Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Share your Projects!
3103

FWIW…

Step 1:

30% open is when the valve has moved 30% of the way from closed (0%) to fully open (100%).

That is, you would expect water to flow through the valve at a reduce rate because of a smaller aperture. The radiator might ‘whistle/sing’, due to the turbulence that this gives (a phenomenon that you get with smart/motorized TRVs, but not so much with wax-TRVs).

However, whether the vale is ‘open’ or not (i.e. water can flow through it) would also depend upon other factors:

  • is the valve ‘stuck’ (this is why the TRV cycles occasionally)
  • is the TRV sitting on top of an adapter
  • is the TRV configured for ‘full-stroke’, etc.

NOTE: How far a valve is open - or closed - is a separate issue to whether the boiler is heating the CV (the circulating volume of fluid) and/or whether the CV pump is on…

Step 2:

If the transform function (the graph in the link above) creates a heat demand > 0% for a zone (after considering zone temps, setpoints, system/zone modes, optimalizations, etc.), then the controller will make a ‘call for heat’ from the boiler (or similar). It is asking fro the CV to be heated & pumped.

Step 3:

Step 2 with either be TPI, or modulated, depending. With TPI, a 50% call for heat might me boiler on 5 mins, off mins.

If modulated, the water will effectively be heated to a lower temp (say 30C instead of 45C).

This depend on a lot of other parameters, and - in addition - the boiler may decide to it’s own thing if configured to do so.

Step 4:

Even though the boiler is pumping hot water around the CV, the TRVs may device to go to 0%.

I don’t know if you need to bother trying to understand all of that - the system is full of feedback loops, effectively tuning itself as it goes - it works.

3104

and there you go:

:rofl:

3105

Intel NUC for Home Assistant

MacOS for debugging the stick :slight_smile:

3106

Excellent explanation!

3107

So that’s the solution - we should put it in the Wiki somewhere - did you get if off the ghoyi57/evofw3 repo?

3108

I did the same, I found this information here: nanoCUL not transmitting · Issue #31 · ghoti57/evofw3 · GitHub
Afterward, I started the evofw3 autotune process: EVOFW3 Autotune · ghoti57/evofw3 Wiki · GitHub

3109

Anyway it is still not perfect.
I disabled sending in ramses_rf and now it works ok. (Read only)

If I enable sending, the device hangs after a few minutes.

I think it is a hardware or tuning issue

3110

Im monitoring my boiler usage with a Shelly 1, HA template sensors and an automation which sends me email daily.

All of my HR92s White Wheels are installed so that at 30% of 4mm pin travel they should stop hissing.

Judging by this graph, my Evohome is doing something under 30%.

Screenshot_2022-11-11-03-24-06-405_com.android.chrome
Screenshot_2022-11-11-03-24-06-405_com.android.chrome1080×575 44.6 KB

So if under 30% there should be no flow and over 30% more or less its calling for boiler to come on… Wouldnt it be better to install HR92 White Wheel like this:

No flow:
0-10%

Flow:
10-30% (0,8mm pin travel of maybe warm water but not calling for heat)
30-80% (2mm pin travel)
80-100% (0,8mm of no contact)

If I understand it correctly then this would dump excess heat evenly into the zones and not waste it in the boiler room.

Thoughts?

3111

There’s more to: Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm - #3103 by zxdavb

In addition

  • the zone heat demand is the transformed value of the highest pin valve position of the TRVs of that zone
  • the boiler (system) heat demand is the highest of all zone’s heat demands
3112

Is that still the case with the latest firmware in the Evohome controller? I have seven zones and in the morning when the setpoints all increase I could see a few HR92s at 100% and the remainder at some intermediate value. At this point, the heat demand will not be 100% but some lower percentage which seems to cause the system to select something that is either advanced load scaling or TPI and instead of a constant firing, will do several short bursts over the space of an hour.

At other times I could manually alter an HR92 to a much higher setpoint causing a 100% open on a single TRV and it causes the boiler to fire straight away. There is more going on here.

Now its true, before resideo pushed the latest firmware to my controller the highest open HR92 did correspond to the demand setting on the controller, but now in my system that is no longer the case.

3113

Hi David, thanks for your reply!
I filtered out the neighbour device and removed the fake remote as you advised. It seems that faked: true is needed for a remote to be able to send commands.

I’ll PM you the logs files, I should have more than enough logging by now :slightly_smiling_face:
Edit - PM sent!

3114

You got me - I should have explained it better: I did start by saying:

What I meant to say was: this is how it works if you ignore all optimizations.

To clarify the above: (in the absence of woo) the zone heat demand is as follows:

zone_heat_demand = transform(max(trv_pin_valve_positions))

NOTE: be aware that the above algorithm used to create the zone demand in evohome_cc (as the controller will not provide this information - it will provide teh system heat demand, however)

