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

[bishop]

Hello,

Sorry for the late reply, but here is what I see on my system:

• boiler_output_temp → looks the same (with values)
• boiler_return_temp → looks the same (permanently at 1 degree C)
• boiler_setpoint → The boiler_setpoint has data (looks ok), the ot_boiler_setpoint is unavailable
• ch_max_setpoint → ch_max_setpoint is unavailable, the ot_ch_max_setpoint has data (looks ok)
• ch_water_pressure → both unavailable
• dhw_flow_rate → both unavailable
• dhw_setpoint → dhw_setpoint is unavailable, the ot_dhw_setpoint has data (always at 0.1 degree C)
• dhw_temp → both unavailable
• outside_temp → both unavailable
• rel_modulation_level → both have data and the data are quite different. I have no clue which one is the most plausible one

[bishop]

Hi,

I’ve just update to 0.18.3 (I was running 0.17.13 before because the versions 0.18.1 and 0.18.2 would not start on my system - see error logs already provided in a previous post).

The good news is that 0.18.3 starts and I can now see the heat demand of one of my UFH zone . This is the first time I see that, previously none of my UFH zone would be available.
The heat demand for the other UFH zones are still unavailable unfortunatelly and I have the follwoing errors:

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:592
Integration: Sensor (documentation, issues)
First occurred: 10:31:59 PM (1 occurrences)
Last logged: 10:31:59 PM

Platform evohome_cc does not generate unique IDs. ID 02:024358-heat_demand already exists - ignoring sensor.02_024358_heat_demand

Logger: homeassistant.components.sensor
Source: custom_components/evohome_cc/sensor.py:129
Integration: Sensor (documentation, issues)
First occurred: 10:31:59 PM (2 occurrences)
Last logged: 10:31:59 PM

Error adding entities for domain sensor with platform evohome_cc
Error while setting up evohome_cc platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
    original_icon=entity.icon,
  File "/config/custom_components/evohome_cc/sensor.py", line 175, in icon
    return "mdi:power-plug" if self.state else "mdi:power-plug-off"
  File "/config/custom_components/evohome_cc/sensor.py", line 129, in state
    return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:98
First occurred: 10:27:10 PM (3 occurrences)
Last logged: 10:47:10 PM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 131, in wrapper
    return fnc(self, discover_flag=discover_flag)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1124, in _discover
    [self._make_cmd(_000A, payload=ufh_idx) for ufh_idx in self._circuits_alt]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1176, in _circuits_alt
    if msg := self._msgz[_0005][RP]["0009"]:  # also 0000, 0004
KeyError: '0005'

I send you a PM with my packetlog in parallel in case you need it.

[jonboy]

Running 0.18.3 now and have amended settings as follows

  ramses_rf:
    enforce_known_list: true
    # disable_discovery: true
    disable_sending: true
    # enable_eavesdrop: true 

On startup I see two very similar errors:

2022-01-28 10:40:04 ERROR (MainThread) [homeassistant.components.sensor] Error adding entities for domain sensor with platform evohome_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
    original_icon=entity.icon,
  File "/config/custom_components/evohome_cc/sensor.py", line 175, in icon
    return "mdi:power-plug" if self.state else "mdi:power-plug-off"
  File "/config/custom_components/evohome_cc/sensor.py", line 129, in state
    return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'

2022-01-28 10:40:04 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up evohome_cc platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 257, in _async_setup_platform
    await asyncio.gather(*pending)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
    original_icon=entity.icon,
  File "/config/custom_components/evohome_cc/sensor.py", line 175, in icon
    return "mdi:power-plug" if self.state else "mdi:power-plug-off"
  File "/config/custom_components/evohome_cc/sensor.py", line 129, in state
    return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'

I also see very different data collected now, presumably as a result of using “disable_sending: true” for example:

boiler_output_temp - Unavailable
OT boiler_output_temp - Working

boiler_setpoint - Working
OT boiler_setpoint - Unavailable

I am fairly certain that prior to setting “disable_sending: true”, the UFH controller was being disrupted in some way. I am (and have been for the last couple of weeks) paying close attention to the UFH system as it is new . I have not seen any behaviour which might be considered strange when the evohome_cc is not running, nor when sending is disabled. However, when sending has been enabled the UFH controller has gone into an error state (0.17.3) and has flashed error lights (which I have only noticed whilst walking past the UFH controller). In addition, Zones have switched off with 100% demand showing on the controller, zones have switched on with 0% demand showing on the controller. Of course, at present I have no definitive proof of the link between what evohome_cc is doing and the odd behaviour I am seeing.

[stevieb12345]

I’ve not had any more of these.

[Heathy65]

Being a newbie to evohome_cc I have some questions I’d appreciate some help on:

1. I’m having issues with the yaml configuation. I have the basic communication up and running but some commands in the evohome_cc wiki seem to break things. For example if I add the “restore_state: true” command to my configuration then the HA “Check Configuration” operation hangs and if I try a Restart Core I get a “Failed to restart Home AssistantCore. string indices must be integers” error. As an aside, even if I put a dumb command in the YAML I assume it shouldn’t hang?

