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

No, The schema is simply invalid.

Did the following error message not appear in your HA log?:

Inconsistent state: 04:055510 (TRV) changed parent: 01:050858_02 (radiator_valve) to 01:050858_03 (radiator_valve),  (try restarting the client library)

… I guess I can change the message:

Inconsistent schema: 04:055510 (TRV) changed parent...

Looking at your schema, I can see why there may be confusion:

      devices:
        - '04:055480'

devices means sensors and/or actuators. 04:055480 is the sensor, but not one of the actuators.

It didn’t add the other actuator - it gave up instead.

With the latest version the integration don’t start anymore:

My config:

evohome_cc:
  serial_port: /dev/ttyUSB-EVOHOME
  scan_interval: 60
  packet_log: 
    file_name: evohome_cc.log
    rotate_bytes: null
    rotate_backups: 3
  restore_state: true
  ramses_rf:
    enforce_known_list: true
    max_zones: 9
  schema:
    controller: 01:087939
    system:
      heating_control: 10:078099
  known_list:
    - 01:087939 # Controller
    - 04:225661 # Badkamer
    - 04:225663 # Slaapkamer Evi
    - 02:017205 # Woonkamer
    - 04:023992 # Kastenkamer
    - 04:059569 # Slaapkamer
    - 04:225657 # Toilet
    - 04:024000 # Slaapkamer Nova
    - 10:078099 # Heating control
    - 18:073736 # Vloerverwarming (UFH)

log file:

2021-11-18T20:36:52.877459 # ramses_rf 0.16.7

You’ll have to increase logging in HA & see what eventuates: Troubleshooting

Before the update there was no problem. I have now increase the logging.

You can also downgrade via HACS.

