HR92 not responding correctly

[dty]

Hello all,

I'm having some issues with one of my HR92s and I just wanted to make sure it's not me being thick.

My study is an odd shape. One half of it has a mezzanine floor. So, standing on the ground floor, there is a ceiling above you at a normal-ish height. The other half has a spiral (well, helical!) staircase up to the mezzanine, and as such it's open to the floor above.

Under the mezzanine, I have a small-ish radiator. At the end of the room where the staircase as, I have a larger (but not large!) radiator. There is no heating in the upstairs part. (In fact, there's no cavity wall insulation either, as you'll see from the following graphs, but that's not directly relevant). Because of the shape of the room and the uneven heat demand, I've set this zone to be a multi-room zone so that each radiator can respond according to its local demand. The larger radiator at the open end of the room will clearly need to work harder since a lot of its heat will be going straight upstairs.

Here is a capture from my Domoticz monitoring showing the problem.

DomoticzDevices.jpg

You can see from the table that the smaller radiator (#604) is only calling for 14% heat, despite being 6C below the set point! The larger radiator (#530) seems to be doing its job just fine, but it's struggling to heat the room on its own as you can see from the following graph:

DomoticzChart.jpg

You can see from the graph that the square-wave is the set point. Currently, it's set to 18C. You can also see that the small radiator (I'm going to call the line yellow, but I'm colour blind!) just isn't heating at all. And you can see from yesterday (pink line, maybe) that the larger radiator did its best, but just couldn't manage with all its heat going straight up to the top floor.

Some days, however, it works just fine, as you can see below. (It never quite reaches the set point, but I believe that's because of the shockingly poor insulation, which is being dealt with.)

DomoticzChart2.jpg

So, basically, sometimes the HR92 on the small radiator simply can't be bothered. And sometimes it's fine. It seems like the underlying problem is that it's only calling for 14% heat, when it should be calling for 100% heat. This suggests to me that it's the HR92 that's at fault, not the plumbing/radiator. If I remove the HR92 and manually open the valve, the radiator heats up quickly (assuming there's a call for heat somewhere else and the boiler is on, of course).

Any suggestions?

[DBMandrake]

Where are you getting the 14% heat demand figure from ? I don't see it in the table or graphs. Are you using an HGI80 ?

What does the Valve position (option 10 in the HR92's menu) say under the conditions where you think it's at 14% ? The valve position and heat demand don't follow a one to one relationship (since the valve position includes learnt valve pin calibration) but they do move up and down together in unison.

Have you tried rebooting the HR92 by removing the batteries and reinserting them ? Just a few days ago I had a situation where my bathroom HR92 didn't seem to be sending any heat demand - turning it up caused the valve to open as expected, and the new set point was even reflected on the controller screen, but the boiler relay failed to come on. I tried turning it right down then up again two or three times and still no response from the boiler relay. At the time no other radiators were calling for heat so I turned up the hallway radiator and the boiler relay came on immediately then went off again when I turned it down but the bathroom one refused to play ball.

I removed and reinserted the batteries on the bathroom HR92 and it has worked fine since. I suspect its an obscure bug in the HR92's firmware - I've seen one or two reports of this kind of behaviour on the forum over the last year but it seems very uncommon and it's the first time I've witnessed it first hand.

[dty]

The 14% comes from the Domoticz table. Where is says "On: 28". It's on a scale of 0-200! So when things are flat-out they say "On: 200" - like the large rad does. Yes, I'm using an HGI80.

After posting, I unclipped the head from the body and re-attached it, and it cycled the valve (which it seems to do every time I unclip, so I guess this is normal), and then immediately demanded 100% heat, and promply started heating up very quickly.

I hadn't considered off-and-on-again! I'll give it a go next time I see the problem. For today (and maybe 3 or 4 days hence), it's fixed now.

[dty]

I've checked the valve positions (not that the problem is occurring right now...) and the small rad is reporting 53% (and Domoticz is showing a demand of 106/200 = 53%), and the large rad is reporting 95% (and Domoticz is showing a demand of 190/200 = 95%). So, at the moment at least, the valve position and the demand seem to be tracking one another.

[DBMandrake]

I actually meant a full battery out reboot - but its interesting that unlatching it and latching it again was sufficient - this triggers a pin travel learning cycle where it will re-learn the pin travel limits so that it can calibrate 0-100% pin travel.

Is it possible it wasn't latched on securely ? An HR92 won't send a heat demand (or perhaps continue to send the last known heat demand ? Must test that...) when the latch is not closed, however it will also stop it from turning the motor, so shouldn't in theory stop sending heat demands yet still allow the motor to adjust the valve...

[dty]

I doubt it wasn't latched properly. I'm aware of this as an issue, and the latching action is pretty positive. Plus, it seems to work for 3 or 4 days, then stop for a couple, then work again, then stop again.

Just re-checked the valves vs Domoticz. The demand is dropping now as it nears the set point, but the Domoticz number and the valve position still match (adjusting for the scale).

[DBMandrake]

I've checked the valve positions (not that the problem is occurring right now...) and the small rad is reporting 53% (and Domoticz is showing a demand of 106/200 = 53%), and the large rad is reporting 95% (and Domoticz is showing a demand of 190/200 = 95%). So, at the moment at least, the valve position and the demand seem to be tracking one another.

Ah - that is very interesting, because nobody with an HGI80 has ever confirmed the relationship between the reported valve position and the transmitted heat demand before. (I don't have one)

That has some interesting implications, because not all valves calibrate to open at the same percentage! Usually it tries to calibrate so that a valve just starts opening at 40% indicated pin travel, but that would imply that it is already sending an almost 40% heat demand (which would run the boiler ?) before water is even flowing through the radiator, which seems unlikely.

I've also noticed on some of my radiators that after a few days the calibration must shift because it starts reporting lower figures like about 20% as being the point where the valve just starts to flow. Hmm...

[dty]

I've just checked a handful of other HR92s (I've got 12, and I've only covered the downstairs so far!!!), and they Domoticz number "matches" the valve position.

[DBMandrake]

I've just checked a handful of other HR92s (I've got 12, and I've only covered the downstairs so far!!!), and they Domoticz number "matches" the valve position.

Thanks for confirming that - we've just reverse engineered one more fact about how the system works...

Somebody with an HGI80 needs to capture a table of heat demand figures taken from a variety of conditions over time for analysis so we can work out what algorithm is used to combine all the individual heat demands from the HR92's to the final heat demand sent to the boiler relay - because now we know the HR92's are just sending raw valve pin travel figures as their "heat demand" (which will have a very non-linear relationship with actual water flow through the radiator, since there is a lot of dead band at each end of the pin travel where water flow doesn't change) the Evotouch must be applying some additional intelligence to these received heat demands when calculating the overall system heat demand to send to the boiler relay.

For example if all radiators except one were completely closed, but one was near the set point with a "heat demand" of 20%, that is actually below the valve opening threshold on most TRV valve bodies (no water will flow) so you wouldn't want the boiler to fire up at a 20% duty cycle when no radiator will actually make use of that heat...

[paulockenden]

because nobody with an HGI80 has ever confirmed the relationship between the reported valve position and the transmitted heat demand before.

Pretty sure I have. Unless I dreamt I did it!

[DBMandrake]

Pretty sure I have. Unless I dreamt I did it!

Must have missed it.

But as I say, it does have some interesting implications, in that the Evotouch must use additional intelligence to figure out whether the "heat demand" from an HR92 is actually sufficient to allow water to flow through that radiator - and that threshold is going to be different for every radiator!

Initial calibration does tend to set that at about 40% indicated pin travel on all my radiators, but for some reason most of mine always drift out of calibration (towards a lower figure) over a period of a few days. I think this is caused by a gradual "re-calibration" process occurring each time it winds the valve to the limits, causing a gradual change in where the perceived 0 and 100% locations are.

[paulockenden]

because now we know the HR92's are just sending raw valve pin travel figures as their "heat demand"

We don't. You're assuming the figure on the LCD is the raw pin travel. It might be, or it might be the post-calibration value.

P.

[dty]

Well, I don't *actually* have an HGI80 - I have a Raspberry Pi with a radio board on in and some custom written firmware (by me) which reads the radio signals and pretends to be an HGI80 for the benefit of Domoticz. But the firmware is just decoding the (well-documented) radio signal and presenting it as text. It's certainly not placing any interpretation on what it receives whatsoever. It's basically "received this message with this type, these addresses and these fields". So I'm 99.9999% sure it's doing exactly what the HGI80 would be doing.

The fact that I can also send commands from Domoticz via my firmware and the radio to Evohome without any problems also supports the "it's just a radio to text conversion" premise!

[dty]

Initial calibration does tend to set that at about 40% indicated pin travel on all my radiators, but for some reason most of mine always drift out of calibration (towards a lower figure) over a period of a few days. I think this is caused by a gradual "re-calibration" process occurring each time it winds the valve to the limits, causing a gradual change in where the perceived 0 and 100% locations are.

How do you know what this calibration is doing, and where do you get the 40% figure from?

[DBMandrake]

We don't. You're assuming the figure on the LCD is the raw pin travel. It might be, or it might be the post-calibration value.

Not sure what you mean by "post-calibration" value ?

I'm not assuming anything - I've taken measurements and studied the calibration process quite closely.

The percentage figure displayed is a linear percentage of pin travel where 0% represents the pin fully depressed position and 100% represents either a certain fixed pin travel from fully depressed (which is increased in stroke 1 mode) or the hard limit stop in the radiator attachment with the black wheel, whichever comes first. After the depressed and open positions are found the range of travel in between is scaled to 100% and the valve position is kept track of using dead reckoning by counting motor revolutions.

Calibration works like this:

When you close the latch and calibration is initiated a minute later it will start turning to depress the pin. It will do this until a certain threshold of resistance is met from the pin or the limit stop in the mounting attachment is hit. If you close the latch without it being on the mounting attachment (allowing the motor to turn forever) it will keep turning looking for the closed point for a few minutes before giving up.

It will be either measuring the motor speed slowing or possibly the motor current increasing to work out when the force exerted on the pin has reached a preset limit. When this limit is reached it stops and this point is calibrated as 0%.

Stroke 1 mode increases the motor torque, and as a consequence in stroke 1 mode the pin depressed position will be calibrated a bit further down. Stroke 1 will therefore make it close "harder" for valves that are difficult to close.

It needs some sort of threshold detection system to find the closed limit because in the closing direction a valve pin doesn't move freely and suddenly hit a hard stop - you are compressing an o-ring so it has some give, so you have to have a force threshold at which you consider the valve to be closed.

When the closed position is calibrated the 100% open position is initially "assumed" based on a fixed number of motor revolutions from the closed position. In stroke 0 mode the number of revolutions is typically NOT enough to hit the limit stop on the attachment - I find it typically stops short by about half to one turn, and in fact on my valves, 100% open in stroke 0 mode isn't full water flow. In stroke 1 mode the assumed number of turns is significantly greater and what I have seen is that it always results in it hitting the limit stop the first time it goes to 100%. So as well as making the valve close harder stroke 1 also makes it open further.

The first time it tries to fully open the valve after calibration, if the motor hits the limit stop before an indicated 100% is reached it immediately re-calibrates this as the new 100% and re-scales the entire range from 0 to 100% based on this new position. You can clearly see this happen if you watch the valve position figure while it opens - it might get to say 90%, hit the limit stop then jump to 100%.

It's also the case that if in the future it is ever trying to close the valve completely down to 0% and the force to do so becomes excessive before it reaches 0% it will re-calibrate the 0% position as well. Say your valve gets sticky when it gets hot (I think a couple of mine do) and it tries to close the valve completely when the schedule goes to 5 degrees - it gets to an indicated 10% before it finds it too hard to turn, it then stops and makes this point 0% and once again scales the rest of the range based on this new figure.

Now a pin position that used to be represented by 40% could now be 30% as the physical travel between 0-100% has be re-scaled. I believe that a sticky valve triggering a re-calibration of the 0% point is what causes the "calibration creep" that I see over time, where less of the valve pin movement is used and the purported opening point creeps down from 40% to about 20%. (It's the same position, really, it's just the 0% position got re-calibrated further up due to the sticking pin)

From what I can see on the fly re-calibration only ever shrinks the working range of the pin, it never increases it - to increase it again you have to trigger a full re-calibration.

How do you know what this calibration is doing, and where do you get the 40% figure from?

40% comes from just observing when the valve starts to flow - most of my radiators have enough hiss to be heard when they start to flow.

So for example say that the valve has recently done a full re-calibration due to being re-fitted - if I adjust the temperature in half degree steps around the set point until I find the point where the valve JUST stops and starts audibly flowing, this is the opening point of the valve where the o-ring seal is just starting to lift off the seat - typically this seems to happen at about 30-40% indicated pin travel. Any position lower than this is closed and just the o-ring being compressed further. EG 20% will be no flow, so will 10% and 0% - it's all dead band as far as controlling the flow of water is concerned.

What I notice with calibration creep is over a few days or weeks a radiator that initially started flowing at about 40% will now start flowing at an indicated 20% or so and have to be brought right down to about 15% to stop flowing - when this happens the room temperature is typically overshooting because it takes the heuristics quite a while to learn that it now requires a much lower "valve opening" to maintain the correct temperature.

Usually my first sign that a valve has suffered from calibration creep is when the room is a degree or more over temperature and yet the radiator still seems to be flowing heavily and is roasting hot to the touch - when I check the valve position figure it is typically down around 20% - which should be more than enough to close the valve but it is still flowing heavily. The reality is the valve hasn't changed, but the calibration of its travel range in percentage has changed.

If I then force a re-calibration of that valve and check again at what point its opening and closing, it will be back around 40% again and it will stop overshooting the room temperature, for a few days anyway...

This calibration creep induced temperature overshoot due (I believe) to sticky valve pins is why I will be changing my valves to Honeywell Valencia's...