Apologies in advance if it’s all in the documentation. Have been unable to find anything, though.
The configuration: A zigbee thermostat (Ubisys h1) on every radiator. A zigbee thermometer (LUMI air monitor) in every room. HA with Zigbee Home automation (ZHA) integration. A schedule for each radiator for setting termperatures depending on anticipated occupancy of each room. For instance, the bedroom will be heated to about 19.5 °C when we’re going to bed and again when we get up in the morning. The temperature will be allowed to drop to 16.5 °C at all other times.
The problem: The thermostats are all, of course, attached to the radiator and exposed to the hot water tubes leading to and from the radiator. Therefore, the temperatures as reported by the thermostats are widely off, by as much as 8 °K. The difference to the actual room temperature varies with the outside temperature. When the heating has been turned off for several hours, the temperature reported by the thermostat will match the actual temperature in the room as reported by another thermometer which is some distance from the radiator.
Actually, one of the thermostats even reports a higher temperature when other rooms are being heated. This is so because the tubes feeding those other rooms run underneath that thermostat.
So: How can I control the temperature in my rooms by the readings of the actual temperature as reported by the external thermometers instead of the reported (wrong) temperatures by the thermostats?
I think the answer to this question will be based on how you currently control the TRV’s?
If they are exposed to HA as a simple switch (on/off) then my besty bet would be to use the generic thermostat option as this will allow any temp sensor that is exposed to HA to be the control sensor.
Take a look here:
If they are controlled some other way, let us know as there is normally always a way, might just need to approach it differently.
I do this using node-RED flows. Each morning it sends the day’s schedule to the TRVs based on expected occupancy that day. Then it monitors the wall sensors and dynamically adjusts the TRV calibrations. Cheating, really but it works. I also make the main hall thermostat follow radiator demand rather than the hall temp. I use influx & grafana to visualise it all. I also have node-RED install a new schedule on command from a zigbee button press when the expected usage of a room changes. Still tweaking and will document it eventually.
@rossk: I did try using the Generic Thermostat, but the device I am using is exposed to the ZHA as a complex thing. One of its entities is actually called a thermostat which in turn seems to consist of several data items, none of which I have been able to access. Another entity seems to be called a HVAC which seems to represent the on/off state of the TRV. However, it uses values other than on/off to represent on and off, respectively. I’m stumped.
@zillion42: that looks very much like what I’m looking for. Thanks a lot for the pointer.
@hunterdrayman: that looks like a very advanced version of what I’d attempt. But then, I’m a complete noob and still trying to learn HA. Learning to handle Node Red at this time seems like a formidable projekt in its own right at the moment.
@popch It’s true that node-RED involves quite a lengthy learning curve but I’d say it’s not a steep one (after the first mile or so) and I’ve been able to do things easily with node-RED that I couldn’t accomplish in regular automatons, so it’s been worth the effort.
You can probably find a way of controlling the TRV calibration without node-RED.
Other solutions I’ve seen involve turning the TRV into a dumb device and letting HA do the work. I don’t like this because of what happens when your HA server is down. The BRT-100-TRVs that I have are very smart - their only major flaw is that their function is not well documented.
I found that when I did it, my TRV’s did not have a switch I could integrate with the generic thermostat. So I ended up created an input boolean as the switch, then when that changes, it fires an automation that either turns the target temperature up high, or very low, which effectively gives me ‘on’ or ‘off’
At first, I tried the Better Thermostat. Even though the description reads as if it was a solution to my very problem, it turned out that it controlled about six of my ten TRVs (thermostats) quite well, two TRVs from time to time and two not at all, leaving one at the hot position and the other one at the cold one. If that’s better, it’s still not good enough.
My solution now consists for each room of:
one or two TRVs, one temperature sensor, one input_number for the busy temperature setting, one input_number for the unoccupied temperature, one input_number for the computed target temperature, one schedule for selecting the busy or lazy temperature, one automation which selects the target temperature according to the day of time and one automation which turns the TRVs on and off depending on the room temperature.
It’s not a pretty solution but it’s a working one, so far.
I think that’s quite a lot of software for a very marginal functionality. However, my rooms are cozy and we now see where we can reduce the heating without much loss of comfort.
Same, Better Thermostat broke my TRVs connexion a couple of time. To make sure of it and reassure me I was not going crazy, I set half of my TRVs with it, other half without. And systematically BetterThermostat resulted in abnormal behaviour with very hot or very cold.
