Skip to content

Algorithms

Detailed specification of aedifion.controls algorithms.

Standard .controls apps

Standard .controls apps are based directly on standard component models.

The controls apps can be tested without writing directly to the building by using a dryrun variation. In this case, a virtual data point with the calculated setpoints is generated and stored (similar to a VDP - virtual data point) to investigate the behavior of a controls app.

🦜 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.

The ARA can be deployed as a variation of the Schedule .controls app. It can either write to the main switching command of a component or the pinned setpoint to modify the set temperature to fit the desired on-off times.

Components

AHU
Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Return air temperature Yes EXH_T_AIR Input
Main switching command Yes COM_SWI_MN Output
Return air temperature setpoint Yes, only for "setpoint" variation EXH_T_AIR_SP Output
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"}}
Schedule timezone
Main switching command - on
Main switching command - off
ARA .controls App - Return air temperature setpoint Only for "setpoint" variation
Room
Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Room temperature Yes T_AIR Input
Main switching command Yes COM_SWI_MN Output
Air temperature setpoint Yes, only for "setpoint" variation T_AIR_SP Output
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"}}
Schedule timezone
Main switching command - on
Main switching command - off

🐜 Anti Pump Blockage Algorithm (ANT)

During certain periods of the year, it can be energetically advantageous to switch off heating, cooling or hybrid circuits (e.g., a heating circuit can be switched off during peak summer season). This can be either a decision made by the responsible technician or the outcome of a .controls app like the WASP. This leads to pumps not being switched on, which can cause blocked pumps. Thus, it is recommended to periodically switch on the pumps for a brief amount of time.

The ANT checks once a week whether the pump was switched on or not. If the pump was running during that week, no further action is taken. If the pump was not running at all during that week, the pump is switched on for five minutes before turning it off again. Considering disruptions during daily operations and lower dynamic electricity prices, the app is triggered during the night from Sunday to Monday.

Components

All Components

The ANT .controls app is available for heating circuits, cooling circuits and hybrid circuits.

Default

Variation parameter: None

Pins Required pin_alphanumeric_id Input/Output
Pump operation command Yes PU+COM_SWI Output
Pump operating message No* PU+MSG_OPR Input
Main switching command No* COM_SWI_MN Input
Pump control signal No* PU+CTRL Input
Pump position No* PU+CTRL_FB Input

*: At least one of PU+MSG_OPR,COM_SWI_MN, PU+CTRL, PU+CTRL_FB is required.

Attributes Required Info
Main switching command - off No -
Main switching command - on No -

Main Switching command

Variation parameter: main_switching_command

Pins Required pin_alphanumeric_id Input/Output
Main switching command Yes COM_SWI_MN Input, Output
Pump operating message No* PU+MSG_OPR Input

*: PU+MSG_OPR is used as the default input pin, if it is mapped. Otherwise COM_SWI_MN is used.

Attributes Required Info
Main switching command - off No -
Main switching command - on No -

🐝 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:

  1. The blinds are used at night to keep heat in buildings during winter or let off heat during summer.
  2. 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 Required pin_alphanumeric_id Input/Output
Room temperature No T_AIR Input
Sunlight protection - position Yes SUN_POS Input, Output
Outside air temperature No T_AIR_ODA Input
Attribute Required Info
Schedule No default: every day from 08:00 to 18:00
Bee .controls App - Cooldown time No default: 3600 s
Bee .controls App - Cooldown time user No default: 7200 s
Upper limit for room air temperature No default: 26 Β°C

🐸 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 free cooling while ensuring that users are not greeted in the morning by uncomfortably cold offices. Furthermore, free cooling is only activated when it is significantly cheaper to run the fans for free cooling at night than to run compression chillers to achieve the same cooling effect during the day. The frog is allowed to activate the AHU for free cooling between 02:00 and 06:00 and only once per night.

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 platform 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 the FROG should be used stand-alone (without a running HERO .controls app) and if there is only one constant supply air temperature setpoint, or one can directly write to the effective supply air temperature setpoint.

Caution

The FROG writes the 'Main switching command - off' attribute value when free cooling is switched off. Use an automatic mode for the 'Main switching command - off' attribute value if available (so that the AHU is switched from auto mode to on and back to auto mode during free cooling), or combine the FROG with a schedule to ensure a proper operation during the day. If the FROG is off or inactive, the 'Supply temperature summer case' attribute value will be written (constant value).

