Greyhound, the reason they're testing it under low load, is that if there's high load (for example -5 outside and +20 inside and poor isolation), that 1 minute of heat per 10 minutes will probably not raise temperature in the room. In that case, you won't notice the problem. It will seem like it's keeping temperature perfectly.
There's logic behind requesting heat even when 0.1 above setpoint. It prevents drops below the setpoint. But there's no logic anymore when it keeps getting warmer and warmer in the course of a few hours and it then still requesting heat 1.0 above setpoint.
Rameses: the problem occuris with ANY temperature sensor. HR80, HR92, Evohome and Round, located at GOOD spots. Also on the same spot as the old thermostat which does fine. Also, my own thermometers tell me the same thing (except that Evohome of course is always lie'ing a bit about the measured temperature, making it seem closer to setpoint than it is).
G4RHL, Evohome overshoots even further if you use it in thermostat-modus (no radiator valves involved), so it's more noticable in that case. Also, Evohome lies a bit about measured temperature. If it says 21.5 during setpoint 21, it might very well actually be 21.9. Have you confirmed with your own thermometers that it 'only' goes up and down 0.5? I expect it to be around 0.7-0.8 when using radiator valves.
Last edited by erik; 13th March 2015 at 07:00 AM.
Ignoring arguments over how the TPI algorithms should behave, the behaviour of other zones is clearly not correct. Can anyone else replicate this?
e.g. Zone A and B both previously set to 17.0 and both holding 17.0. Zone A is then set to e.g. 20. Zone A will heat up. Zone B will heat up. Zone B will only stop heating up at 18.5 (1.5 degrees above it's setpoint, the zone valve closes off).
Perhaps we should have a poll of what firmware we have, and whether we are happy with it.
v25 16Jan2014, and not happy...
Rameses - humour me, please tell me what firmware version the Evohome controller units are currently leaving your factory with, right now.
Honeywell thinks their software does not have critical mistakes in it, so they don't release updates. New units also have the same firmware. So far.
greyhound, you are correct. The radiator valve in zone B in your example should close much earlier. Letting it go 1.5 over setpoint is way too much.
Nest automatically updates their firmware for their customers, adding new features and functionality and enhancing their customers investment in their platform. The industry has changed from dedicated hardware devices to a combination of solid hardware enhances by agile software delivery.
greyhound1234 - Firstly - when you say zone valve - do you mean Hr92 on the radiator? If so then how do you know this is open?
There is no way the Hr92 will call for heat unless your at set point (and been falling) or below) - it will then 'trickle' the water in to attempt to control the temp of the rad (at 17 degree) - are you saying that the radiator (zone b) is on and warm (and I mean was not getting hot water)? Or are you just looking at the room temp?
Is Zone A linked to Zone B? (next door? linking room? etc)
getconnected.honeywell.com | I work for Honeywell. Any posts I make are purely to help if I can. Any personal views expressed are my own
There are no firmware changes to the controller.
There are and have been firmware changes to the gateway - which provide enhancements, such as schedule editing etc - future enhancements are road mapped.
getconnected.honeywell.com | I work for Honeywell. Any posts I make are purely to help if I can. Any personal views expressed are my own