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

[hamba]

I thought since DHW is working I’ll share my automation that turns it on when the water temperature drops below 40 deg while off.
If anyone can think of any improvements, please share.

$ cat automations.yaml
- id: '1614965419220'
  alias: Heat HotWater
  description: ''
  trigger:
  - platform: numeric_state
    entity_id: water_heater.stored_hw
    below: '40'
    attribute: current_temperature
  condition:
  - condition: state
    entity_id: water_heater.stored_hw
    state: 'off'
  action:
  - service: water_heater.set_operation_mode
    data:
      entity_id: water_heater.stored_hw
      operation_mode: 'boost'
  mode: single

[freekeys]

Hey all, I’m having an issue with the standard evohome and am wondering if the feature set in this project will help. As you can see in the chart below, the heating in one of my rooms takes a long time to kick in… annoyingly this is the nursery! So for example this morning the room was cold at 5.10am so we turned the heat up to encourage the heating on but it didn’t start heating until 5.40. Will setting this project up allow me to better understand what’s going on here? Or even to override evohome and force the valve on? Thanks!

[zxdavb (David Bonnes)]

@freekeys

I’m having an issue with the standard evohome and am wondering if the feature set in this project will help

How are you getting the green shaded areas with the ‘standard’ (official) evohome integration? It is not accurate & was removed (I think I removed it, anyway).

There is a dead band of 0.5C.

@freekeys

Will setting this project up allow me to better understand what’s going on here?

Yes - you will see the ‘truth’, as opposed to the fudge that was in the original integration (my fault - i put it there).

[kardiologia (Konstantinos)]

Dear zxdavb, with the latest version of evohome_cc, if I try to set_hvac mode off, I am getting the following error: Failed to call service climate/set_hvac_mode. ‘RadZone’ object has no attribute ‘frost_protect’

This was working in the previous versions
Thank you in advance

[zxdavb (David Bonnes)]

OK, just pushed v0.5.16 - some bugfixes, including:

• by @kardiologia

‘RadZone’ object has no attribute ‘frost_protect’

• by @phdelodder

‘RadZone’ object has no attribute ‘cancel_override’

and

    assert mode in ZONE_MODE_LOOKUP, mode
AssertionError: 00

[iMiMx (iMx)]

@zxdavb Do you prefer bugs reported here? Or on github? I was chatting with @phdelodder about a few things, he also noted the issue/fix with window sensors:

For the window open state you need to change line 23 of https://github.com/zxdavb/evohome_cc/blob/93622024ae852f233d75ec8b1a774e76de1fb1a7/custom_components/evohome_cc/const.py and the reason you can see https://github.com/zxdavb/evohome_rf/commit/2e7e1382f0a71216007e216a22a33bb1571ed9aa on file evohome_rf/devices.py at line 1018 and line 1026

[zxdavb (David Bonnes)]

@Hassiouser

Is this HA plug-in capable of managing two evohome systems through one HGI-80?

Well… It could, but someone would have to write the code… And given the small number of people in this use-case…

Try this work-around:

Duplicate the evohome_cc folder within in the custom_components folder:

custom_components
    evohome_cc
        __init__.py
        const.py
        ...
    evohome_cc2 
        __init__.py
        ...

Modify this line in evohome\const.py to say:

DOMAIN = "evohome_cc2"

Create a second entry in configuration.yaml:

evohome_cc:
  schema:
    controller: 01:111111
  ...

evohome_cc2:
  schema:
    controller: 01:222222
  ...

Make sure you have mutually-exclusive allow_lists.

And see what happens! If it doesn’t work - what error message did you get?

[zxdavb (David Bonnes)]

@iMiMx

Do you prefer bugs reported here? Or on github?

I would prefer github - there tends to be better bug reports then

[zxdavb (David Bonnes)]

@iMiMx

I was chatting with @phdelodder about a few things, he also noted the issue/fix with window sensors:

I believe I have just fixed this - I have pushed a new evohome_cc

[iMiMx (iMx)]

I have raised an issue on Github, when trying to set a Preset change on 0.5.16a:

Failed to call service climate/set_preset_mode

Results in:

Failed to call service climate/set_preset_mode set_zone_mode() takes 3 positional arguments but 6 were given.

[zxdavb (David Bonnes)]

OK, try 0.5.17 - sorry, stupid mistake.

[phdelodder (Philippe Delodder)]

There seems to be a new issue:

Set preset mode to none

[zxdavb (David Bonnes)]

OK, try 0.5.19

[phdelodder (Philippe Delodder)]

Set preset mode to none

it’s a different error now:

  File "/usr/local/lib/python3.8/site-packages/evohome_rf/command.py", line 520, in set_zone_mode
    assert mode in ZONE_MODE_MAP, mode
AssertionError: follow_schedule

[phdelodder (Philippe Delodder)]

When I look at my schema from 0.5.19 I have several orphans, when looking at 0.5.10 I don’t have any orphans. Is that something new in the latest evohome_rf and do I need to rebind or is this all good?

Version 0.5.19 (nanocul 0.6.14 evofw3):

Schema = {'controller': '01:223036', 'system': {'heating_relay': '10:040239'}, 'orphans': ['04:050559', '04:081849', '04:155407', '04:155445', '04:155533'], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {'00': {'heating_type': 'radiator_valve', 'sensor': None, 'devices': ['04:231774', '04:231772', '04:231776']}, '01': {'heating_type': 'radiator_valve', 'sensor': '04:231770', 'devices': ['04:231770']}, '02': {'heating_type': None, 'sensor': '04:155537', 'devices': []}, '03': {'heating_type': 'radiator_valve', 'sensor': '04:155551', 'devices': ['04:155551']}, '04': {'heating_type': None, 'sensor': None, 'devices': []}, '05': {'heating_type': None, 'sensor': None, 'devices': []}, '06': {'heating_type': None, 'sensor': None, 'devices': []}, '07': {'heating_type': 'radiator_valve', 'sensor': '04:155403', 'devices': ['04:155403']}, '08': {'heating_type': None, 'sensor': None, 'devices': []}, '09': {'heating_type': None, 'sensor': None, 'devices': []}}}

