NodeRED is brilliant. Each time I have a “lightbulb moment” I can easily (or sometimes after a bit of a struggle) execute it in my favourite automation software. This idea came to me after a conversation with a work colleague. He asked me about the impact of the radiator’s heat on the internal temperature sensor of the Moes ZigBee TRV I covered in my previous post. These thermostats come with a calibration setting that assures correct operation. Why calibrate something manually, when you can get NodeRED to do it for you?
Why TRV is lying to you?
Even calibrated TRVs lie to you. Due to proximity to the radiator, Moes ZigBee TRV will report the temperature much higher than the temperature in the actual room. Without calibration, the skewed result from the internal temperature sensor will close the valve before the setpoint temperature of the room is reached.
Calibration tells the TRV to offset the actual reading by a specific number to compensate for the proximity to the radiator. The offset will differ for each thermostat, as it’s influenced by the TRV location, radiator size and heat convection. It all sounds great, but there is a catch. What happens to the temperature reported by the TRV if the radiator is cold?
I doubt that Moes ZigBee TVR is clever enough to figure out that offset needs applying only when the radiator is hot. A price tag on the device this complex would be much higher. The thermostatic valve applies a fixed offset to the temperature sensor to deal with the situation and mitigate the issue by averaging the error.
You should calibrate TRVs when radiators are hot. The problem is that the thermal radiation rate from the heat source isn’t fixed. It looks like an exponential curve. The hotter the source the more heat it bleeds. The colder it gets, the more inaccurate calibrated sensor will become.
In general, not a big issue
In my Moes ZigBee article I stated that with careful calibration, it would be possible to do away with all other temperature sensors I have in my home. I still stand by this, especially if you don’t have sensors in every room. From two possible scenarios, it’s best to have your TVR read lower temperatures when not in use, then higher ones when you are trying to reach a setpoint.
As long as you don’t rely on TRV’s internal temperature sensors to tell you how cold the room is, your heating will be on point. It’s a good practice to have one or two sensors at home and use them to report back the actual home temperature.
Fixing it with more sensors
In my Moes ZigBee TRV article, I stated, that you can only control the setpoint on each TRV, not the valve position directly. At first, I thought I would simply overcrank the setpoint (set it to 30℃ or 10℃ depending on whether I need the TRV to open or close) and use the array of temperature sensors I already own to control the heating. While this is a still viable strategy, it seems smarter to dynamically control the calibration value instead.
I can submit the calibration value dynamically to each TRV based on the difference reported by the valve and a dedicated sensor. The updates are frequent on both sides to assure the accuracy of this feedback loop.
Hidden benefit
It also came to my attention, that others may end up with thermostats located in different, then heated, areas. This is especially true for floor heating. Thanks to the auto-calibration script, you can calibrate your TRV against any temperature sensor – including ones located in different rooms. If this is the goal you want to reach, this project will work for you as well.
Things to keep in mind
As the calibration is crucial to correct operation, I have to deploy some precautions to make sure I only calibrate the TRV based on the readings taken in a similar timeframe. I have no use for the offset figure if one is calculated against the temperature taken 20-30 min ago. In that case, I can either retain the previous calibrated value or revert back to a default calibration offset.
I can also merge both, and if I can’t obtain 3 calibration figures in a row (each time retaining the previous offset), I would go back to the default value until a correct calibration figure is available. Either way, my ZigBee temperature sensors are not going anywhere! I have even more reasons to use my ZigBee battery monitoring project to catch sensors with low batteries early.
Testing, 1… 2… 3… testing
What I said before, was a theory. It’s time to confirm it with some facts. What better presents the facts than a set of pretty charts displayed by Grafana and InfluxDB (if you fancy the same setup, I have a tutorial that guides you step by step to get that).
In my testing scenarios, I placed 2 TRVs near the radiator (so simulate the thermal radiation in use) alongside another temperature sensor to get neutral readings near the radiator and a few meters away to get an overall room temperature.
1st scenario
To verify, that in fact, the calibration offset isn’t clever, I applied a fixed offset to one of the TRV and left the other one reporting the temperature without it. As you can see in my graphs, the temperature between these two was almost always consistent. Both TRVs were over-reporting, in a similar manner. This proves that there is no funny business going on regardless of temperature changes and offset applied to the TRV.
The issue caused by the linear offset of the TRV 1 is already visible on the graph. The TRV only reports correctly when the radiator is bleeding just the right amount of heat and it is under-reporting when the radiator is cold.
TRV 2 without the offset applied has the complete opposite pattern. It reports a correct temperature when the radiator is cold and over-reports when the extra heat from the radiator is reaching the temperature sensor. In either calibration scenario, you are being lied to.
Self-calibration scenario
In my self-calibration scenario, I applied the calibration script to the TRV 1 and left the other one without offset applied. Thanks to the exchange between the room temperature sensor and the internal sensor of the TRV, I’m able to compare the two values, calculate the correct offset and apply it for the next reporting interval.
I apply the calibration when 2 conditions are met to assure the consistent accuracy of the data:
- The temperature difference is greater than 1 degree
- The room temperature reading isn’t further apart than 15 min
This provided a pretty accurate temperature reading from the internal temperature sensor. I set the tolerance to be 1 degree, and if the TRV reports a value higher/lower than a threshold the calibration script kicks in applying a new offset. This brings the temperature curve close to what my room temperature sensor is reporting and paves the way for setpoint driven operation from my DIY Smart Heating system.
TRV auto-calibration script
The script in NodeRED takes care of this. You will need to pair each TRV with a dedicated temperature sensor (unless you rather use a manual calibration). Values are compared each time a new room temperature is recorded by an external sensor. By default, calibration is done within 15 min between the TRV update and the room temperature update, which seems to be working well.
One thing that I discovered during testing, is that when the calibration offset value is sent back to my TRVs, these will report back with a full payload including new offset, but old internal temperature reading. As this would lead to incorrect values in my calibration script, I simply suppressed the feedback for 10 sec.
The last thing to note is that the calibration offset is applied instantly to the TRV, but the local temperature usually updates every 10-15 min – and you won’t see a correct figure until the next TRV update.
For the best consistency, I strongly suggest using sensors with a frequent polling rate. If you don’t know which sensors are these, I’m working on a comparison of ZigBee sensors – so consider following me if you want to see the data from these tests.
Final thoughts
My TRVs are no longer lying to me. This project is a lead into the v4 of my Smart Heating system and it will assure, that the valves are acting in the correct way. Only time will tell if I’m going to stick with these setpoints, or if I’m going to switch to overdriving methods to keep actuating my valves. Let me know what features would you like to see in your Smart Heating. Are you going to invest in TRVs? Let me know in this Reddit thread.
Project Download
Download project files here. Bear in mind that Patreon supporters have early access to project files and videos.
