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

Share your Projects!
3097

The 094 describes a weak RF signal and suggests it is from a neighbour’s house. Filter it out via enforcing the whitelist.

See my previous post about faking vs instantiation.

You don’t need (to instantiate) a second remote - the remote you have is stateless - so just impersonate it by using the remote.send_command service call (or, better still, the ramses_cc equivalent).

FWIW, and IIRC, you do not need to set faked: true anyway (I could be wrong, and it wont hurt to leave it in, I guess).

Anyway, just ditch the faked remote.

FANs usually cast 31D9/31DA packets, as does 32:236773 (and 37:250081). Humidity sensors cast a 12A0 (your device could be both / send both).

If you like, send (PM) me a 24h packet log - you haven’t provided enough of a log file here for me to be confident about much more.

1 Like
3098

For those that dont know:

HR92’s sensor.04_xxxxxx_heat_demand is actual valve pin position !

3099

@zxdavb delete this post if its not appropriate.

Is everyone installing their HR92s onto their valve bodies so that <30% valve pin position the valve is already closed or is any other percentage better?

3100

Correct. The other heat demands are as you might expect.

For a long time, I might like to have changed this to valve_position - but there are good reasons for not doing so. PV position is a number between 0-200, and it is simply divided by 200 to get a %.

You overestimate my powers.

I am not sure if this question makes sense? A PV position of 30% is 30% open (and so on). AFAIK, it is not configurable.

There is a function that is used to heat demand of an actuator to heat demand of a zone, see:

To be clear, it is three straight lines, 0-30 (i.e. PV of 0-60, these are all 0%), >30-70, and >70-100.

3102

So I managed to get ramses_cc working.

For those who are having the issues that rames_cc doesnt receive signals. (With the ebay nanocul)

  • install the evofw3 as instructed above
  • if you have macos: install “serial tools” from the mac store.
  • connect and if you see strange data: reset nvram with !ER
  • power cycle the device
  • do a autotune as described EVOFW3 Autotune · ghoti57/evofw3 Wiki · GitHub
1 Like
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?)```