If the room wasn't losing heat and it was within 0.2C of setpoint then no thermal input is required.
If the room wasn't losing heat and it was within 0.2C of setpoint then no thermal input is required.
So the display should indicate 17.5C as its over the threshold to call for heat.
So really the rounding applied when you change the setpoint should be applied to the temperature displayed.
So basically I should tell my wife to turn the temperature up by 1.0C to get a radiator to heat up.
If the radiator was previously off and you have turned it up to 17.5C when the measured temperature is already 17.3C that 0.2C difference won't be enough heat demand to exceed the minimum on time for the boiler if no other rooms are calling for heat. Turn it up another 0.5C and you should see some action.
Also, I don't think I've seen this discussed before, but when an HR92 goes to 0% valve pin position (fully closed) it goes into a sort of "sleep" mode where it won't produce any heat demand again until the set point is at least about 0.5C above the ambient, when it will "wake up". Whereas if it is already partially open then it will produce heat demand even at the set point.
So you would probably find if you turned it up to 18.0C then waited for it to open the valve, then turned it back to 17.5C it will close the valve a bit but still generate some heat demand. I've long noticed this behaviour (it can cause temperature cycling in low load conditions) but I don't know the reasoning behind why it is designed this way. (Personally I think it's a mistake, but it is baked into the HR92 firmware so can't be altered with an update...)
It always compares the true, accurate measured temperature to the set point for the purposes of controlling the radiator and generating heat demand. The "fake" temperature is for display purposes only and doesn't affect the temperature control algorithms.Is the temperature difference compared against the setpoint and the actual temperature or the "fake" temperature?
Last edited by DBMandrake; 12th November 2020 at 05:01 PM.
The answer to that unfortunately is "it depends". If a radiator is already putting out heat, turning it up 0.5C will have an effect.
However if the radiator is cold and your new set point is still very close to the ambient temperature as in your example, it may not be enough to "wake" the HR92 into opening the valve and calling for heat. In that case you would want to turn it up by 1C to ensure that something happens.
Is it possible to have a flame indicator (heat demand) for each zone you would then know if the zone is going to heat 🔥 up.
There is a fuzzy logic control in the device so it is not a flat delta T away from setpoint. At 17.3C RT and 17.5 SP at perhaps 10-15C outside temp the demand % will likely be very very low, maybe only a few %. The human body can't register a 0.2C temperature difference, about 1C is about average I believe, so from a control point of view there is no imperative to drive heat into the zone. However from a human point of view 17.3C is not a comfortable temperature for most people but this very much depends on activity level. If you feel cold at 17.3C then increase the temperature further and the system will respond!
AtM
Resideo employee. Comments are personal, and likely to get a hard stare from Rameses
How this all came about this week we were sitting in our lounge which is normally set to 19.0C during the day. Normally this is OK, but on this occasion it needed to be increased ( radiators were cold) so a small increase was required i.e. 0.5C increase. Turned up the setpoint nothing happened needed to be 1.0C increase to get the boiler to fire up.
In the evening the schedule is set to 20.5C which is fine. During the day we don't normally sit in the lounge for long periods. We are not fiddling.
Todays test highlighted the weird algorithm when you increase the heat by 0.5C the displayed temperature jumps by 0.5C a few minutes later.
In my test the actual temperature was obviously to high 17.3C to actually request any heat. So why doesn't the display actually show 17.5C so that increasing the temp by 0.5C will actually cause a request for heat. I know that the radiator valves will show a different temperature if this software change is made. This is a beta release so input from users should be considered overall this release is much better no overshoot of temperature.
I have some switches in Domoticz that implement a timed temperature boost in certain zones by requesting a setpoint of 22 deg with a TemporaryOverride with an until-time calculated at 20 mins from now.
It always worked regardless of whether economy mode was set at the controller or follow-schedule was active. That would seem to imply that the 'old' ECO mode did a one-off setpoint drop on selected zones when it was activated, but the controller ignored applying the -3 to any subsequent setpoint changes.
What I've observed lately is that when eco/boost is active in the beta firmware, this behaviour is different and the -3 deg offset is applied to any incoming setpoint requests - even after the initial act of enabling eco/boost mode.
Am I correct in deducing this or is something else playing out here?