If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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
Which is an argument that the value shown *isn't* pin position. Your radiator valves don't start flowing at different points over time.
That's what I meant by the value being 'post calibration'.
Which is an argument that the value shown *isn't* pin position. Your radiator valves don't start flowing at different points over time.
That's what I meant by the value being 'post calibration'.
P.
Right, I see what you're getting at.
But as far as the HR92 controlling the valve in response to the temperature is concerned, it is the pin position - it has to figure out where the limits of travel are somehow, as every valve will differ.
The real problem is that it keeps adjusting that calibration "ad-hoc" while in use if it runs into any problems like stiffness in the valve. I think that's the real issue. It should be a bit more lenient of the valve being a bit stiffer at its limits in normal use without performing these re-calibrations. This would lead to more consistent performance over time. Of course it may only be an issue with poor quality valves like mine.
Hmm... it appears to have immediately gone wrong again. The graph shows it coming up to temperature at 10:20 - immediately after my first post when I removed it and replaced it on the valve body. But having got up to temperature, it's then just stopped. The Domoticz data shows it currently requesting 44% heat, despite it being almost 4C below set point. (Note that I've renamed my devices in Domoticz since my first post. Sorry for the confusion!)
Hmm... it appears to have immediately gone wrong again. The graph shows it coming up to temperature at 10:20 - immediately after my first post when I removed it and replaced it on the valve body. But having got up to temperature, it's then just stopped. The Domoticz data shows it currently requesting 44% heat, despite it being almost 4C below set point. (Note that I've renamed my devices in Domoticz since my first post. Sorry for the confusion!)
[ATTACH=CONFIG]916[/ATTACH]
[ATTACH=CONFIG]917[/ATTACH]
Before you set the zone to multi-room mode, were there any other sensors bound to the zone or were there only ever the two HR92's ?
Assuming the latter, which one was originally bound first as the temperature sensor for the zone when it was originally a single room zone ? The one on the big radiator by any chance ? Which one's temperature shows on the controller ? (Only the first or primary one will show in a multi-room zone)
Just a hunch, but try this: Change the zone back to a single room zone, wait 10 minutes, then change it back to a multi-room zone, and wait another 10 minutes, then see how it behaves.
What I'm wondering is whether the change to multi-room zone may not have been communicated to the small radiator HR92 properly. In that case if the large radiator HR92 was originally the primary sensor for the zone the small radiator HR92 might still be acting as a slave to the temperature reading from the other one.
For a bit of background that explains my hunch, single vs multi-room zones seem to work like this: (I don't have an HGI80 so some of this is worked out empirically, so it may not be 100% correct, but I think it is right)
In a single room zone all devices with temperature sensors will still broadcast their temperature reading, (hence you can capture them all individually on an HGI80) but only one of these is "listened to" by the controller, which by default is the first device you bind to the zone whether it be a wall stat or HR92. On the Wi-fi controller model you can choose a different sensor later in the zone configuration without rebinding - this just tells it to "listen to" a different temperature sensor.
This temperature reading is the one displayed on the controller, and more importantly the one that gets relayed back out to all actuators, eg HR92's. The interesting thing is that even if you only have a single HR92 in a single room zone, the temperature reading is sent from the HR92 to the controller, and then sent back to the HR92 again before it is used to control the actuator. This is why the temperature reading on an HR92 lags behind the reading on the controller by a few minutes even when the HR92 is the sensor! It doesn't use its own temperature measurement directly even though it is the only HR92 in the zone. At least not in single room mode...
In multi-room mode what seems to happen is that a configuration bit is sent to all the HR92's in the zone that says "use internal sensor" instead of "use remote sensor", where remote sensor is actually the reading being relayed back from the controller, regardless of where it originated from.
What I'm wondering is whether your big radiator was your primary HR92 in the original setup and when you changed to multi-room mode the small radiator HR92 remained stuck in single zone mode, thus its trying to adjust itself based on what is measured at the far end of the room.
Give my suggestion a try anyway. If that fails perhaps try rebooting the controller. I've seen a number of subtle but very weird behaviour problems over the last year that have been solved by a controller reboot.
One more thing: Do you have room temperature display on both HR92's enabled ? If not enable it and see if they report the same or different temperatures... I bet the misbehaving HR92 shows the same temperature as the other HR92 rather than the measurement it is broadcasting to Domoticz! If it's own display doesn't show the same reading it's broadcasting as a sensor it means it's stuck in single room zone mode.
Last edited by DBMandrake; 19 January 2017, 05:23 PM.
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!
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...
Assuming the latter, which one was originally bound first as the temperature sensor for the zone when it was originally a single room zone ? The one on the big radiator by any chance ? Which one's temperature shows on the controller ? (Only the first or primary one will show in a multi-room zone)
Just a hunch, but try this: Change the zone back to a single room zone, wait 10 minutes, then change it back to a multi-room zone, and wait another 10 minutes, then see how it behaves.
Hmm... I'm not sure it works like that. I'm pretty sure the HR92 is mostly stateless. It will likely get the multi-room flag with the temperature and/or set point updates from the controller (and promptly ignore the temperature if the flag is set). Buuuutttt... it's got to be worth a go!
Essentially you're saying that when the large one starts to throttle back, the small one will too (as it would in a single room zone)? I don't see that behaviour. The large one can get up to temperature and close completely, and the small one will still be making a small call for heat.
One more thing: Do you have room temperature display on both HR92's enabled ? If not enable it and see if they report the same or different temperatures... I bet the misbehaving HR92 shows the same temperature as the other HR92 rather than the measurement it is broadcasting to Domoticz! If it's own display doesn't show the same reading it's broadcasting as a sensor it means it's stuck in single room zone mode.
This is the only zone in which I do have room temperature display enabled - because I spend most of my days in there (or at least, I did before it got cold and I discovered its insulation issues!) The temperatures they're reporting match what's on Domoticz (give or take some lag). The small rad definitely shows the much lower temperature.
It looks fairly cheap, but by the time I'd added an antenna (€15), and postage from Germany, it came in at €82.
I'm happy to share the firmware, but as a professional software developer, I'm ashamed by it at the moment, so I'm in the middle of tidying it up ready for publishing. But I've slightly lost interest in that because it's working for me right now! I'll try and get back to it.
I'd definitely give DBMandrake's suggestions a try as it does sound like the HR92 is behaving very strangely. A full reset of the device might also be a good idea, but I'm not sure what setting might be causing this behaviour. Could you also possibly post a screenshot of the historical heat demand values for these two devices over the same 2 day period, via the log option on each device in the switches tab in Domoticz? What I'm interested in seeing is whether the heat demand of the small radiator freezes at all. I've spent quite a lot of time analysing the single and multi-room zones within my system whilst developing the Domoticz code and I've never seen this behaviour. The closest similar behaviour I've seen is when a HR92 suffered a stuck motor, but it displayed the E2 error when this occurred.
If the behaviour continues after all these suggestions, then I'd also try swapping over the HR92s to confirm that the behaviour follows the HR92. If it does then I think it sounds more like a faulty HR92.
Right, I'm going to change it to single room and go to bed. I'll change it back in the morning. Thanks for the help so far, guys. It's really looking like a problem with the HR92. Just need Rameses to wade in now...
Great, thanks for posting the pictures of the heat demand values. My opinion is that it's either a very strangely bound and confused HR92 which a full reset and recreation of the zone should confirm and fix or (more likely) it's faulty.
So I set it to single room before I went to bed last night. It was broken at that point and remained so overnight until about 7:30 when the optimum start kicked in. It's possible that this was also the first time it learned about the change of mode since I went to bed after the last set point change of the day. Once it got the new set point, it opened up and started heating just fine. But then, it would work just fine for 3 or 4 days previously, before then going off the rails for a couple of days. So I've not learned anything in particular by it working right now. In fact, I'd have learned more if it hadn't worked.
I've set it back to multi-room now, and will continue to monitor for a few days and report back.
My advice (assuming you have space within 12 zones)
- wipe the zone
- hard wipe the HR92s (to reduce chance of double binding)
- Setup 2 zones - one per Radiator. (East / west / lrg small etc) - with same schedule
- wait 7-10 days
Come back with results
I think DBMandrake has some points regarding the point of sensing. DTS91 or SZT in this mix would make sense if the room is odd, has draught wells, solar injection etc. HR92s measure updraft.
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
Comment