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

Share your Projects!
2313

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.

2314

I’ve not had any more of these.

2315

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

  1. 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.

  2. 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.

  3. 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.

2316

@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.

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.

For example, it’s restore_cache: true.

No, and N/A.

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

1 Like
2317

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 :slight_smile: ) 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…

1 Like
2318

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
2319

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 ?

2320

@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.

2321

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.

2322

@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.

2323

This will be fixed in 0.18.4.

2324

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.

2325

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.

2326

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'
2327

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: {}
2328

I have sent a PM and adjusted the suggested config.

2329

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: {}
2330

fix coming - testing now

2331

I try to send a packet with: send_packet to my itho fan. (just to try)
But i get the error:

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 'Gateway' object has no attribute 'make_cmd'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 381, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 584, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1495, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1530, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 786, in check_permissions
    return await service_handler(call)
  File "/config/custom_components/evohome_cc/__init__.py", line 174, in svc_send_packet
    broker.client.send_cmd(broker.client.make_cmd(**call.data))
AttributeError: 'Gateway' object has no attribute 'make_cmd'

evofw = 0.7.1 and 0.18.5 just update with hacs

2332

fix coming - testing now