Pin Required pin_alphanumeric_id Input/Output
Return air temperature Yes EXH_T_AIR Input
Outside air temperature (AHU) Yes T_AIR_ODA_AHU Input
Supply air temperature Yes SUP_T_AIR Input
Supply air temperature setpoint Yes SUP_T_AIR_SP Output
Heat recovery system - position No HRCS+UTIL_LEV Input
Air heater - valve - position No H_CM+H_CRC+VAL_POS Input
Air re-heater - valve - position No H_CM.RE+H_CRC+VAL_POS Input
Air cooler - valve - position No C_CM+C_CRC+VAL_POS Input
Main switching command Yes COM_SWI_MN Output
Attribute Required Info
Main switching command - off No default: 0
Main switching command - on No default: 1
Schedule Timezone Yes
Supply air temperature setpoint maximum No Maximum allowed supply air temperature setpoint
Supply air temperature setpoint minimum No Minimum allowed supply air temperature setpoint
Return air temperature setpoint deviation tolerance No Allowed return air temperature above and below the ideal indoor air temperature (ideal indoor air temperature is 22Β°C in Winter)
Return air temperature setpoint maximum No Maximum allowed return air temperature (independent of the ideal indoor air temperature)
Return air temperature setpoint minimum No Minimum allowed return air temperature (independent of the ideal indoor air temperature)
Supply fan temperature increase No Supply air temperature increase due to the waste heat of the fan
Heat recovery system efficiency No Maximum efficiency of the heat recovery system
Heat recovery system active during cooling No True, if the internal control of the AHU uses the heat recovery for cooling
Adapt HERO parameters No True, if the HERO is allowed to learn parameters based on the AHU behavior
Supply temperature summer case Yes Supply temperature setpoint that is written when the FROG is off or inactive

Minimum and maximum supply air temperature setpoints

Variation parameter: min_and_max_supply_temperature_setpoints

Implementation notes

Use this variation if the FROG should be used stand-alone (without a running HERO .controls app) and 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.

Caution

The FROG writes the 'Main switching command - off' value when free cooling is switched off. Use an automatic mode for the 'Main switching command - off' value if available (so that the AHU is switched from auto mode to on and back to auto mode during free cooling), or combine the FROG with a schedule to ensure a proper operation during the day. If the FROG is off or inactive, the values of the 'Supply air temperature setpoint maximum' attribute and 'Supply air temperature setpoint minimum' attribute will be written (constant value).

Pin Required pin_alphanumeric_id Input/Output
Return air temperature Yes EXH_T_AIR Input
Outside air temperature (AHU) Yes T_AIR_ODA_AHU Input
Supply air temperature Yes SUP_T_AIR Input
Supply air temperature setpoint maximum Yes SUP_T_AIR_SP_MAX Output
Supply air temperature setpoint minimum Yes SUP_T_AIR_SP_MIN Output
Heat recovery system - position No HRCS+UTIL_LEV Input
Air heater - valve - position No H_CM+H_CRC+VAL_POS Input
Air re-heater - valve - position No H_CM.RE+H_CRC+VAL_POS Input
Air cooler - valve - position No C_CM+C_CRC+VAL_POS Input
Main switching command Yes COM_SWI_MN Output
Attribute Required Info
Main switching command - off No default: 0
Main switching command - on No default: 1
Schedule Timezone Yes
Supply air temperature setpoint maximum No Maximum allowed supply air temperature setpoint
Supply air temperature setpoint minimum No Minimum allowed supply air temperature setpoint
Return air temperature setpoint deviation tolerance No Allowed return air temperature above and below the ideal indoor air temperature (ideal indoor air temperature is 22Β°C in Winter)
Return air temperature setpoint maximum No Maximum allowed return air temperature (independent of the ideal indoor air temperature)
Return air temperature setpoint minimum No Minimum allowed return air temperature (independent of the ideal indoor air temperature)
Supply fan temperature increase No Supply air temperature increase due to the waste heat of the fan
Heat recovery system efficiency No Maximum efficiency of the heat recovery system
Heat recovery system active during cooling No True, if the internal control of the AHU uses the heat recovery for cooling
Adapt HERO parameters No True, if the HERO is allowed to learn parameters based on the AHU behavior

For combination with hero

Variation parameter: min_and_max_supply_temperature_setpoints

Implementation notes

Use this variation if the FROG should be combined with the HERO (default or min_and_max_supply_temperature_setpoints). The HERO will calculate the supply air temperature setpoint during free cooling.

Caution

The FROG writes the 'Main switching command - off' value when free cooling is switched off. Use an automatic mode for the 'Main switching command - off' value if available (so that the AHU is switched from auto mode to on and back to auto mode during free cooling), or combine the FROG with a schedule to ensure a proper operation during the day.

