Now that I have installed 8 termostats (Popp / Danfoss Ally Clone) and two of them are used in the same room, I am looking for the optimal configuration.
At the moment I have a 1:1 relationship between the magent switches (Aqara window and door) and the thermostats. Per window contact, I have one rule that sets the config/externalwindowopen on the thermostat.
But since multiple windows and thermostats in the living room create a climate zone, I need to group the devices. When a sensor detects the open window, I want both thermostats to be notified accordingly.
I also want to harmonize the temperature control of the two thermostats. The Danfoss Ally offers a load balancing mode for this, which I don’t know exactly how I can and must configure.
Preferably I would like to set the room temperature and not the temperature for both thermostats.
Last but not least, I would also like to leave the determination of the room temperature for both devices to the Philips Hue Motion Sensor and use the “external Measured Room Sensor” field.
I would be very happy to hear your expert advice. I’m not even sure if rules are the right approach to inform the thermostats about open windows.
In your case, i’d recommend using something like Node red or Home assistant where you can create automations for this. This basically uses the "If this then that " principle where it acts on what you want to do. I am not sure if this can be achieved with deCONZ Rules alone. I haven’t done the above, so perhaps someone else can help you better.
I would not recommend using the temperature reported by devices not dedicated to it (for example Hue motion sensor) as this is the device internal temperature and not the real temperature. This can cause a deviation.
Hi Dennis,
thanks for being helpful here as well.
I figured my question would fit better here than on Discord or Github.
I would like to handle vital tasks (motionlight, room temperature) as much as possible autonomously within deCONZ.
Although I use Home Assistant for many years, but the constant restarts because of any updates of the core or individual components are a problem.
That’s why I decided to run deCONZ on its own hardware and not as an integrated addon in Docker on HA.
Let’s break down my challenge:
Can multiple Aqara window contacts be linked into a group?
Rule 1:
At least 1 window goes open → heating off.
Rule 2:
No window sensor in the group is open → heating on.
It would be neat to define a logical thermostat that uses the average value of the two thermostats as the actual value and transmits an adjustable setpoint to both thermostats.
I will get the determined room temperature from climate sensors in the future. At the moment, the Hue Motion sensor (offset calibrated at room temperature) is more reliable than the thermostat that measures the temperature directly at the radiator.
I am not sure if this is something that can be achieved with rules itself. I do know that Hue Essentials is able to make rules easily from the app. @Thomas is it possible to configure the above with Hue essentials?
Your first point about multiple window sensors, if I understand correctly, is something like the following two automations:
“when any window is opened, set config/externalwindowopen to open”
“when any window is closed, and if all (other) windows are closed, set config/externalwindowopen to closed”.
Is this what you want? This is definitely possible using deCONZ rules only, but the automations in my Hue Essentials app do not expose this functionality in an easy way at the moment. Automation events, conditions, and actions can be customised in the app. But this setup can require a lot of conditions, depending on the amount of window sensors you want to link to a thermostat. A bit too advanced to create using the current features in the app.
How many window sensors do you have in a room? That should give me a bit of an idea what to expect, because there are also limits for the amount of conditions in rules (why these limits were added in deCONZ, I don’t know, it makes it more challenging with even more rules).
I do have plans to add this specific feature, but can not give an ETA at this time. There are a lot of feature requests for the automations and I am the only one adding these to the app.
This part of your request is too advanced for the deCONZ rules. There is no way at the moment to use sensor values (like temperature) as variables, average them, or use them as actions, etc. You would need to find another solution for this, unfortunately.
I understand you may think this is similar to the open/close feature, but for that one you can only have two states (open and closed), so rules can be created for all possible situations. But obviously that cannot be done for every possible temperature value. So something like variables in rules (and basic math calculations) would need to be supported (scripts?), and only then this can be done on deCONZ.
I think there is no way to implement this only using Deconz (right now). For example the rule for the external room sensor integration is little complex. The temperature needs to be send “at least every 3 hours but not more often than every 30 minutes @ every 0,1K change.”
The setpoint I just sync between the several allys in one room with my smarthome controller, Domoticz. If one setpoint is changed I just sending new setpoints to the others. I don’t know if this is also possible with rules?
I also managed to get running the load balancing feature with a customized DDF through the Rest API and a “simple” script through domoticz.
But you “only” need a simple enviroment which can do easy mathematics and can handle HTTPS. I don’t know if this would also be possible on a simple Raspberry Pi setup??
Coincidence and writing before reading the above. Just added some deconz internal rules for the external open state, which works crisp and nicely.
Setting the external temp should work with ddx rules. Iirc, you should change one of the settings first to “allow” setting the temp every 5 mins (radiator covered?). Haven’t played with that yet, but I guess that will come the next days.
Thanks for sharing the document btw Looks like a great source of knowledge I wasn’t aware of
First, many thanks to each of you for taking on my challenge.
My setup so far (Window control):
There are four rooms, each with a thermostat and window sensor installed.
I created the rules for open and closed windows manually via the REST API.
There is the living room with two radiators and three windows. @Thomas
The rules for each window sensor would need to be supplemented with the action for the second thermostat.
Also, the rules, for closing the window would need to be supplemented with conditions that include the other two window sensors. Only if these are also “off”, the actions for both thermostats may be executed.
I was hoping I could throw all three window contacts into a group and use the status of the group as a trigger. That would save me having to use the other sensors as conditions.
Am I on the right track here?
Load Balancing
For load balancing multiple Danfoss Ally I found among others Home Assistant templates that can at least give us food for thought, although they are designed for Zigbee2MQTT and ZHA respectively. The point is not to keep the temperature identical, but to make use of the Ally’s functions to distribute the heating load.
“load_estimate” “room_load_mean”
External temperature sensor for Ally:
Again, I found templates for ZHA and Zigbee2MQTT that transmit the measured temperature via “/set/external_measured_room_sensor”. The maximum update rates, as mentioned by Hencor and Swoop, depend on the configuration of the Ally.
It would be very helpful to know more about the DDX rules that @Swoop mentioned. Especially because I have no clue how to achieve the timing for the update.
No, it’s a bit more complicated than just creating a group. Sensors can not be in a group.
As said earlier it’s on the wish list for Hue Essentials.
I see you are familiar with the rules, in that case I can give you a hint in the right direction.
“when any window is opened, set config/externalwindowopen to open”
For this automation, you need to create a rule for every window sensor containing:
conditions:
open EQ true (for only this 1 sensor)
open DX (for only this 1 sensor)
actions:
set config/externalwindowopen to open
Repeat above.
And the next automation:
“when any window is closed, and if all (other) windows are closed, set config/externalwindowopen to closed”.
For this, you need to create a rule for every window sensor containing:
conditions:
open DX (for only this 1 sensor)
open EQ false (repeat this condition for every window sensor)
open EQ false (sensor 2…)
open EQ false (sensor 3… etc)
actions:
set config/externalwindowopen to closed
Repeat above.
These instructions will only work for up to 7 window sensors in a room, for more it is too complicated for me to explain here, as it will require virtual state sensors etc. I hope this should
Good morning @Swoop
as the creator of the Load Balancing Blueprint for Zigbee2MQTT mentioned, he makes use of the load_estimate and room_load_mean attributes of the TVR.
What does it need to have these exposed via the deCONZ-REST-API? To be honest, I’m still not familar with the DDF-Concept.
Maybe it’s also possible to expose the “external_measured_room_sensor” attribute to substitute the “internal measurement” as state. It’s anoying to have the internal sensor value as current TVR temperature in Home Assistant.
@Thomas thanks again for pointing me in the right direction.
If I would have a free wish, then it would be an expert mode for editing Gateway Rules within HUE Essentials wich simply takes care of the syntax and let choose or fill in the operators and entities.
If that’s out of your scope, I would wish to use my purchased Android Key on the Windows version of Hue Essentials.
Hi, i have been following this topic for a while now and have not seen any updates for a while. I would really like to see the the following exposed through the rest api:
config/LoadRadiatorRoomMean
state/LoadEstimateOnThisRadiator
I have a room with 5 radiators off different size and shapes, and almost all the time one or more of them ar cold while the others are hot. Im pretty sure updating config/LoadRadiatorRoomMean with the mean of state/LoadEstimateOnThisRadiator all the radiators will help a lot on this problem.
I would like to help or contribute in any why i can to make this feature available. I can do testing, probably also some coding if that would help, or whatever is needed.
Looks like a great source of knowledge I wasn’t aware of 