2. What is the “send_packet:” command/option for?

3. I’ve seen the alias command in some configurations, what’s its use/purpose:

known_list:
  - '01:188379' : {"alias": "--controller--"} # Controller

4. Is there a definitive list of configuration parameters (for the yaml file) anywhere, as a reference. Initially I was using some depreciated ones in error.

5. Re. the schema (which I can see in the HA logs), is there a mechanism to map the zone names to the relevant xx:yyyyyy items or does that need to be done by hand, i.e. the names of all the RAMSES RF entities in HA.

6. Currently I still have the standard HA Integration for evohome running too. Is that considered bad practice or will they both play-nice together.

Thanks in advance.

[zxdavb (David Bonnes)]

@all I would be very grateful it you could help each other out as much as possible - so I can concentrate on doing only what I can do.

If someone remains stuck after help from the community, I will chip in.

@Heathy65

Is there a definitive list of configuration parameters (for the yaml file) anywhere, as a reference. Initially I was using some depreciated ones in error.

Also, if the wiki is out of date - and it is - it would help if people worked to keep it up to date for the benefit of everyone.

@Heathy65

For example if I add the “restore_state: true

For example, it’s restore_cache: true.

@Heathy65

Currently I still have the standard HA Integration for evohome running too. Is that considered bad practice or will they both play-nice together.

No, and N/A.

… I’ve got a long to-do list here, over to you.

[bishop]

Hi,

I’ll try to answer to the best of my knowledge but I might be wrong on some points (anyone should feel free to correct me if this is the case).

Answers to your question:

1. the “restore_state: true” has been changed to “restore_cache: true” in the configuration ( this was a breaking change which happened a few version back). Changing this should solve your problem.

2. I’m not 100% sure what you mean here. If it’s a question about an option in the yaml configuration, you can use some advanced options to do eavesdropping only without sending packets. I believe send_packet might be one of the option you can use to prevent the dongle emitting packets in case you want to do eavesdropping (but I never used this so I am really unsure here).

3. The alias enables you to provide more information for some devices. This can be necessary in some cases (faked sensor, ventillation unit, RF remote control, …). For the other cases like the controller case you mention this is just a way to add information to help you read your schema so you know which device corresponds to what.

4. I think the best place to start is the Github wiki. David is developping the project quickly at the moment and it evolves every week (thanks again Davis ) so this information can be a bit out of date and needs to be complemented with the posts from this forum discussion.

5. That’s where the Alias can help. Once you have mapped a device name to a zone you can put the corresponding alias in you config to remember this mapping. Concerning the entity displayed in HA, you need to rename them by hand as far as I know.

6. I also have the cloud based evohome integration running in parallel and have not had any problem beause of this so far. As far as I know this is not a problem (and David is the one who developped both integrations).

edit: Sorry was typing while David replied in parallel so some of my answers may be redundant to what David already said…

[zxdavb (David Bonnes)]

@bishop

…you can use some advanced options to do eavesdropping only without sending packets. I believe send_packet might be…

send_packet: true enables the send_packet service call. It allows you to broadcast bespoke packets via RF. I doubt it would be of value to most, especially as it does not yet allow impersonation.

The only parameters it accepts presently are:

parameter	description	example
device_id	The destination device_id.	01:123456
verb	The packet verb, one of: I, RQ, RP, W.	RQ
code	The packet code (class).	1F09
payload	The packet payload as a hexadecimal string.	00

[bishop]

I didn’t know a send_packet service existed. I am very interested to use it to simulate packets sent from my RF remote control to control my ventillation (for instance to boost it temporarily instead of having to press on the button of the remote control).

I am trying to emulate this type of packet:

2022-01-11T13:28:06.767137 063  I --- 29:156898 32:132125 --:------ 22F3 007 00020F03040000

I have added the send_packet: true in my configuration and tried to send packets using the following service call (and various variation on it):

service: evohome_cc.send_packet
data:
  device_id: '32:132125'
  verb: I
  code: 22F3
  payload: 00020F03040000

I get the following error:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/connection.py:134
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 1:30:36 PM (7 occurrences)
Last logged: 3:00:14 PM

[139955753060912] Error handling message: value must be one of [' I', ' W', 'RP', 'RQ'] for dictionary value @ data['verb']. Got None
[139955753060912] Error handling message: does not match regular expression ^[0-9A-F]{4}$ for dictionary value @ data['code']. Got None value must be one of [' I', ' W', 'RP', 'RQ'] for dictionary value @ data['verb']. Got None
[139955475062448] Error handling message: value must be one of [' I', ' W', 'RP', 'RQ'] for dictionary value @ data['verb']. Got None

Am I doing something wrong ?

[jonboy]

@All long standing evohome_cc users

As David mentions, the Wiki at Home · zxdavb/evohome_cc Wiki · GitHub is not up to date. Being a newbie to evohome_cc, I have struggled to put together a complete configuration. And reading this entire thread is probably not realistic given its length. I have just amended the Wiki to correct the “restore_cache” option. I’m happy to make some other changes to the Wiki to simplify the getting started steps for other newbies.