Pin Required pin_alphanumeric_id Input/Output
Return air temperature Yes EXH_T_AIR Input
Supply air temperature Yes SUP_T_AIR Input
Main switching command Yes COM_SWI_MN Output
Attribute Required Info
Main switching command - off No default: 0
Main switching command - on No default: 1
Schedule Timezone Yes
Return air temperature setpoint deviation tolerance No Allowed return air temperature above and below the ideal indoor air temperature (ideal indoor air temperature is 22Β°C in Winter)
Return air temperature setpoint minimum No Minimum allowed return air temperature (independent of the ideal indoor air temperature)

πŸ¦Έβ€β™€οΈ Heat Recovery Optimization (HERO)

The heat recovery optimization determines the most efficient temperature which can be used to heat or cool a building. At the same time, the HERO keeps the building temperature within the comfortable range. 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 setpoint.

Pin Required pin_alphanumeric_id Input/Output
Return air temperature Yes EXH_T_AIR Input
Outside air temperature (AHU) Yes T_AIR_ODA_AHU Input
Supply air temperature setpoint Yes SUP_T_AIR_SP Output
Heat recovery system - position No HRCS+UTIL_LEV Input
Air heater - valve - position No H_CM+H_CRC+VAL_POS Input
Air re-heater - valve - position No H_CM.RE+H_CRC+VAL_POS Input
Air cooler - valve - position No C_CM+C_CRC+VAL_POS Input
Supply air fan - operating message No FAN.SUP+MSG_OPR Input
Attribute Required Info
Supply air temperature setpoint maximum No Maximum allowed supply air temperature setpoint
Supply air temperature setpoint minimum No Minimum allowed supply air temperature setpoint
Return air temperature setpoint deviation tolerance No Allowed return air temperature above and below the ideal indoor air temperature (ideal indoor air temperature is 22Β°C in Winter)
Return air temperature setpoint maximum No Maximum allowed return air temperature (independent of the ideal indoor air temperature)
Return air temperature setpoint minimum No Minimum allowed return air temperature (independent of the ideal indoor air temperature)
Supply fan temperature increase No Supply air temperature increase due to the waste heat of the fan
Heat recovery system efficiency No Maximum efficiency of the heat recovery system
Heat recovery system active during cooling No True, if the internal control of the ahu uses the heat recovery for cooling
Adapt HERO parameters No True, if the hero is allowed to learn parameters based on the ahu behavior

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 pin_alphanumeric_id Input/Output
Return air temperature Yes EXH_T_AIR Input
Outside air temperature (AHU) Yes T_AIR_ODA_AHU Input
Supply air temperature setpoint maximum Yes SUP_T_AIR_SP_MAX Output
Supply air temperature setpoint minimum Yes SUP_T_AIR_SP_MIN Output
Heat recovery system - position No HRCS+UTIL_LEV Input
Air heater - valve - position No H_CM+H_CRC+VAL_POS Input
Air re-heater - valve - position No H_CM.RE+H_CRC+VAL_POS Input
Air cooler - valve - position No C_CM+C_CRC+VAL_POS Input
Supply air fan - operating message No FAN.SUP+MSG_OPR Input
Attribute Required Info
Supply air temperature setpoint maximum No Maximum allowed supply air temperature setpoint
Supply air temperature setpoint minimum No Minimum allowed supply air temperature setpoint
Return air temperature setpoint deviation tolerance No Allowed return air temperature above and below the ideal indoor air temperature (ideal indoor air temperature is 22Β°C in Winter)
Return air temperature setpoint maximum No Maximum allowed return air temperature (independent of the ideal indoor air temperature)
Return air temperature setpoint minimum No Minimum allowed return air temperature (independent of the ideal indoor air temperature)
Supply fan temperature increase No Supply air temperature increase due to the waste heat of the fan
Heat recovery system efficiency No Maximum efficiency of the heat recovery system
Heat recovery system active during cooling No True, if the internal control of the ahu uses the heat recovery for cooling
Adapt HERO parameters No True, if the hero is allowed to learn parameters based on the ahu behavior

πŸ“ˆ 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_IN_SP Output
Outside air temperature No T_AIR_ODA Input
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_IN_SP Output
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_IN_SP Output
Outside air temperature No T_AIR_ODA Input
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_IN_SP Output
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint maximum Yes T_IN_SP_MAX Output
Supply temperature setpoint minimum Yes T_IN_SP_MIN Output
Outside air temperature No T_AIR_ODA Input
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint maximum Yes T_IN_SP_MAX Output
Supply temperature setpoint minimum Yes T_IN_SP_MIN Output
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_OUT_SP Output
Outside air temperature No T_AIR_ODA Input
Attributes Required 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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_OUT_SP Output
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes T_IN_SP Output
Outside air temperature No T_AIR_ODA Input
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint maximum Yes T_IN_SP_MAX Output
Supply temperature setpoint minimum Yes T_IN_SP_MIN Output
Outside air temperature No T_AIR_ODA Input
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint maximum Yes T_IN_SP_MAX Output
Supply temperature setpoint minimum Yes T_IN_SP_MIN Output
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes COND+T_OUT_SP Output
Outside air temperature No T_AIR_ODA Input
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes COND+T_OUT_SP Output
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes H_TRA_ST+SEC+T_OUT_SP Output
Outside air temperature No T_AIR_ODA Input
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 Required pin_alphanumeric_id Input/Output
Supply temperature setpoint Yes H_TRA_ST+SEC+T_OUT_SP Output
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 adjust the setpoints of the room climate controllers in response to temporary weather conditions that cause discomfort. However, once the weather changes and the discomfort subsides, these settings are often not reset.

