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

rieschard · December 16, 2023, 9:51pm

Upgrading to the december version of home assistant made all ramsess devices unavailable. Is this a known issue?
Stable version


ramses_cc:
  serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
  packet_log:
    file_name: packet.log
    rotate_backups: 28
  restore_cache: true
  ramses_rf:
    enforce_known_list: false


Failed to open /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0 (config: {'baudrate': 115200, 'rtscts': False, 'dsrdtr': False, 'timeout': 0, 'xonxoff': True}): [Errno 5] could not open port /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0: [Errno 5] I/O error: '/dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0'

zxdavb · December 16, 2023, 10:18pm

Fix this (is an error from the OS): ramses_cc cant work without a serial port.

rieschard · December 16, 2023, 10:29pm

Thanks, i managed it by disconnecting and reconnecting the usb device

rieschard · December 17, 2023, 11:09am

In version 0.30.7 i have the following log message:


Logger: ramses_tx.parsers
Source: runner.py:188
First occurred: 16 december 2023 om 23:32:19 (14504 occurrences)
Last logged: 12:06:24

I --- 37:055637 --:------ 37:055637 3120 007 0070B00000E5FF < Support the development of ramses_rf by reporting this packet (byte 5: E5)
I --- 37:137928 63:262142 --:------ 10E0 038 0000010028040101FEFFFFFFFFFF030B07E0564D532D31324333390000000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 37:137928 (device type 37 not known to have signature: 00010028040101FEFF)
I --- 37:146734 63:262142 --:------ 10E0 038 0000010028040101FEFFFFFFFFFF030B07E0564D532D31324333390000000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 37:146734 (device type 37 not known to have signature: 00010028040101FEFF)
I --- 37:047927 63:262142 --:------ 10E0 038 0000010028040101FEFFFFFFFFFF030B07E0564D532D31324333390000000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 37:047927 (device type 37 not known to have signature: 00010028040101FEFF)

rieschard · December 17, 2023, 11:19am


service: ramses_cc.fake_device
data:
  device_id: "34:012303"
  create_device: true
  start_binding: true

I want to create a virtual temperature device with a rameom number and bind it to the evohome controller
The upper service call gives an error
Without the “create device” line it does not give an error but no binding is established.
Any help is appreciated!

zxdavb · December 17, 2023, 11:32am

Have a look at: Create new page · zxdavb/ramses_cc Wiki · GitHub

Sorry: that wiki is currently a mess.

If you cannot create the device using the service call, instantiate it in the configuration.yaml as an orphan.

zxdavb · December 17, 2023, 11:35am

… and a 24h packet log, if you’re willing - you can PM me a link.

zxdavb · December 17, 2023, 11:43am

Yes - it is 6C.

rieschard · December 17, 2023, 12:56pm

Yes, I looked at that.
New devices are added to the entity list, but unavailable.
binding fails (no connection to evenome controller)

Spaco · December 18, 2023, 9:42am

One thing I’ve noticed, and I suspect it is not a general issue, is that going from 0.21.40 to 0.30.x has made restarts/reboots quite fiddly. On my setup, many entities come up unavailable after a restart (with restore_* settings commented out, so default) and never become available as you would expect. It takes various combinations of restore_schema/state and multiple restarts for all entities to come up as available. The weird thing is, the packet log is happily chugging along in the background and no errors/warnings in the system log - I can’t find a reproducible pattern to this. Going back to 0.21.40 makes restarts consistently reliable again. But hey, no one else has mentioned anything so its probably a quirk of my setup.

dwp · December 18, 2023, 12:28pm

Thanks - I will wait until there is less demand before fiddling

zxdavb · December 18, 2023, 12:44pm

The timings have changed for refreshing data, so this may be the reason.

If you find something missing after a reboot - then it’s not in the cache, and a second reboot shouldn’t make things any better…

A reproduceable patterns would be the first step to a fix.

PyroPath · December 18, 2023, 1:25pm

So, I’ve been playing around for the past month or so, trying to set up this integration. It has been with varying levels of succes, which is mostly related to coverage of the dongle with some HR92’s showing up intermittently. I think this might be caused by the fact that my SSM-D2 is plugged directly into my USB3 port on the mini-pic running HA OS. I will try to get this better later on, but my main focus is now to get the basis working.

Most recently I added my Itho-Daaldrop CVE-S Optima into the mix and (through eavesdropping?) I also found the RF remote in the packet logs. What I tried to set up was a clone or impersonation of the current RF remote, but the WIKI is not very clear on how to achieve this. So I went the trial and error route. At one point I was able to see a “remote” entity is home assistant, but it didn’t behave as I hoped. Learning the commands didn’t go as expected with the ventilation box not responding to it and being unable to learn more than one command. So I put it away/aside for a bit.

Now I’m trying to get back into it and somewhere, or somehow I lost the remote entity and I can’t seem to get it back. I still have 2 sensor entities: a battery state entity and an OEM_code entity for the ID that is the remote, but the remote itself is nowhere to be found. Making it impossible to fiddle and tinker with commands. I don’t know what I have changed between it being available and not working and losing it, because some time has passed where I put it aside and was busy with other things, but still tinkering with Ramses_cc for other things.

