HR92 not responding correctly

[HenGus]

Clearing binding at the HR92

1. Press the button.

2. Hold the button pressed for 5 seconds.

3. Select bind using the adjustment dial and keep the
button pressed until cleared is displayed. Binding is deactivated.

[dty]

Thanks HenGus. I've now done this:

1. Wiped bindings on both HR92s
2. Deleted zone from controller
3. Recreated zone with schedule, etc.
4. Added good HR92 to zone
5. Created new zone
6. Duplicated schedule from other zone (don't want the two to fight!)
7. Added "bad" HR92 to new zone

[dty]

Out of interest (and tangentally relevant), if there are multiple actuators in a zone configured as single room (not multi-room), does Evohome learn about the thermal performance of each one individually? That is, can the valves be open different amounts, or do they always work in lock-step?

[DBMandrake]

Out of interest (and tangentally relevant), if there are multiple actuators in a zone configured as single room (not multi-room), does Evohome learn about the thermal performance of each one individually? That is, can the valves be open different amounts, or do they always work in lock-step?

That is an excellent question, and although I've thought about this before I haven't seen anyone talk about it.

The Evohome controller only distributes the current room temperature (and set point) to the HR92's - it's up to the individual HR92's to decide how much to open their valve - and they are a full PID (or at least PI) controller in their own right, so the decision on how much to open the valve depends not only on the current set point and measured temperature differential, but also based on past trends (integral term) and predicted system response time (differential term) and these PID tunings are adapted over time using feedback heuristics. This is all done internally to the HR92.

So although I don't have any hard data to back it up I believe that yes, multiple radiator valves in a single room zone can and almost certainly do open to different amounts, especially when you consider that differences in radiator valves may require it.

In fact I can also see a potential issue where multiple radiators become "unbalanced" in their output due to one feedback parameter (measured temperature) controlling multiple radiator valves each with their own separately learning PID controller... with the sum heat output of both radiators affecting the feedback variable of temperature. Over time multiple HR92's may diverge (especially the integral term) and result in one radiator putting out more heat than another one in the same zone when in the proportional band. As I don't have any two radiator zones currently I am not able to test this theory, and perhaps there is something that I've missed in the system that would help prevent this sort of instability.

Has anyone with an HGI80/Domoticz and a single room multiple radiator zone checked to see if the radiator valves in the same zone report the same or different heat demand figures ?

[paulockenden]

So although I don't have any hard data to back it up I believe that yes, multiple radiator valves in a single room zone can and almost certainly do open to different amounts, especially when you consider that differences in radiator valves may require it.

You are correct. However I've just gone to grab a screenshot to prove it and the three rads in one zone all have the same heat demand! Sods law. You'll have to take my word that they usually show differences.

Although I guess at least this balance shows that divergence isn't an issue!

P.

[HenGus]

Thanks HenGus. I've now done this:

1. Wiped bindings on both HR92s
2. Deleted zone from controller
3. Recreated zone with schedule, etc.
4. Added good HR92 to zone
5. Created new zone
6. Duplicated schedule from other zone (don't want the two to fight!)
7. Added "bad" HR92 to new zone

And, has it worked?

[dty]

And, has it worked?

Well... it "works" in that, the rad warms up, etc., but it was doing that before. I'll need to leave it at least a week or so before I claim victory. Obviously, if it goes wrong in the mean time, I'll invoke Rameses and see what he thinks.

However, I don't have zones to spare, and having two sensor/actuator pairs in the separate zones in the same room is clearly not a long-term solution! But the act of unbinding and rebinding may have cleared out a problem, in which case I should be safe to re-add the "duff" one to the same zone as the other one.

But I'm getting ahead of myself...

[dty]

You are correct. However I've just gone to grab a screenshot to prove it and the three rads in one zone all have the same heat demand! Sods law. You'll have to take my word that they usually show differences.

Although I guess at least this balance shows that divergence isn't an issue!

P.

I've only got one zone with multiple sensors that's configured as a single-room zone. Since I've been paying attention to it, I've not seen it show different heat demands.

[dty]

So here's something interesting. Two heads in the same single-room zone asking for different head loads, and the Domoticz numbers don't match the valve positions. Both heads report valves at 28% (and both rads are hot, so the 40% thing might be misleading too), but are requesting 32/200 and 54/200.
IMG_1367.jpg

[DanD]

Hi,

I've done a quick check of a few of my HR92s vs Domoticz and I can confirm that the valve position shown on the HR92 is exactly half the demand value shown in Domoticz (due to its 0-200 range). One thing that's worth checking is that your HGI80 & Domoticz are getting a good signal and aren't missing any changes in the heat demand value sent out by the HR92 as this could also be causing a mismatch (check the last updated timestamps in your devices list). There is also a couple of minutes lag before the HR92 sends out its new heat demand value which also might cause a brief temporary mismatch.

With regards to your earlier question about how multiple HR92s behave in a single-room zone set-up. I believe that they do operate independently with regards to their heat demands. I've just looked at the data from one of my single-room zones and the heat demand values from the two HR92s are pretty similar, but not identical.

Dan

[dty]

I thought I'd included the time stamps, but it seems I posted the wrong screen grab and now I've deleted it.

The devices were being received OK, because the temperature readings were updating fine. There was a period of about half an hour where the temperature readings of both were updating, and only one of the heat demands updated one time. But that's OK. I've not ready the protocol documentation in detail, but I suspect the temperature reading and heat demand are separate messages. In this instance it seems that no heat demand messages were sent for the period - presumably because no change was required. So that's all fine.

What's odd is that the valve position and the heat demand didn't correlate. Spot checks I did previously suggest they do. But they were just spot checks. Perhaps they "mostly" do, but not always?

[DBMandrake]

The devices were being received OK, because the temperature readings were updating fine. There was a period of about half an hour where the temperature readings of both were updating, and only one of the heat demands updated one time. But that's OK. I've not ready the protocol documentation in detail, but I suspect the temperature reading and heat demand are separate messages. In this instance it seems that no heat demand messages were sent for the period - presumably because no change was required. So that's all fine.

You have to think about an HR92 as a dual function device - it is both a temperature sensor and an actuator, effectively it is two devices in the same packaging and these two sides of it work independently. In fact on the HR80 you had to manually bind the temperature sensor side of it and the actuator side of it independently and one at a time!

On the HR92 the binding process is simplified to only one binding from a user interface perspective but there are still two devices in one and actually two bindings.

Temperature readings are sent from the sensor side of the device, while heat demands are sent from the actuator side of the device, so yes they are completely separate messages.

Heat demands will only change when the valve moves position, and it tries to minimise unnecessary movements as much as possible for optimal battery life so you'd typically see more temperature sensor updates than you would heat demand updates, especially if you were not right in the proportional band.

What's odd is that the valve position and the heat demand didn't correlate. Spot checks I did previously suggest they do. But they were just spot checks. Perhaps they "mostly" do, but not always?

Are you sure its not just time lag, as DanD suggests ? Or lost transmissions ? (collisions etc)

[dty]

Are you sure its not just time lag, as DanD suggests ? Or lost transmissions ? (collisions etc)

It's impossible to answer that question! But given that the temperature readings were making it through OK, I'd guess there was no issue and this is expected behaviour.

[dty]

How much does the radio board cost and would you consider sharing the firmware ?

I could really use an HGI80 but I just cant justify (or afford) the cost of one, but I have Raspberry Pi's coming out my ears...

Just following up on this (again!), I've started a new thread about this here: http://www.wordpress-1219309-4387497...-without-HGI80

[dty]

Well... it "works" in that, the rad warms up, etc., but it was doing that before. I'll need to leave it at least a week or so before I claim victory. Obviously, if it goes wrong in the mean time, I'll invoke Rameses and see what he thinks.

However, I don't have zones to spare, and having two sensor/actuator pairs in the separate zones in the same room is clearly not a long-term solution! But the act of unbinding and rebinding may have cleared out a problem, in which case I should be safe to re-add the "duff" one to the same zone as the other one.

But I'm getting ahead of myself...

So no, it appears to have gone wrong again. It's currently calling for 21% heat, despite being 8C below the set point. Seems like it just stopped bothering some time in the middle of the night.

DomoticzChart4.jpg

What next, Rameses?