Version 0.5.10 (HGI80):

Schema = {'controller': '01:223036', 'system': {'heating_relay': '10:040239'}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {'00': {'heating_type': 'radiator_valve', 'sensor': None, 'devices': ['04:231774', '04:231772', '04:231776']}, '01': {'heating_type': 'radiator_valve', 'sensor': '04:231770', 'devices': ['04:231770']}, '02': {'heating_type': 'radiator_valve', 'sensor': '04:155537', 'devices': ['04:155537', '04:155533']}, '03': {'heating_type': 'radiator_valve', 'sensor': '04:155551', 'devices': ['04:155551']}, '04': {'heating_type': 'radiator_valve', 'sensor': '04:155443', 'devices': ['04:155443']}, '05': {'heating_type': 'radiator_valve', 'sensor': '04:155445', 'devices': ['04:155445']}, '06': {'heating_type': 'radiator_valve', 'sensor': '04:155407', 'devices': ['04:155407']}, '07': {'heating_type': 'radiator_valve', 'sensor': '04:155403', 'devices': ['04:155403']}, '08': {'heating_type': 'radiator_valve', 'sensor': '04:050559', 'devices': ['04:050559']}, '09': {'heating_type': 'radiator_valve', 'sensor': '04:081849', 'devices': ['04:081849']}}}

[zxdavb (David Bonnes)]

OK, I think I worked out why my testbed wasn’t working, try: 0.5.20

[iMiMx (iMx)]

I still need to digist and wiki-ise this - I saw the same:

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

I have one zone, zone 00: "00":{ "name":"Living Room", "mode":{ "mode":"follow_schedule", "setpoint":18.0 }, "config":{ "min_temp":5.0, "max_temp":35.0, "local_override":true, "openwindow_function":true, "multiroom_mode":false } }, Which has 2 TRVs: "04:055514":{ "temperature":21.78, "setpoint":"None", "battery_state":"None"…

David then responded, under the ‘The sync_cycle’ heading, in my understanding, stating it is not an/binding issue.

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

I will answer your question, but ask you to make it a wiki entry? Note: none of the RAMSES-II protocol is documented, so I could be wrong, but… Discovery vs Eavesdropping OK - there is a difference between: discovery, where - when asked - the controller tells evohome_rf the ‘truth’ of your configuration, and eavesdropping (where evohome_rf sniffs packets sent by any device to ‘learn’ how the system is configured (and will be ‘wrong’ is a device is badly configured’) Discovery was ‘disc…

" Note : a TRV does not need to be in a zone from the controller’s point of view to choose to accept this data and process it as if it was in the zone.

I understand that this is not a problem and accounts for the ‘orphan’ with the controller still able to trigger it as required."

[zxdavb (David Bonnes)]

@phdelodder

When I look at my schema from 0.5.19 I have several orphans, when looking at 0.5.10 I don’t have any orphans. Is that something new in the latest evohome_rf and do I need to rebind or is this all good?

WIthout looking at you schema…

There was a enhancement to evohome_cc, where all devices seen by evohome_rf are now shown up as sensors, that is, now including those that are ‘true orphans’.

Because of the above change, the devices key was removed from Status = {"devices": {... (status of devices known to the system), and now is a separate entry, Devices = {... (status of all known devices).

There are two slightly different definitions of an orphan:

• a device that is bound to your controller, or - more likely - believes it is bound to your controller, but does not (yet) have a parent (perhaps it was not bound properly) - a parent is a zone, or DHW, or heating-control - because it has no parent, it has no ‘home’ in the schema
• a device that is not bound to your controller at al - a true orphan - these may become system orphans later on (or never), and even children after that (or never)

A true orphan is a device (e.g. a TRV) that has been eavesdropped rather than discovered - most likely it actually belongs to another controller. (@Hassiouser this will help you a little - you can get all your devices, but not both systems).

Here below, orphans are devices that belong to the system, but have no home (as yet) under system, stored_hotwater, underfloor_heating, or zones.

Schema = {
    'controller': '01:145038', 
	'system': {'heating_relay': '13:237335'}, 
	'orphans': ["13:123456"], 
	'stored_hotwater': {}, 
	'underfloor_heating': {}, 
	'zones': {
        ...
	}
}

Issues surrounding the above can be managed with allow lists (or less well, with block lists), which is strongly recommended.

Fell free to add this to the wiki.

[zxdavb (David Bonnes)]

Guys, you need to be aware.

NOTE: If you restart HA often, you will exceed the RF duty cycle and your system will not behave as expected.

evohome_rf sends a huge number of packets when it starts up as part of discovery & has a lot of intelligence surrounding that to ensure things go smoothly, despite it clearly exceeding the RF duty cycle.

If you restart evohome_rf often (e.g. by restarting HA often) within a short period of time, then it will perform discovery back-to-back, which will result is an excessive number of RQ packets been sent via RF.

The controller will stop responding to these RQs for an extended period of time, and discovery will fail to work. There will be nothing to do, but wait (or reboot the controller), and then restart HA.

The situation is even worse if you are using a HGI80 instead of a evofw3-based device - you will have you power-cycle the HGI80 to get it working again.

An example of what you will likely see is an incomplete schema, where previously it was complete.

[phdelodder (Philippe Delodder)]

Seems fixed, altough my test env needs some rest now, guess I had it restart one to many times.