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

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

fix coming - testing now

The UFH demand in evohome_cc (0.18.5) does not match the demand shown on the Evohome controller, for example:

Dining Room heat_demand
from evohome_cc: 77.0%
from evohome controller: 44%

Hall heat_demand
from evohome_cc: 49.0%
from evohome controller: 14%

Living Room heat_demand
from evohome_cc: 82.0%
from evohome controller: 58%

For radiators they do match, for example:

Bed 1 heat_demand
from evohome_cc: 51.0%
from evohome controller: 51%

In the file ./config/.storage/evohome_cc the UFH controller is listed under the main_controller as both an ā€œorphanā€ and ā€œunderfloor_heatingā€:

    "data": {
        "client_state": {
            "schema": {
                "main_controller": "01:164379",
                "01:164379": {
                    "system": {
                        "heating_control": "10:047712"
                    },
                    "orphans": [
                        "02:020364"
                    ],
                    "stored_hotwater": {
                        "hotwater_sensor": "07:046947",
                        "hotwater_valve": "13:120242",
                        "heating_valve": null
                    },
                    "underfloor_heating": {
                        "02:020364": {
                            "circuits": {}
                        }
                    },

I have copied all config files and logs to the shared drive I PMā€™d previously.

So, 0.18.6 has been released - it includes UFH/OTB/send_packet bugfixes.

Please re-check using 0.18.6 and report accordingly - you will likely need to submit a new packet log.

I think I know what it is - but the first pair should have been - 77% / 46% - the rest are OK.

1 Like

Thx for your great work! I was just thinking about controlling itho fans. When you want to control the itho box you have to join a ā€œremoteā€ before you can control it. When you make the itho 15 seconds without power and then power it on you can join a remote.

The issue is this:

2022-01-10T11:06:30.721732 059  I 095 --:------ --:------ 02:153425 22F1 003 000304

2022-01-10T11:06:30.839724 059  I 096 --:------ --:------ 02:153425 22F1 003 000304
2022-01-10T11:06:30.887763 059  I 096 --:------ --:------ 02:153425 22F1 003 000304
2022-01-10T11:06:30.941539 060  I 096 --:------ --:------ 02:153425 22F1 003 000304

2022-01-10T11:06:31.000235 059  I 097 --:------ --:------ 02:153425 22F1 003 000304
2022-01-10T11:06:31.053543 059  I 097 --:------ --:------ 02:153425 22F1 003 000304
2022-01-10T11:06:31.107448 059  I 097 --:------ --:------ 02:153425 22F1 003 000304

2022-01-10T11:18:30.445878 059  I 098 --:------ --:------ 02:153425 22F1 003 000304

If you look, you see triplets of packets from the switch (the remote) - 3x, so the fan is sure to hear. Each triplet shares has a monotonically increasing sequence number: 095, 096, 097, 098ā€¦

Not all switches to do this.

Anyway, ramses_rf can easily impersonate the switch (the remote), it just needs to know the right sequence numberā€¦ But then the real switch will be out of syncā€¦

The alternative is to add evohome_cc as a second switch - can your fan handle two switches?

Unless the fan is willing to ignore the sequence number (I donā€™t know the answer to that), you will need to wait for a new version of evohome_cc.

For the sharp-eyed among you - @cinnamon has a switch with a device ID that starts with 02: - this caused me a lot of griefā€¦ So much grief.

You can use i think max 3 or 4 remotes. I use the normal one and an esphome remote. That is a nodemcu with a cc1101 module with esphome.
Works great but if it could with your project is even better!

@Robvde

Wow! I just got a look at your packet log:

> cat .secret*/rob*/*.log | grep -E '(I|RP).* 000[5C] ' | python client.py -c .secrets/robvde.json parse
08:01:32.598 || CTL:040078 | HGI:013217 | RP | system_zones     | 0008 || {'_device_class': '08', 'zone_mask': [0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'radiator_valve'}
08:01:32.692 || CTL:040078 | HGI:013217 | RP | system_zones     | 0009 || {'_device_class': '09', 'zone_mask': [1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'underfloor_heating'}

Good so far, right - says youā€™ve got 8 zones

  • zones 0, 1, 2, 3 are underfloor heating zones, with an HCE80 as the actuator
  • zones 4, 5, 6, 7 are radiators zones, with TRVs as actuators

But thenā€¦

10:25:39.417 || CTL:040078 | HGI:013217 | RP | zone_devices     | 0408 || {'zone_idx': '04', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['10:025262']}

Notice the actuator is 10:025262, the OTB (R8810A, R8820A) - this is crazy!

It should look like this:

10:25:40.470 || CTL:040078 | HGI:013217 | RP | zone_devices     | 0404 || {'zone_idx': '04', '_device_class': '04', 'device_class': 'sensor', 'devices': ['04:233367']}

ā€¦ where the devices consist of TRVs, starting with 04:, not an OTB - all 4 TRV zones are equally misconfigured.

Who installed your system? Does it work as expected?

The way is should work is: the TRVs send demand to the controller - the controller pools/modifies those demands and send them to the OTB

Iā€™ve update to 0.18.6, so far no errors to report.

I have the following warning which I donā€™t rember seeing before:

Logger: ramses_rf.devices
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/devices.py:1490
First occurred: 9:16:52 AM (4 occurrences)
Last logged: 9:21:52 AM

RP --- 10:052644 18:198151 --:------ 1300 003 007FFF < OTB: deprecating code 0x1300: it appears unsupported
RP --- 10:052644 18:198151 --:------ 12F0 003 007FFF < OTB: deprecating code 0x12F0: it appears unsupported
RP --- 10:052644 18:198151 --:------ 1260 003 007FFF < OTB: deprecating code 0x1260: it appears unsupported
RP --- 10:052644 18:198151 --:------ 1290 003 007FFF < OTB: deprecating code 0x1290: it appears unsupported

I have no heat demand for my underfloor heating but this is most probably due to my HCE80 not responding for a reason I still have not figured out (weā€™ve already discussed this via PM).

Thanks again for the hard work.

Great!

The above warnings are appropriate. The system will stop polling for these data, as they are not valid values - 1300 is CH water pressure.

Now Iā€™m looking, I have another system doing this. Please:

  1. provide me with a copy of your schema
  2. restart HA with enable_eavesdrop: true
  3. provide me with a copy of that schema (after a few hours, please)

And weā€™ll come up with a plan.

The UFH demand in evohome_cc (0.18.6) does not match the demand shown on the Evohome controller, for example:

Dining Room heat_demand
from evohome_cc: 69.0%
from evohome controller: 30%

Hall heat_demand
from evohome_cc: 44.0%
from evohome controller: 11%

Living Room heat_demand
from evohome_cc: 77.0%
from evohome controller: 49%

For radiators they do match, for example:

Bed 3 heat_demand
from evohome_cc: 11.0%
from evohome controller: 11%

I have copied all config files and logs to the shared drive I PMā€™d previously.

There is a data-point being collected: ā€œ10:047712 valueā€ which is an integer between 1 and 9 inclusive. Any hints (related to the OpenTherm side and possibly correlates with demand to some extent) as to what this data-point is, as I havenā€™t been able to figure it out yet?

OK, I make it:

  • 69/29% (close)
  • 44/11%
  • 77/51% (close)

I can make this fix - would be worthwhile just to have someone confirm they are seeing it too.

No idea! I have a bunch of these Iā€™m investigating - this is a likely one, called value, so Iā€™ve added it in, along with percentage.

Iā€™m hoping someone will tell me, or I will be able to work it out in someoneā€™s packet log.

When that happens, I have another dozen or so to try.

BTW, I am not sure if it is a value, or a bunch of bit flags.

Quite possible I have misunderstood but I have values for ā€œ10:047712 ch_water_pressureā€ which appear valid and are very useful. (My boiler is not readily accessible and only displays pressure if switched off. The UFH pressure is 2 floors lower and so has a substantial differential & canā€™t be captured either.)

Also, I have not seen issues with the UFH controller since switching to 0.18.x.

The information I am able to collect is very helpful, particularly that that derives from the OTB. This integration is surpassing what I had hoped for and I very much appreciate all the effort @zxdavb is putting into it.

along with percentage

I see a correlation between:

01:164379 heat_demand
10:047712 percent

BTW, I am not sure if it is a value, or a bunch of bit flags.

Iā€™ll keep looking at this and widen my thinking to include it being bit flags.

The above warnings are appropriate. The system will stop polling for these data, as they are not valid values - 1300 is CH water pressure.

@jonboy: that is why youā€™re not getting the same warnings as @bishop, and so your system will contine to poll these data.

Reporting these values just seen, as they are a bit different (0% on controller):

Dining Room heat_demand
from evohome_cc: 36.0%
from evohome controller: 0%

Hall heat_demand
from evohome_cc: 44.0%
from evohome controller: 0%

Living Room heat_demand
from evohome_cc: 79.0%
from evohome controller: 51%

I then looked again a few minutes later and the values were:

Dining Room heat_demand
from evohome_cc: 35.0%
from evohome controller: 0%

Hall heat_demand
from evohome_cc: 45.0%
from evohome controller: 11%

Living Room heat_demand
from evohome_cc: 79.0%
from evohome controller: 51%

In spite of the Evohome Controller showing 0% demand for Dining Room, the zone actuators were ā€œonā€.

Iā€™ll not post any further updates for now, unless @zxdavb lets me know it would be helpful to do so. (Packet logs, etc updated on shared drive.)

Can everyone with UFH please let me know if they have a HCC80, or a HCE80?

@Robvde @bishop Can you specifically let me know.

I have a HCE80 for my UFH

@zxdavb, we own a HCE80 for UFH and HRA80 as External Antenna.

Who installed your system? Does it work as expected?

It has been installed for 5 years and works as expected.
I will see if the controller can be reconfigured.

Running 0.18.6 and no bugs