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

nickasdf · November 9, 2022, 9:53pm

ramses_cc is great work, thanks a lot!

I’m trying to get it to work with my Orcon MVS-15 ventilation unit and I’m not sure what I’m missing, maybe my configuration is incomplete or I made some mistakes

My setup:

Orcon MVS-15 with 15RF remote (the MVS-15 unit also has a built-in humidity sensor)
nanoCul USB dongle with evofw3 firmware. I started and completed the tuning procedure in evofw3 because I thought I wasn’t getting responses.
I’m using a bigger magnetic base antenna with the nanoCul

I started with the minimal setup for ramses_cc and I did get some logging, like:

2022-11-09T21:20:02.097536 ...  I --- 29:163367 32:236773 --:------ 22F1 003 000104 # 22F1| I|29:163367
2022-11-09T21:20:02.124372 ...  I --- 32:236773 --:------ 32:236773 31D9 003 000001 # 31D9| I|32:236773|00 (00)
2022-11-09T21:22:33.198788 063  I --- 29:163367 32:236773 --:------ 22F1 003 000404
2022-11-09T21:22:33.212834 063  I --- 32:236773 --:------ 32:236773 31D9 003 000004
2022-11-09T21:23:36.979362 068  I --- 29:163367 32:236773 --:------ 22F1 003 000204
2022-11-09T21:23:36.995382 063  I --- 32:236773 --:------ 32:236773 31D9 003 000002
2022-11-09T21:23:37.046597 063  I --- 32:236773 --:------ 32:236773 31D9 003 000002
2022-11-09T21:25:39.159801 094  I 190 37:250081 --:------ 37:250081 31D9 017 0006010020202020202020202020202000

29:163367 is definitely the 15RF remote. I assume that 32:236773 is the Orcon MVS-15.
I’m not sure what 37:250081 is (more about this later)

I wasn’t sure what auto-discovery would do for me and nothing was happening except for some ramses_rf logging in the HA logging so I ended up with this configuration (also using learn command):

# Transceiver for HVAC control (868 Mhz)
ramses_cc:
  # scan_interval: 30
  serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
  packet_log:
    file_name: packet.log
    rotate_backups: 28
  known_list:
    18:070912: # nanoCul 868 Mhz dongle
      class: HGI
      _note: nanoCul 868 Mhz
    29:163367: # Orcon 15RF remote
      class: REM
      _note: Orcon 15RF
      commands:
        auto: " I --- 29:163367 32:236773 --:------ 22F1 003 000404"
        low: " I --- 29:163367 32:236773 --:------ 22F1 003 000104"
        medium: " I --- 29:163367 32:236773 --:------ 22F1 003 000204"
        high: " I --- 29:163367 32:236773 --:------ 22F1 003 000304"
        away: " I --- 29:163367 32:236773 --:------ 22F1 003 000004"
        timer_15mins: " I --- 29:163367 32:236773 --:------ 22F3 007 00020F03040000"
        timer_30mins: " I --- 29:163367 32:236773 --:------ 22F3 007 00021E03040000"
        timer_60mins: " I --- 29:163367 32:236773 --:------ 22F3 007 00023C03040000"
    29:123456: # Fake remote for use with HA
      class: REM
      faked: True
      _note: Fake Orcon 15RF
      commands:
        auto: " I --- 29:123456 32:236773 --:------ 22F1 003 000404"
        low: " I --- 29:123456 32:236773 --:------ 22F1 003 000104"
        medium: " I --- 29:123456 32:236773 --:------ 22F1 003 000204"
        high: " I --- 29:123456 32:236773 --:------ 22F1 003 000304"
        away: " I --- 29:123456 32:236773 --:------ 22F1 003 000004"
        timer_15mins: " I --- 29:123456 32:236773 --:------ 22F3 007 00020F03040000"
        timer_30mins: " I --- 29:123456 32:236773 --:------ 22F3 007 00021E03040000"
        timer_60mins: " I --- 29:123456 32:236773 --:------ 22F3 007 00023C03040000"
    32:236773: # Orcon MVS-15 fan
      class: FAN
      _note: Orcon MVS-15
    # 37:250081: # Orcon MVS-15 fan?
    #   class: FAN
    #   _note: Orcon MVS-15
    # 32:236773: # Orcon MVS-15 humidity sensor?
    #   class: HUM
  ramses_rf:
    enforce_known_list: false # TODO: set to true when finished

Based on the packet log I would say that 32:236773 is the Orcon MVS-15 but when I configure it with class FAN it doesn’t work (not available). When I configure 37:250081 as FAN it becomes available but it’s not updated when I change the fan speed using a remote etc. I’m confused…

I didn’t bind any of the devices to the fan unit except for the 15RF remote, the fake remote works using the send command service when I use the id of the real 15RF remote (29:163367) in the command instead of the fake remote’s id.

Some probably relevant HA logging:

