Skip to content

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)

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 modifiy the set temperature to fit the desired on-off times.

Components

AHU
Pins Info
Outside air temperature
Return air temperature
Main switching command
Return air temperature setpoint Only for "setpoint" variation
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"}}
Schedule timezone
Main switching command - on
Main switching command - off
ARA .controls App - Return air temperature setpoint Only for "setpoint" variation
Room
Pins Info
Outside air temperature
Room temperature
Main switching command
Temperature Setpoint Only for "setpoint" variation
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"}}
Schedule timezone
Main switching command - on
Main switching command - off

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

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.