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

zxdavb · November 9, 2022, 4:19pm

So you definitely don’t get:

2022-11-09 16:15:07.197 ERROR (MainThread) [ramses_rf.protocol.transport] Failed to open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0

… in your HA log? (I have to ask, as you have posted an edited log).

This is what I have:

2022-11-09 16:32:32.407 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.connection_made(SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, PacketProtocolQos, Serial<id=0x7ff61b6c2260, open=True>(port='/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=True, rtscts=False, dsrdtr=False)))

zxdavb · November 9, 2022, 4:43pm

If that doesn’t help: you’re not doing anything odd, like running in a VM, are you?

djfanatix · November 9, 2022, 6:23pm

No VM, just HASSOS on a NUC

Could a Z-wave stick in the neighborhood cause interference?

2022-11-09 18:56:16.410 WARNING (MainThread) [ramses_rf.protocol.schemas] Best practice is exactly one gateway (HGI) in the known_list: []
2022-11-09 18:56:16.415 WARNING (MainThread) [ramses_rf.protocol.schemas] It is strongly recommended to use the known_list as a whitelist (device_id filter), configure: enforce_known_list = True
2022-11-09 18:56:16.418 INFO (MainThread) [custom_components.ramses_cc.coordinator] Success initialising with the cached schema: {'main_tcs': None, 'orphans_heat': [], 'orphans_hvac': []}
2022-11-09 18:56:16.418 INFO (MainThread) [custom_components.ramses_cc.coordinator] Restoring the client state cache (packets only)...
2022-11-09 18:56:16.547 INFO (MainThread) [homeassistant.setup] Setting up homekit_controller
2022-11-09 18:56:16.560 INFO (SyncWorker_2) [pyfritzhome.fritzhome] Updating Devices ...
2022-11-09 18:56:16.565 INFO (MainThread) [ramses_rf.protocol.transport] RAMSES_RF protocol library v0.22.1, using PacketProtocolFile
2022-11-09 18:56:16.565 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.pause_writing()
2022-11-09 18:56:16.576 INFO (MainThread) [homeassistant.setup] Setting up fritz
2022-11-09 18:56:16.576 INFO (MainThread) [homeassistant.setup] Setup of domain fritz took 0.0 seconds
2022-11-09 18:56:16.578 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.connection_made(<ramses_rf.protocol.transport.SerTransportRead object at 0x7fc8a2ac6f40>)
2022-11-09 18:56:16.578 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2022-11-09 18:56:16.579 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.pause_writing()
2022-11-09 18:56:16.744 INFO (MainThread) [homeassistant.setup] Setup of domain homekit_controller took 0.2 seconds
2022-11-09 18:56:16.744 INFO (MainThread) [custom_components.ramses_cc.coordinator] Restored the cached state.
2022-11-09 18:56:16.745 DEBUG (MainThread) [custom_components.ramses_cc.coordinator] Starting the RF monitor...
2022-11-09 18:56:16.747 INFO (MainThread) [ramses_rf.protocol.transport] RAMSES_RF protocol library v0.22.1, using PacketProtocolQos
2022-11-09 18:56:16.750 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgTransport._set_dispatcher(<bound method PacketProtocolQos.send_data of PacketProtocolQos(enforce_include=False)>)
2022-11-09 18:56:16.890 INFO (MainThread) [homeassistant.setup] Setting up hacs
2022-11-09 18:56:16.890 INFO (MainThread) [homeassistant.setup] Setup of domain hacs took 0.0 seconds
2022-11-09 18:56:16.892 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.connection_made(SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, PacketProtocolQos, Serial<id=0x7fc8a1447eb0, open=True>(port='/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=True, rtscts=False, dsrdtr=False)))
2022-11-09 18:56:16.892 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2022-11-09 18:56:16.894 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.resume_writing()

I have no error when connecting to the serial port.
How can I verify the port? I checked in the hardware settings of HA

Could it be something with the bootloader?
I used the ‘standard’ bootloader

prescott · November 9, 2022, 8:11pm

Yes it perfectly answers it, thanks!

Jimbone777 · November 9, 2022, 9:45pm

Hello, I’m super sorry to ask an idiotic question but I’m having trouble following direction.

I have HA installed on a Pi4 and am using a SSM-D2 from indalo tech. I’m trying to control a Nuaire PIV instead of splashing out on their remote control.

I’ve got as far as the ramses configuration and can see things in the packet log:

2022-11-09 21:15:24.408 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:17:49.409 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:18:43.903 ERROR (MainThread) [ramses_rf.protocol.message]  I 025 30:112130 --:------ 30:112130 31D9 017 2100FF0000000000000000000000000000 < AssertionError(What!! (AA))
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 338, in _validate
    return {**self._idx, **result}
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 219, in _idx
    assert self._pkt._idx == "00", "What!! (AA)"
AssertionError: What!! (AA)
2022-11-09 21:20:14.411 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:22:39.414 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:25:04.417 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:27:25.683 WARNING (MainThread) [ramses_rf.protocol.parsers]  I --- 30:112130 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: RFG:112130 (device type 30 not known to have signature: 0001C90023006CFEFE)
2022-11-09 21:27:51.135 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:30:16.138 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:32:41.140 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:34:00.229 WARNING (MainThread) [ramses_rf.entity_base] No response for task(000C|RP|01:090099|000E): throttling to 1/24h
2022-11-09 21:34:10.138 WARNING (MainThread) [ramses_rf.entity_base] No response for task(000C|RP|01:090099|010E): throttling to 1/24h
2022-11-09 21:34:20.048 WARNING (MainThread) [ramses_rf.entity_base] No response for task(10A0|RP|01:090099|00): throttling to 1/24h
2022-11-09 21:35:06.142 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:37:28.647 WARNING (MainThread) [ramses_rf.entity_base] No response for task(000C|RP|01:090099|000F): throttling to 1/24h
2022-11-09 21:37:31.144 ERROR (MainThread) [ramses_rf.dispatcher]  I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))

I don’t know what to do next, I’m not sure what class of device my PIV is and what numbers I should use to configure it. Should a device/entity magically shown up in HA by now? Do I need to look at the packet log and work out a number I should be using in the configuration? Do I need to pair/bind something with the PIV (it uses a pairing/binding method with the off-the-shelf control).

I’d appreciate any hints as to where I’m going wrong, I’m happy to read, I just don’t know what I’m doing. thanks

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