2022-11-09 22:37:30.885 INFO (MainThread) [ramses_rf.dispatcher] || FAN:236773 |  18:070912 | RP | fan_mode         |      || {'fan_mode': 'auto', '_scheme': 'orcon', '_mode_idx': '04', '_mode_max': '04'}
2022-11-09 22:37:30.885 INFO (MainThread) [ramses_rf.dispatcher] RP --- 32:236773 18:070912 --:------ 22F1 003 000404 < Invalid code for 32:236773 (FAN) to Tx: 22F1
2022-11-09 22:37:30.928 INFO (MainThread) [ramses_rf.dispatcher] || HVC:250081 |            |  I | hvac_state       |      || {'exhaust_fan_speed': 0.005, 'fan_info': 'speed 1', 'remaining_time': 0.0, 'air_quality': None, 'air_quality_base': 0, 'co2_level': None, 'indoor_humidity': 0.55, 'outdoor_humidity': None, 'exhaust_temperature': None, 'supply_temperature': None, 'indoor_temperature': None, 'outdoor_temperature': None, 'speed_cap': 63488, 'bypass_position': None, 'supply_fan_speed': 0.0, 'post_heat': None, 'pre_heat': None, 'supply_flow': None, 'exhaust_flow': None}
2022-11-09 22:37:31.074 INFO (MainThread) [ramses_rf.dispatcher] || HVC:022641 |            |  I | fan_state        |  00  || {'exhaust_fan_speed': 0.3, 'fan_mode': '3C', 'passive': True, 'damper_only': True, 'filter_dirty': False, 'frost_cycle': False, 'has_fault': False, '_flags': [0, 0, 0, 0, 0, 1, 1, 0], '_unknown_3': '00', '_unknown_4': '202020202020202020202020', 'unknown_16': '00', 'seqx_num': '134'}
2022-11-09 22:37:31.087 INFO (MainThread) [ramses_rf.dispatcher] || HVC:022641 |  18:070912 | RP | unknown_3222     |      || {'start': '03', 'length': '07', 'data': '......00000000000000'}
2022-11-09 22:37:31.097 INFO (MainThread) [ramses_rf.dispatcher] || REM:163367 | FAN:236773 |  I | fan_boost        |      || {'minutes': 15, 'flags': [0, 0, 0, 0, 0, 0, 1, 0], '_new_speed_mode': 'per_vent_speed', '_fallback_speed_mode': None, 'rate': None, '_unknown_5': '0000'}
2022-11-09 22:37:38.387 INFO (MainThread) [ramses_rf.dispatcher] || REM:163367 | FAN:236773 |  I | fan_mode         |      || {'fan_mode': 'auto', '_scheme': 'orcon', '_mode_idx': '04', '_mode_max': '04'}
2022-11-09 22:37:38.420 INFO (MainThread) [ramses_rf.dispatcher] || FAN:236773 |            |  I | fan_state        |  00  || {'exhaust_fan_speed': 0.02, 'fan_mode': '04', 'passive': False, 'damper_only': False, 'filter_dirty': False, 'frost_cycle': False, 'has_fault': False, '_flags': [0, 0, 0, 0, 0, 0, 0, 0]}

I think HVC:022641 is a ‘neighbour’ device.

Please let me know if you need any more information. Thanks!

zxdavb · November 9, 2022, 11:29pm

First thing: for HVAC, you cannot use the two digits of the device_id that are in front of the colon to determine the device class. But you can for CH/DHW devices, and that is what ramses_rf has done here - it thinks it’s an RFG100.

Use a device hint to make that force the device to be a FAN:

ramses_rf:
  known_list:
    30:112130: class: FAN

(see: 2. configuration.yaml · zxdavb/ramses_cc Wiki · GitHub)

Once you have done that, things will improve for you.

BTW: Currently, all PIVs, HRUs and extractors (EXTs) are called FANs.

Then you’ll need to create a fake remote:

ramses_rf:
  orphans_hvac: [32:123456]
  known_list:
    32:123456: class: SWI

(see: Create new page · zxdavb/ramses_cc Wiki · GitHub)

I am not sure how you bind - have a look at Nuaire’s docs in the first instance.

zxdavb · November 9, 2022, 11:34pm

NOTE: a device is not instantiated (made into existence) by being in the known_list.

The known_list merely tells ramses_rf what to do if/when it wants to instantiate that device.

NOTE: a device is instantiated during HA startup when it is in the schema (e.g. hvac_orphans), or subsequently, when it is ‘seen’ transmitting on the RF.

zxdavb · November 9, 2022, 11:47pm

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.

prescott · November 10, 2022, 1:07pm

For those that dont know:

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

prescott · November 10, 2022, 1:12pm

@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?

zxdavb · November 10, 2022, 1:40pm

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:

Evohome : valve position status on the HR92 vs evotouch

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.

djfanatix · November 10, 2022, 2:04pm

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

zxdavb · November 10, 2022, 2:07pm

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.

zxdavb · November 10, 2022, 2:09pm

and there you go:

djfanatix · November 10, 2022, 2:11pm

Intel NUC for Home Assistant

MacOS for debugging the stick

prescott · November 10, 2022, 2:16pm

Excellent explanation!

zxdavb · November 10, 2022, 5:04pm

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

nickasdf · November 10, 2022, 6:52pm

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

djfanatix · November 10, 2022, 8:39pm

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

prescott · November 11, 2022, 2:36am

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%.

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?

zxdavb · November 11, 2022, 8:32am

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

Mike_H · November 11, 2022, 5:53pm

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.

nickasdf · November 12, 2022, 11:18am

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
Edit - PM sent!

zxdavb · November 12, 2022, 12:51pm

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:

https://ensupport.getconnected.honeywellhome.com/s/article/How-do-you-setup-advanced-load-scaling-on-evohome