@iMiMx I’ve tweaked my code for you:

        "02": {
            "_name": "Utility",
            "heating_type": "radiator_valve",
            "sensor": "04:055510",
            "devices": [
                "04:055510"
            ],
            "_sensor": "04:055510",
            "_actuators": [
                "04:055510"
            ]
        },
        "03": {
            "_name": "Guest Bed",
            "heating_type": "radiator_valve",
            "sensor": "04:055480",
            "devices": [
                "04:055480"
            ],
            "_sensor": "04:055480",
            "_actuators": [
                "04:055510"
            ]

I will make a permanent change from "devices": to "actuators": in the future.

(_sensor determines the sensor a different way to sensor)

1 Like

Hi I have a question ha works on virtalbox on Ubuntu must I also update python on Ubuntu or not ?

Hello,

I think you do not need to update python. In my case I was trying to run the code on a test machine which is different from my machine running HA. That’s why I had an out of date python version on it. If your machine is already running HA, it should have a fairly up to date version of python already (since it is necessary for HA) and so you should not have a problem.

@cinnamon How did you get on? Is it working now, or does the previous version start, but this one does not?

On the troubleshooting link… ‘s/evohome_rf/ramses_rf/g’ :slight_smile:

The beauty of it is that it is a wiki! :sunglasses:

Going back to the original issue, no sensor.07_014869_temperature data.

In the logs, I see the below:

2021-11-19 14:54:47 INFO (MainThread) [ramses_rf.message] || DHW:014869 | | I | dhw_temp | || {'temperature': 17.35}

I assume, hopefully correctly, that this is the hot water device broadcasting the temperature - and thus the nanoCUL can ‘hear’ the device.

And yet sensor.07_014869_temperature remains unavailable and has done since I upgraded from 0.14.x.

P.S. I deleted and recreated zone 03 and do not see any more Inconsistent State in the logs, much obliged.

@iMiMx What do you see for the state graph? Mine is OK (below) - you’ll see it is updated at least every hour…

(don’t worry about the temps - it’s not connected to a real DHW cylinder)

Nada.

I see the broadcasts though:

[core-ssh config]$ grep DHW home-assistant.log
2021-11-19 14:02:58 INFO (MainThread) [custom_components.evohome_cc.water_heater] Found a DHW controller, id=01:050858_HW
2021-11-19 14:54:47 INFO (MainThread) [ramses_rf.message] || DHW:014869 |            |  I | dhw_temp         |      || {'temperature': 17.35}
2021-11-19 15:54:47 INFO (MainThread) [ramses_rf.message] || DHW:014869 |            |  I | dhw_temp         |      || {'temperature': 17.35}
2021-11-19 16:33:33 INFO (MainThread) [ramses_rf.message] || DHW:014869 |            |  I | dhw_temp         |      || {'temperature': 28.2}
2021-11-19 16:37:18 INFO (MainThread) [ramses_rf.message] || DHW:014869 |            |  I | dhw_temp         |      || {'temperature': 38.94}
2021-11-19 16:45:48 INFO (MainThread) [ramses_rf.message] || DHW:014869 |            |  I | dhw_temp         |      || {'temperature': 59.25}
2021-11-19 16:53:18 INFO (MainThread) [ramses_rf.message] || DHW:014869 |            |  I | dhw_temp         |      || {'temperature': 66.05}

I did restore_state: false already, after deleting/recreating the inconsistent state zone 03.

Thanks for the answer
Regular are different things of line and sometimes it comes back and the temp of the zone goes high
Iamb running the latest Ramses RF

Grateful if anyone is able to help me out - since the recent set of upgrades I’m no longer able to see any of Opentherm heating control (10:124973) parameters, they all return as “Unavailable”.

Possibly related, I do not believe my UFH heating zones are correctly configured given the empty value in the schema (below). Do I need to add my HCE80 (02:001786) into my config file, if so in what format?

underfloor_heating: {}

extracted from:

system:
heating_control: '10:124973'
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Living
heating_type: radiator_valve
sensor: null
devices:
- '04:254312'
'01':
_name: Small
heating_type: radiator_valve
sensor: '22:150839'
devices:
- '04:254306'
- '22:150839'
'02':
_name: Kitchen
heating_type: underfloor_heating
sensor: '34:175809'
devices:
- '34:175809'
'03':
_name: Main
heating_type: radiator_valve
sensor: '22:210057'
devices:
- '04:254288'
- '22:210057'
'04':
_name: Diner
heating_type: underfloor_heating
sensor: '34:176169'
devices:
- '34:176169'
'05':
_name: Bedroom
heating_type: radiator_valve
sensor: '22:206071'
devices:
- '04:127635'
- '22:206071'
'06':
_name: Family
heating_type: radiator_valve
sensor: '34:098094'
devices:
- '04:173599'
- '34:098094'
'09':
_name: Guest
heating_type: radiator_valve
sensor: '22:022442'
devices:
- '04:173603'
- '22:022442'

Config file below:

# Evohome
evohome_cc:
  serial_port: /dev/ttyACM0
  packet_log: packet.log
#  restore_state: false
  ramses_rf:
    enforce_known_list: true
  schema:
    controller: 01:081046
    system:
      heating_control: 10:124973
  known_list:
  - 01:081046
  - 02:001786
  - 04:254312
  - 04:254306
  - 04:254288
  - 04:127635
  - 04:173599
  - 04:173603
  - 10:124973
  - 18:132629
  - 22:150839
  - 22:150839
  - 22:210057
  - 22:206071
  - 22:022442
  - 34:175809
  - 34:176169
  - 34:098094

Do you have any of these messages in your HA logs:

2021-11-19 19:18:37 WARNING (MainThread) [ramses_rf.devices] RP --- 10:048122 18:006402 --:------ 3220 005 00C0121980 << OpenTherm: deprecating msg_id 0x12: it appears unsupported

Do you have any such sensors, not even one?

Please send me a packet log.

This is a bug (actually, it just hasn’t been implemented) in ramses_rf.

In future, it may look like this:

'04':
  _name: Diner
  heating_type: underfloor_heating
  sensor: '34:176169'
  actuators:
    - '02:001786_05'

@iMiMx Please send me a HA log, and your config, so I can get to the bottom of the missing sensor.

You will need this logging:

logger:
  default: warn
  logs:
    homeassistant.core: debug  # to see: Event state_changed, or not
    ramses_rf.message: info   # MSGs rcvd (excl. RQ/18:), is the one you usually want

I will need the contemporaneous packet log.

@iMiMx

Use this logging instead:

logger:
  default: warn
  logs:
    homeassistant.core: debug  # to see: Event state_changed, or not
    # custom_components.evohome_cc: info
    custom_components.evohome_cc.sensor: info
    ramses_rf.message: info   # MSGs rcvd (excl. RQ/18:), is the one you usually want
1 Like