Many room control units have predefined standard setpoints. Users can only adjust these setpoints within a limited range, either increasing or decreasing the temperature by a specified amount.

The ORC application addresses inefficient setpoints by automatically resetting the offset to 0 K at midnight if doing so results in energy savings.

Components

Room
Pins Required pin_alphanumeric_id Input/Output
Room temperature offset Yes T_AIR_SP_ADJ Input
Base room temperature setpoint Yes T_AIR_SP_BASE Output
Room temperature setpoint Yes T_AIR_SP Input

Pump modulation algorithm (PUMA)

The Puma controls the head of pumps in heating circuits. It uses the weather forecast and tries to keep the spread of the flow and return temperature of the heating circuit within a reasonable range. The pump is switched off if no heating is required. The PUMA can be used if the flow temperature setpoint of a heating circuit can't be set and serves as an alternative to the Heating curve.

❗The pump should be in a pressure control mode (e.g. dp-c or dp-v) so that the setpoint changes the head/pressure of the pump. It is not recommended to control the pump speed directly.

Components

Heating circuit

Default

Variation parameter: None

Controls the pump head based on the ambient temperature forecast and the given heating curve.

Pins Required pin_alphanumeric_id Input/Output
Pump - operation command Yes H_CRC+PU+COM_SWI Output
Pump - control signal Yes H_CRC+PU+CTRL Output
Attribute Required Info
Main switching command - off No default: 0
Main switching command - on No default: 1
Heating curve - base points No in Β°C and %; default: -5,70; 10,35; 20,0
Heating curve - night time reduction No in %; default 0
Schedule No Used for night time reduction; default Mo - Fr: 06:00 - 20:00
Schedule timezone No default: Berlin/Europe

return_temperature

Variation parameter: return_temperature

Controls the pump head based on the ambient temperature forecast and the given heating curve and tries to keep the spread between flow and return temperature within a reasonable range that depends on the outside air temperature.

Pins Required pin_alphanumeric_id Input/Output
Pump - operation command Yes H_CRC+PU+COM_SWI Output
Pump - control signal Yes H_CRC+PU+CTRL Output
Supply temperature Yes H_CRC+T_IN Input
Return temperature Yes H_CRC+T_OUT Input
Attribute Required Info
Main switching command - off No default: 0
Main switching command - on No default: 1
Heating curve - base points No in Β°C and %; default: -5,70; 10,35; 20,0
Heating curve - night time reduction No in %; default: 0
Schedule No Used for night time reduction; default Mo - Fr: 06:00 - 20:00
Schedule timezone No default: Berlin/Europe

Minimum and maximum supply air temperature setpoints

⏰ 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 pin_alphanumeric_id Input/Output
Switch command Yes COM_SWI_MN Output
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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Main switching command Yes COM_SWI_MN Output
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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Heating limit Yes CTRL_SV_UP Output
Attribute Required 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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Main switching command Yes COM_SWI_MN Output
Attribute Required 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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Cooling limit Yes CTRL_SV_UP Output
Attribute Required 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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Main switching command Yes COM_SWI_MN Output
Operation mode Yes OPR_MOD Output
Attribute Required 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

Hybrid circuit automatic switch

Variation parameter: wasp_hybrid_circuit_automatic_switch

Implementation notes

Use default if you want to control the component operation using the main switching command and the operation mode datapoints.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Automatic switch Yes OPR_MOD_SW_AUTO Output
Attribute Required Info
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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Main switching command Yes COM_SWI_MN Output
Cooling limit Yes CTRL_SV_UP_C Output
Heating limit Yes CTRL_SV_UP_H Output
Attribute Required 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.

Pins Required pin_alphanumeric_id Input/Output
Outside air temperature No T_AIR_ODA Input
Main switching command Yes COM_SWI_MN Output
Heating limit Yes CTRL_SV_UP_H Output
Attribute Required 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.

🦀 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.

πŸ• 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.

🦐 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.

πŸŽ›οΈ 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.