Below is my configuration.yaml. The 37: is the CVE, the 29: is the RF remote. The commands for low, auto and high were simply copy/pasted from the packet log (and removing the counter that in there) in an effort to amend the configuration as stated in the WIKI. But this is the part where I was struggling before to understand what is/was needed to simply clone or impersonate a remote.I didn’t have it in there before, when I first tried to have the remote faked. I was trying various things, hoping it would fix stuff, but unfortunately, it didn’t. I’ve also tried reinstalling the whole integration and various variations on cache, state and schema restore, eavesdrop on/off, enforce known list and what not, but still nothing:

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log:
    file_name: packet.log
    rotate_backups: 7

  restore_cache:
    restore_schema: false
    restore_state: false

  ramses_rf:
    enforce_known_list: true # if not true, still enforces the block_list
    disable_discovery: false
    disable_sending: false # do not transmit any packets, ever
    enable_eavesdrop: true # can be used to create an initial system schema

  01:245354:  # Temperature control system (Evohome)
    #system:
    #  appliance_control: 13:155994
    zones:
      "00": {sensor: 01:245354}

  orphans_hvac: [37:182456, 29:057880]
  known_list:
    18:203291: {class: HGI}         # SSM-D Kantoor
    01:245354:                      # Evohome / Controller Huiskamer
    13:155994:                      # BDR91 Meterkast
    04:136057:                      # HR92 zone 00 Trapkast
    04:040504:                      # HR92 zone 01 Garage
    04:136053:                      # HR92 zone 02 Entree
    04:136205:                      # HR92 zone 03 1e Badkamer
    04:136055:                      # HR92 zone 04 2e Badkamer
    03:255542:                      # Thermostaat zone 05 Kantoor
    04:136051:                      # HR92 zone 05 Kantoor
    34:010179:                      # Thermostaat zone 06 Slaapkamer
    04:040506:                      # HR92 zone 06 Slaapkamer
    04:245529:                      # HR92 zone 07 Sport
    34:095145:                      # Thermostaat zone 08 W&W
    04:040510:                      # HR92 zone 08 W&W
    04:136199:                      # HR92 zone 08 W&W
    04:136201:                      # HR92 zone 09 Tafel
    04:040508:                      # HR92 zone 09 Keuken
    04:136203:                      # HR92 zone 09 TV
    37:182456: {class: FAN}         # Itho CVE-S Optima
    #29:057880: {class: REM}         # Itho CVE-S Optima Remote
    29:057880:                      # Itho CVE-S Optima Remote faked
      class: REM
      faked: true
      commands:
        low:  ' I --- --:------ --:------ 29:057880 22F1 003 630204'
        auto: ' I --- --:------ --:------ 29:057880 22F1 003 630304'
        high: ' I --- --:------ --:------ 29:057880 22F1 003 630404'

#edited for correct formatiing. appologies.

I found out the entity for the remote was gone when I tried the service call to copy a command. it would give me an instant checkmark without pushing a button on the physical remote. it gives an error in the log:
"
2023-12-18 11:52:39.048 WARNING (MainThread) [homeassistant.helpers.service] Referenced entities remote.29_057880 are missing or not currently available"

Also, “03:255542: # Thermostaat zone 05 Kantoor” is a HCF82 temperature sensor/thermostat without manual temperature setting from Honeywell. It shows up in the logs. but the entities in HA never become available.

#2nd edit

I also found some error messages related to 03:255542:

Logger: ramses_rf.protocol.message
Source: runner.py:188
First occurred: 20:15:33 (5 occurrences)
Last logged: 22:15:31

I 107 03:255542 --:------ 03:255542 30C9 003 0106E0 < Corrupt payload: Packet idx is 01, but expecting no idx (00) (0xAB)
I 108 03:255542 --:------ 03:255542 30C9 003 0106D6 < Corrupt payload: Packet idx is 01, but expecting no idx (00) (0xAB)

rieschard · December 19, 2023, 7:31pm

Creating a fake device


service: ramses_cc.fake_device
data:
  device_id: "03:023456"
  create_device: true
  start_binding: true

Does not result a successful binding in evohome

Any suggestions? I am trying in circles
I am using a HGI80

stevieb12345 · December 20, 2023, 8:01am

I’ve just moved house and had all my valves working with faked sensors in my old house, but I’m also struggling to get the faked sensors working on my new install.

The wiki on the faked sensors is hard to follow.

zxdavb · December 20, 2023, 3:21pm

If appears that 29:057880 does not exist.

Please put it in a orphans list:

ramses_cc:
  orphans_hvac: [29:057880]

See: known_list:

The known_list exists for three reasons:

for relevant devices (e.g. sensors, remotes), to indicate is faking is enabled

… and:

Having a device ID in the known list will not cause it to be instantiated: use a schema, or one of the orphan lists to do that.

So, also see: schemas for hvac systems

zxdavb · December 20, 2023, 3:58pm

Which version are you using - 0.2x.x should still be OK for binding.

PyroPath · December 20, 2023, 4:34pm

Am I doing something wrong in my posted configuration.yaml then? Perhaps indentation or place in the list, because, it is already in there:

“orphans_hvac: [37:182456, 29:057880]”

right above the known list…

zxdavb · December 20, 2023, 4:39pm

Ah!

Then I am stuck - are you using version 0.2x.x?

PyroPath · December 20, 2023, 4:44pm

tried 0.22.40, 0.30.5, 0.30.6 and 0.30.7. The weird thing is, the battery status does pop up in the entities, but with unknown status. Is it normal for the schema not to contain the hvac and remotes? Because currently, when I look at the attributes of the schema, they are not in there.