Algorithms
Detailed specification of aedifion.controls algorithms.
Standard .controls apps¶
Standard .controls apps are based directly on standard component models.
- Adaptive Room Temperature Algorithm (ARA) - A control algorithm learning room characteristics to optimize room temperature setpoints.
- Blind Control Algorithm (BEE) - A control algorithm moving the blinds to use solar energy effectively
- Decentralized occupancy driven optimisation (DODO) - A control algorithm for adapting ventilation to occupancy
- Free Cooling (FROG) - A control algorithm for cooling the building at night with outdoor air.
- Heat Recovery Optimization (HERO) - A control algorithm that increases the heat recovery of air handling units.
- Heating curve - An algorithm to implement a piecewise linear heating curve for heating or cooling circuits.
- Optimized Room Climate Controller (ORC) - A control algorithm that detects rooms with unsuitable setpoints and optimizes them.
- Predictive heating curve weather compensation (PRAWN) - A control algorithms predicting the required heating power to optimize the heating
- Schedules - Switching components based on pre-defined time schedules
- Weather-predictive Temperature-Mode Setter (WASP) - A control algorithm using weather prediction technology to control high inertia heating-cooling systems.
π¦ Adaptive Room temperature Algorithm (ARA)¶
Rooms should be comfortable for the duration that they are occupied to maximize user comfort, but not during off-times to save energy. However, when setting the occupancy schedule, the room conditioning will not start until the start of the occupancy, resulting in a uncomfortable first hour. To compensate for this, schedules are often extend far beyond the real need, resulting in wasted energy during off hours.
The objective of the ARA is to dynamically extend the schedules, so that the comfort conditions are met on arrival of the occupant, but the overall pre-conditioning phase is minimized.
Components¶
Room¶
Pins | Info |
---|---|
Temperature Setpoint | |
Outside air temperature | |
Room temperature |
Setpoint Attributes | Info |
---|---|
Priority | |
Reset value |
Attributes* | Info |
---|---|
Schedule | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
π Blind Control Algorithm (BEE)¶
The blind control algorithm determines the optimal blind position in a building. The blinds of the building are optimized in the following ways:
- The blinds are used at night to keep heat in buildings during winter or let off heat during summer.
- The blinds are used to increase or decrease solar gains of a building.
We do not set the blind position immediately after the user has taken an action. The blind control algorithm is recommended for any building with blinds that can be controlled by our platform.
Components¶
Room¶
Pins | Info |
---|---|
Blind position | |
Blind rotation | Not in component model yet. |
Room temperature |
Attributes* | Info |
---|---|
Schedule | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Facade orientation |
𦀠Decentralized occupancy driven optimisation (DODO)¶
This algorithm can be applied in buildings with occupancy detection/counting mechanisms. Due to itΒ΄s reactions to live changes in occupancy, it is only applicable to systems with a short reaction time, such as ventilation systems.
The DODO even allows you to combine multiple occupancy detection zones into one value, if the ventilation zone is larger than a single occupancy zone. Every combined occupancy zone can have itΒ΄s own occupancy limit, above which the ventilation turns on or increases itΒ΄s volume flow.
Components¶
Room¶
Pins | Info |
---|---|
Temperature | |
Outside air temperature | |
Presence |
πΈ Free Cooling (FROG)¶
Buildings often apply their cooling systems during the day to maintain a comfortable temperature, while the cool air at night can be used to lower the buildings' temperature. The FROG application implements a free cooling while ensuring that users are not greeted in the morning by uncomfortably cold offices. Furthermore, the free-cooling is only activated when it is significantly cheaper to run the fans for free-cooling at night, than what it is to run compression chillers to achieve the same cooling effect during the day.
Best Practices¶
The FROG is particularly well-suited to buildings which are too warm in summer. Ensure that the AHU can be activated by the cloud-plattform and that the supply air temperature setpoint can be written before implementing the FROG.
Components¶
Air handling unit¶
Default
Variation parameter: None
Implementation notes
Use default if there is only one constant supply air temperature setpoint, or one can directly write to the effective supply air temperature sepoint.
Pin | Required | Mapping info |
---|---|---|
Extract air temperature | Yes | EXH_T_AIR |
Main switching command | Yes | COM_SWI_MN |
Fresh air temperature | Yes | T_AIR_ODA_AHU |
Supply air temperature | Yes | SUP_T_AIR |
Supply air temperature setpoint | Yes | SUP_T_AIR_SP |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - off | No | - |
Main switching command - on | No | - |
Supply fan temperature increase | No | - |
Minimum and maximum supply air temperature setpoints
Variation parameter: min_and_max_supply_temperature_setpoints
Implementation notes
Use this variation if it is not possible to write directly to the supply air temperature setpoints, but it is possible to write to the minimum and maximum supply air temperature setpoints.
Pin | Required | Mapping info |
---|---|---|
Extract air temperature | Yes | EXH_T_AIR |
Main switching command | Yes | COM_SWI_MN |
Fresh air temperature | Yes | T_AIR_ODA_AHU |
Supply air temperature | Yes | SUP_T_AIR |
Supply air temperature setpoint maximum | Yes | SUP_T_AIR_SP_MAX |
Supply air temperature setpoint minimum | Yes | SUP_T_AIR_SP_MIN |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - off | No | - |
Main switching command - on | No | - |
Supply fan temperature increase | No | - |
π¦ΈββοΈ Heat Recovery Optimization (HERO)¶
The heat recovery optimization determines the most efficient temperature which can be used to heat or cool a building. It is recommended for AHUs whose heat recovery is not fully utilized in winter or where heating and cooling appear in the same period and are counterproductive.
Best Practices¶
Once an air handling unit has been identified which would benefit from the HERO, a few things should be considered during implementation. Firstly, it is important to determine how the supply air temperature is controlled. Most AHUs control the supply air temperature by using upper and lower limits to calculate the supply temperature setpoint. If there is a minimum/maximum supply temperature setpoint, it must be mapped to the AHU as it will be prioritized over the supply temperature setpoint. Secondly, the sensitivity of the HERO can be set using the supply fan temperature increase and the heat recovery efficiency. Generally, raising the supply fan temperature increase and heat recovery efficiency will raise the supply temperature setpoint and increase the chance that the air heater is activated.
Components¶
Air handling unit¶
Default
Variation parameter: None
Implementation notes
Use default if there is only one constant supply air temperature setpoint, or one can directly write to the effective supply air temperature sepoint.
Pin | Required | Mapping info |
---|---|---|
Extract air temperature | Yes | EXH_T_AIR |
Fresh air temperature | Yes | T_AIR_ODA_AHU |
Supply air temperature setpoint | Yes | SUP_T_AIR_SP |
Attribute | Required | Mapping info |
---|---|---|
Heat recovery system efficiency | No | - |
Supply air temperature setpoint maximum | No | - |
Supply air temperature setpoint minimum | No | - |
Supply fan temperature increase | No | - |
Minimum and maximum supply air temperature setpoints
Variation parameter: min_and_max_supply_temperature_setpoints
Implementation notes
Use this variation if it is not possible to write directly to the supply air temperature setpoints, but it is possible to write to the minimum and maximum supply air temperature setpoints.
Pin | Required | Mapping info |
---|---|---|
Extract air temperature | Yes | EXH_T_AIR |
Fresh air temperature | Yes | T_AIR_ODA_AHU |
Supply air temperature setpoint maximum | Yes | SUP_T_AIR_SP_MAX |
Supply air temperature setpoint minimum | Yes | SUP_T_AIR_SP_MIN |
Attribute | Required | Mapping info |
---|---|---|
Heat recovery system efficiency | No | - |
Supply air temperature setpoint maximum | No | - |
Supply air temperature setpoint minimum | No | - |
Supply fan temperature increase | No | - |
π Heating Curve¶
The heating curve is the relationship between the system supply temperature and the outside air temperature. It determines what system supply temperature is set for a given outside air temperature. The heating curve is defined by establishing a set of point pairs. Each pair consists of a known system supply temperature corresponding to a specific outside air temperature. Linear interpolation is applied to seamlessly connect these base points, creating a continuous curve.
The predictive variation of the heating curve uses the weather forecast for the next day to adjust supply temperatures in advance. This variation is particularly useful for systems with high inertia, such as underfloor heating systems. It reduces the risk of overshooting the supply temperature setpoint and increases the energy efficiency of the system.
Implementation notes
When using the predictive variation of a heating curve, the base points should be more conservative to avoid low supply temperatures in case of cold temperatures in the early mornings.
Optional Functionality¶
A nighttime reduction can be defined to change the supply temperature setpoint by a set amount while the schedule is not active to further increase energy savings.
Components¶
Boiler¶
Default
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive
Variation parameter: predictive
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Cooling Circuit¶
Default
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive
Variation parameter: predictive
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Minimum and maximum supply temperature setpoints
Variation parameter: min_and_max_supply_temperature_setpoints
Implementation notes
Use this variation if it is not possible to write directly to the supply temperature setpoint, but it is possible to write to the minimum and maximum supply temperature setpoints.
Pins | Mapping Info |
---|---|
Supply temperature setpoint maximum | T_IN_SP_MAX |
Supply temperature setpoint minimum | T_IN_SP_MIN |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive minimum and maximum supply temperature setpoints
Variation parameter: predictive_min_and_max_supply_temperature_setpoints
Implementation notes
Use this variation if it is not possible to write directly to the supply temperature setpoint, but it is possible to write to the minimum and maximum supply temperature setpoints.
Pins | Mapping Info |
---|---|
Supply temperature setpoint maximum | T_IN_SP_MAX |
Supply temperature setpoint minimum | T_IN_SP_MIN |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Combined heat and power¶
Default
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive
Variation parameter: predictive
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Heating Circuit¶
Default
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Minimum and maximum supply temperature setpoints
Variation parameter: min_and_max_supply_temperature_setpoints
Implementation notes
Use this variation if it is not possible to write directly to the supply temperature setpoint, but it is possible to write to the minimum and maximum supply temperature setpoints.
Pins | Mapping Info |
---|---|
Supply temperature setpoint maximum | T_IN_SP_MAX |
Supply temperature setpoint minimum | T_IN_SP_MIN |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive minimum and maximum supply temperature setpoints
Variation parameter: predictive_min_and_max_supply_temperature_setpoints
Implementation notes
Use this variation if it is not possible to write directly to the supply temperature setpoint, but it is possible to write to the minimum and maximum supply temperature setpoints.
Pins | Mapping Info |
---|---|
Supply temperature setpoint maximum | T_IN_SP_MAX |
Supply temperature setpoint minimum | T_IN_SP_MIN |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Heat pump¶
Default
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive
Variation parameter: predictive
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Heat transfer unit¶
Default
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Outside air temperature | T_AIR_ODA |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Predictive
Variation parameter: predictive
Pins | Mapping Info |
---|---|
Supply temperature setpoint | T_IN_SP |
Attributes | Required | Mapping info |
---|---|---|
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Base points | Yes | The base points for the calculation. Must be given as pairs of outside air temperature/supply temperature, e.g. -12,90;20,50 |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
π§ Optimized Room Climate Control Algorithm (ORC)¶
Users often activate their room climate controllers and put them to a setting as a result of discomfort stemming from a short term weather condition. After this condition, and the resulting discomfort, have passed, the settings are often not resetted. The ORC-application handles this issue by halving the user-setting after a predetermined time-period has passed.
In many room control units, there are fixed standard setpoints. Users can only decrease or increase these setpoints by a certain difference using the room control unit.
Components¶
Room¶
Pins | Info |
---|---|
Temperature Setpoint | |
Temperature Setpoint Deviation | |
Outside air temperature |
π¦ Predictive heating curve weather compensation (PRAWN)¶
β This algorithm requires at least 3 months of historical measurement data in 15-minute-resolution, recorded during the heating season. If this data is not (yet) available, a simplified variant of the PRAWN can be used.
The cooling/heating demand at different outdoor temperatures is learned from historical data and new measurements. The flow temperature set point is adjusted based on the weather forecast so that the lowest possible temperature (heating case) is present in the distribution network. The algorithm prevents energy loss due to simultaneous heating and cooling (e.g. floor heating and ventilation) Moreover, it increases the efficiency of chillers and heat pumps.
Variants of PRAWN¶
The algorithm should, if possible, be extended by reference temperature measurements taken from (retrofitted) room temperature sensors. If one of the room temperatures is below the lower threshold, the flow temperature is automatically increased by a pre-defined temperature difference. Moreover, the algorithm can already be implemented in a project, in which room temperature sensors are available, even if sufficient training data is not available.
Components¶
Heating circuit¶
Pins | Info |
---|---|
Heating power | |
Volume flow | |
Supply temperature | |
Return temperature | |
Supply temperature setpoint |
Attributes* | Info |
---|---|
β° Schedules¶
The schedule turns a system on and off, based on the defined schedule parameters. Holidays region adjusts the schedule to the specific region holidays, for example: on Christmas, the schedule will be Off. An additional custom holiday can be added to the schedule, where the custom day schedule will be applied. If no custom day schedule is defined, the default value on holidays is Off. The default holidays region is "DE" (Germany).
Per default, its switching commands are 0 and 1, but for systems that need other values (such as the ones that use multi state variables), you can adjust the on and off value preset.
Components¶
All components¶
Implementation notes
The component must have a main switching command pin to implement the schedule controls algorithm.
Pins | Required | Mapping info |
---|---|---|
Switch command | Yes | COM_SWI_MN |
Attributes | Required | Mapping info |
---|---|---|
Main switching command - off | No | - |
Main switching command - on | No | - |
Schedule | Yes | Currently, the accepted schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Schedule Timezone | Yes | - |
Custom day schedules | No | Currently, the accepted custom schedule format looks like this {"monday": {"end": "18:00", "start": "04:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Custom holiday | No | Currently, the accepted holiday dates format looks like this {"Summer Holidays":{"start": "2024-08-15", "end": "2024-08-30"}} |
Regional holiday key | No | Currently, the accepted holiday Region key format looks like this : "COUNTRY-STATE", example:"DE-NW", abbreviations can be found here: https://python-holidays.readthedocs.io/en/latest/index.html |
π Weather-predictive Temperature-Mode Setter (WASP)¶
Description¶
Cooling, heating, and hybrid circuits are dependent on ambient temperature to switch On and Off, making decisions by direct reaction to weather changes. This behaviour leads to short-sighted operations, where heating and cooling occur successively within short periods, or at times where no operation is needed due to fluctuations of temperatures within acceptable outside temperature ranges. The Weather-predictive Temperature-Mode Setter uses predictive weather data to analyse the weather conditions during working hours(8h-18h) and decides which heating and cooling limits have to be implemented, to switch operations On and Off and ensure no unwanted operations occur during or outside working schedules.
Functionality¶
WASP creates its own switching limits (heating and cooling switching limits) based on the predictive outside temperature and changes the switching limits datapoints in the component accordingly. If these switching limits are not present as datapoints for the component, On/Off switch datapoints are used with the WASP witching limits to achieve the same results.
N.B.: WASP does not write to temperature setpoints and does not control in any way how the circuit operates when It is turned on.
Optional Functionality¶
The WASP uses nighttime reduction (added by default) which further extends the limits at night and ensures there is no operation at night except for extreme ambient conditions. The nighttime is applied outside schedule times, defaults to 10 degrees Celsius and can be changed in the attributes of the component. The schedule defaults to weekdays from 6 a.m. to 8 p.m. and can be changed to any schedule in the attributes of the component.
Components¶
Heating Circuit¶
Default
Variation parameter: None
Implementation notes
Use default if you want to control the component operation using a main switching command datapoint.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Main switching command | Yes | COM_SWI_MN |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - on | Yes | - |
Main switching command - off | Yes | - |
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Heating Limit
Variation parameter: single_limit
Implementation notes
Use single_limit if you want to control the component operation using the heating limit datapoint.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Heating limit | Yes | CTRL_SV_UP |
Attribute | Required | Mapping info |
---|---|---|
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Cooling Circuit¶
The Cooling Circuit component uses the cooling switching limit generated by WASP. If the ambient temperature is below the cooling switching limit, the circuit will be turned off.
Default
Variation parameter: None
Implementation notes
Use default if you want to control the component operation using a main switching command datapoint.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Main switching command | Yes | COM_SWI_MN |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - on | Yes | - |
Main switching command - off | Yes | - |
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Cooling Limit
Variation parameter: single_limit
Implementation notes
Use single_limit if you want to control the component operation using the cooling limit datapoint.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Cooling limit | Yes | CTRL_SV_UP |
Attribute | Required | Mapping info |
---|---|---|
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Hybrid Circuit¶
The Hybrid Circuit component uses the heating switch limit and the cooling switch limit generated by the WASP, to control heating and cooling operations. The WASP makes sure that these switching limits do not contradict each other in any situation and prevents any successive heating and cooling operations.
Default
Variation parameter: None
Implementation notes
Use default if you want to control the component operation using the main switching command and the operation mode datapoints.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Main switching command | Yes | COM_SWI_MN |
Operation mode | Yes | OPR_MOD |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - on | Yes | - |
Main switching command - off | Yes | - |
Operation mode - neutral | Yes | - |
Operation mode - heating | Yes | - |
Operation mode - cooling | Yes | - |
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Heating and cooling limits
Variation parameter: heating_and_cooling_limits
Implementation notes
Use heating_and_cooling_limits if you want to control the component operation using the heating limit, cooling limit and main switching command datapoints.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Cooling limit | Yes | CTRL_SV_UP_C |
Heating limit | Yes | CTRL_SV_UP_H |
Main switching command | Yes | COM_SWI_MN |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - on | Yes | - |
Main switching command - off | Yes | - |
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Single limit
Variation parameter: single_limit
Implementation notes
Use single_limit if you want to control the component operation using a one heating/cooling-limit datapoint that decides heating or cooling in the component and the main switching command datapoints. The heating/cooling-limit is such components is usually compared to outside temperature and decides the operation mode based on the difference. For example: if the ambient temperature is above the limit, the operation mode is cooling and vice versa. In such cases, the limit datapoint is mapped to the heating limit pin.
Pin | Required | Mapping info |
---|---|---|
Outside air temperature | Yes | T_AIR_ODA |
Heating limit | Yes | CTRL_SV_UP_H |
Main switching command | Yes | COM_SWI_MN |
Attribute | Required | Mapping info |
---|---|---|
Main switching command - on | Yes | - |
Main switching command - off | Yes | - |
Schedule | No | Currently, the accepted schedule format looks like this {"monday": {"end": "20:00", "start": "06:00"}, "tuesday": {"end": "16:24", "start": "04:00"}} |
Night time reduction | No | A value that is substracted from the supply temperature when the schedule is off |
Schedule Timezone | No | Defaults to Europe/Berlin |
Custom .controls apps¶
Custom .controls apps require a system-specific mapping.
- Demand responsive mixed integer grid optimization (DINGO) - A control algorithm optimizing the schedule and modulation of generators and consumers in a grid.
- Tuning of PID controllers - Finding optimal control parameters
- Variable pressure control (MaxPhi) - Minimizing fan and pump speeds
- Temperature Spread Regulator) - Optimizing the temperature spread
- System identification and coordination of subsystem controllers) - Identifying and coordinating subsystems and controllers
π Demand responsive mixed integer grid optimization (DINGO)¶
The DINGO uses model-predictive control perform demand-side management in energy networks. It can be applied to a variety of energy systems including heating, cooling and electricity networks. Since the DINGO actively manages consumers and can make use of flexibility in energy systems, it is particularly well-suited to energy system with flexible prices, onsite generation of renewables or systems with a high thermal inertia. A further use-case of the DINGO is to reduce operational costs by performing peak-shaving.
ποΈ Tuning of PID controllers¶
If you encounter control loop oscillations in a system where the PID controllerΒ΄s parameters are writable, we can optimize them to get rid of the oscillating behaviour. A control loop oscillation can have many causes. These include, but are not limited to
- the PID controllerΒ΄s values might be insufficiently tuned to the controlled system
- the PID controller might be set up incorrectly and using the wrong input or writing to the wrong setpoint
- multiple controllers could be influencing each other
π¨ Variable pressure control (MaxPhi)¶
This function optimizes the energy-efficiency and therefore the cost-efficiency of energy distribution systems with distributed consumers and a central volume flow control actuator. Some examples are:
- air handling units (AHU) with variable air volume (VAV)-Boxes
- district heating systems
- underfloor heating systems
- borehole heat exchanger fields
- etc.
The volume flow from all the distributed consumers is generated centrally with a volume flow control actuator, for instance, a pump or ventilation unit. In standard systems, they are controlled by a constant pressure or volume flow setpoint. Depending on this given plant state the distributed controllers reduce this volume flow to the respective setpoint, which is needed to fulfil the desired state. Because the system's pressure- or volume flow setpoint is selected for a full-load operation mode, in a partial-load operation mode, where the distributed actuators are (partially) closed, the overall system is not working efficiently. With variable pressure control, the inputs are the continuously retrieved feedback signals of all the distributed actuators. With the maximum of those feedbacks, the setpoints of the superordinate volume flow control actuator are being calculated.
π‘οΈ Temperature Spread Regulator¶
This application can be applied to water-bearing thermal distribution systems, such as heating and cooling circuits. In conventional distribution systems, the pump is operated statically, regardless of the actual user demand or the actual heat requirement of the heating circuit. The Temperature Spread Regulator .controls application closely monitors the inlet and outlet temperatures in the system in order to determine whether the system is running efficiently. Deriving the necessary intelligence from historical data, a determination is made about how large the temperature gradient within the thermally activated component should be in order to justify pump operation. Based on the derived thresholds, the operating time of pumps is reduced, increasing the efficiency and reducing the mechanical wear of the entire system.
π System identification and coordination of subsystem controllers¶
Supervisory Model Predictive Control (MPC) is considered a high-potential control approach for buildings and energy systems. It is based on a model of the controlled system that is used by an algorithm to determine the most favourable control decision for a given aim such as energy savings or thermal comfort improvement. However, the effort of providing a good model is slowing down the spread of MPC in the building sector. Our approach reduces the effort for model creation. We apply automatic system identification algorithms (e.g. SID) to the data of small subsystems. The reduced dimensionality of small subsystems increases the quality of the model fit.
Our implementations of distributed MPC algorithms (BExMoC and LC-DMPC) allow combining these small models into one application that yields an optimal result for the total system.
Further Information¶
More control algorithms will be described here. If you wish to implement your own algorithm or want us to implement it, feel free to contact us.