To do so, I need to be reasonably certain that I understand things myself. To that end, it would be helpful if others who have fully working and comprehensive evohome_cc configs could post them here or PM them to me. I think it would also be helpful to have logger configs too. I think my config below (slightly simplified from what I am actually running) is all correct. I am unclear on exactly how the alias bit can be used and I removed it because it was not doing what I wanted.

evohome_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log: packet.log
  restore_cache: true
  ramses_rf:
    enforce_known_list: true
    # disable_discovery: true
    disable_sending: true
    # enable_eavesdrop: true 
  schema:
    controller: 01:123456
  known_list:
    - 01:123456
    - 02:234567
    - 04:456789
    - 07:789012
    - 10:101234
    - 13:134567
    - 18:189012
    - 34:345678

logger:
  default: warn
  logs:
    ramses_rf: warn
    ramses_rf.message: warn
    evohome_rf.packet_log: debug

Please let me know if I’ve got anything wrong, and I’d appreciate explanation of the detail of the alias feature. Once I’m clear I’ll spend a bit of time updating the Wiki.

[zxdavb (David Bonnes)]

This is the only logging you should bother with:

  logs:
    # homeassistant.core: debug  # to see: Event state_changed, or not

    # custom_components.evohome_cc: info  # use info for Schema =

    ramses_rf.message: info                # MSGs rcvd (excl. RQ/18:), is the one you usually want
    # ramses_rf.protocol.protocol: info    # PKTs sent (excl. retries) & rcvd
    # ramses_rf.protocol.transport: info   # RF Tx'd (incl. retries) & Rx'd

See: https://github.com/zxdavb/evohome_cc/wiki/5.-Troubleshooting

Note that the above makes no mention of the gateway, active_fault & schema binary sensors, but should.

[zxdavb (David Bonnes)]

@bishop Your Zone 5 is misconfigured:

> cat .secrets/bishop/*.log | grep -v RQ | unix2dos | grep -E ' 000[5C] ... 0[45]0[48]' | python client.py -rr parse

22:26:56.008 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0408 || {'zone_idx': '04', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:240790']}
22:26:56.033 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0508 || {'zone_idx': '05', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': []}
22:26:57.353 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0404 || {'zone_idx': '04', '_device_class': '04', 'device_class': 'sensor', 'devices': ['04:240790']}
22:26:57.402 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0504 || {'zone_idx': '05', '_device_class': '04', 'device_class': 'sensor', 'devices': ['04:081013']}

The TRV, 04:081013, needs to be rebound as an actuator (it is correctly bound as a sensor) - I believe the zone is called Bathroom 2nd.

[zxdavb (David Bonnes)]

@jonboy

TypeError: unsupported operand type(s) for *: 'Message' and 'int'

This will be fixed in 0.18.4.

[zxdavb (David Bonnes)]

So, 0.18.5 has been released as a pre-release.

If you have UFH, then the 0.18.x releases are for you, but they are not as stable as the latest 0.17.x release.

Note that it removes duplicate OTB sensors from HA, and is a little friendlier with HGI80s.

The UFH zones should have heat demand now.

Please report any bugs.

[zxdavb (David Bonnes)]

@bishop

Am I doing something wrong ?

It’s got a space before the I (I will address this).

service: evohome_cc.send_packet
data:
  device_id: 32:132125
  verb: " I"
  code: 22F3
  payload: 00020F03040000

With the lack of impersonation, the PIV may not elect to accept the packet.

There are plans to expose things like this PIV as FAN entities.

[Robvde]

I updated to 0.18.5 from 0.18.3 and got this error 8 times in the last hour

2022-01-31 09:11:50 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 131, in wrapper
    return fnc(self, discover_flag=discover_flag)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1128, in _discover
    [self._make_cmd(_000A, payload=ufh_idx) for ufh_idx in self._circuits_alt]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1195, in _circuits_alt
    if msg := self._msgz[_0005][RP]["0009"]:  # also 0000, 0004
KeyError: '0005'

[zxdavb (David Bonnes)]

Please post (or PM me) - configuration.yaml, please PM a packet log.

Could you try:

  schema:
    controller: 01:040078
    system:
      heating_control: 10:025262
    underfloor_heating:
      02:013748: {}

[Robvde]

I have sent a PM and adjusted the suggested config.

[bishop]

I’ve update to 0.18.5 and I also have the same error as Robvde:

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:98
First occurred: 2:02:17 PM (1 occurrences)
Last logged: 2:02:17 PM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 131, in wrapper
    return fnc(self, discover_flag=discover_flag)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1128, in _discover
    [self._make_cmd(_000A, payload=ufh_idx) for ufh_idx in self._circuits_alt]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1195, in _circuits_alt
    if msg := self._msgz[_0005][RP]["0009"]:  # also 0000, 0004
KeyError: '0005'

edit:
I’ve also tried adding what you advised to my configuration (with the values of my system), but it did not help:

schema:
    controller: 01:076010
    system:
      heating_control: 10:052644
    underfloor_heating:
      02:024358: {}

[zxdavb (David Bonnes)]

@bishop

KeyError: '0005'

fix coming - testing now