But that value is then modified according to any Smart Features, such as.

  • Cold weather boost
  • Warm weather saver
  • Optimized start/stop
  • Advanced load scaling (not used with OT)

… to produce the system heat demand (FWIW, I believe the ‘fuzzy logic’ is in the actuators - TRVs, UFCs, etc.).

Then, the call for heat is made. This call is effected either as TPI (one/off via a BDR relay) or modulated (via an OpenTherm bridge).

When using TPI, each zone’s heat demand is further ‘tweaked’ by advanced load scaling, which looks at the rate of rise in the room temperature for a given input of CV (as a function of time, not volume) - the idea (I believe) is to work out how ‘big’ a room is & how ‘well’ the radiators in that room can heat that room, to prevent overshoot.

Importantly, no-one has ever told me that either of the following has occurred:
a) a zones’ heat demand in the controller UI has not matched that of ramses_cc
b) the system heat demand isn’t the maximum of the zone heat demands

Le me know (with a packet log) if you ever see either of the above.

Ref:

3115

It is much, much much better to white list only those devices you have rather than black listing unwanted device.

This is because ghost devices (albeit with valid IDs) randomly appear all the time.

See: known_list, in the wiki

3116

That’s exactly what I did, also see the logging and configuration I shared with you through PM.
I’m sorry for the confusion, I should have explained my thoughts better :slight_smile:

3117

@zxdavb I get a strange error and the integration only runs for about an hour before its stops. If i restart HA it starts working again. I have tried rames_rf directly on my laptop with no issues with the device.

Any ideas?

Thank you

2022-11-12 17:38:32.810 ERROR (MainThread) [ramses_rf.protocol.transport] Exception raised by transport: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2022-11-12 17:38:32.818 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SerialTransport._call_connection_lost(SerialExcepti...ss on port?)'))
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 414, in _call_connection_lost
self._protocol.connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 754, in connection_lost
super().connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 583, in connection_lost
raise exc
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 115, in _read_ready
data = self._serial.read(self._max_read_size)
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)```
3118

Funny. I had exactly the same issue today. I had to restart the system.
I think it may have been caused by the USB dongle being accidentally removed.

3119

@zxdavb This morning at 8.30 am, five out of eight HR92’s went to 100% as the schedule for the house asked for heating, and three other HR92’s remained closed due to the Warm Weather Saver setting forcing their setpoint to 5degC. The appliance demand as shown on the Evohome Controller system summary page updated to 85%. Is this what you’re interested in seeing?

I’m not yet moved on to evohome_cc, I’m still using Evogateway, but I do intend to install evohome_cc but on a separate install. However, the values I see obtained from Evogateway agree with what I see on the Evohome Controller summary page.

I’ve attached a link to today’s packet.log. Setpoints for all TRVs happen at 8.30. Eight TRVs, seven Zones. TRV:133207 & TRV133209 are together in Zone 6 and use a T87 remote thermostat

packet.log

Mike

3120

Interesting, as no one has been near my device. I originally had connected to a powered usb 2.0 hub and the issue occurred so I moved it to the Raspberry Pi directly and the issue continued.

3121

FWIW, evogateway sits on top of ramses_rf, just like ramses_cc does, so they should (ignoring all commits to ramses_rf since 0.18.6) give the same values.

For now, I’m interested when the demand in HA doesn’t match the demand in the controller UI.

Thanks for the logs - I’ll have a look.

3122

Cheers for the work you’re doing on this, it is very much appreciated, certainly, the data I get back on valve positions and the various demands have shown me some shortcomings in the software in this Evohome controller.

One of the issues that I would never have been aware of unless I had access to this data is seeing the Boiler being asked to fire when the Demand shows 0% on the controller and locally on all the HR92’s as well as selecting the system to OFF.
I see this occasionally when it appears that whatever TPI firing schedule the controller picks, once its mind is made up, if it has decided that’ll it’ll fire three times in the next hour it’ll carry out the last fire regardless of whether the demand drops to zero or not, all actuators showing zero locally. Sometimes I know it’s going to do it, so before it does I’ll select the system to off and it’ll still carry out what it thinks was needed.

My boiler cycles are set to three per hour in the Evohome controller. So sometimes before the third cycle is due that hour, the rooms have crept up to temperature, especially if there is an external factor like a sunny way, and it still fires. More of a nuisance, but is a waste heating boiler water around the bypass pipework.

So I’m hoping with evohome_cc and some other sensors I have around the house, that perhaps I can spot the conditions which cause this and alter setpoints earlier to avoid it. Either that or I’ll place a relay between the BDR91 and the boiler and block the hard-wired firing signal when evohome_cc clearly shows no need to fire:-)