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

Share your Projects!
1600

This may be helpful:

  • however you configure evohome_cc, it wont change the controller’s opinion of reality

In your case, the controller’s reality is that 03:256005 is the sensor for a particular zone.

The faked hint just allows evohome_cc to be able to send temp packets when you make the put_zone_temp service call. That is, evohome_cc knows which device is each zone’s sensor, and you merely need to tell it which of those sensors should have faking enabled.

There is nothing stopping you from enabling faking on a real sensor, but you’d better turn off the physical device, else confusion will ensue when the controller is hearing from a sensor that keeps changing its mind as the the current temperature!

evohome_cc:
  config:
    # enforce_known_list: true
  schema:
    controller: 01:155341
  known_list:
  - 01:155341
  - 03:256005: {faked: true}
  - ...

Just make sure you put all your devices in the known_list. You can use the new schema entity to get that list, then enable enforce_known_list.

Everyone should have enforce_known_list: true as soon as they can, but don’t forget to update it if you add/remove a device.

Usefully, you will see these warnings in HA’s log file:

... Ignoring a non-allowed device_id: 12:010740, if required, add it to the known_list
1602

Updated to 0.14.6 - fix DHW temps, plus other issues

1603

Thank you, that is looking like DHW is working again. I have just noticed another issue though. The service call to evohome_cc.set_system_mode no longer works. I haven’t tested other service calls yet, but when trying to turn the system off I get this error in the logs:


Exception in async_handle_dispatch when dispatching 'evohome_cc': ({'unique_id': '01:073765', 'service': 'set_system_mode', 'data': mappingproxy({'mode': 'heat_off'})},) Traceback (most recent call last): File "/config/custom_components/evohome_cc/climate.py", line 422, in async_handle_dispatch self._call_client_api(self._device.svc_reset_system_mode, **payload[DATA]) AttributeError: 'Evohome' object has no attribute 'svc_reset_system_mode'

Edit: I seem to get this error when I try to set the mode via a service call or the gui, so my system is stuck in eco right now unless I use the Honeywell app to change it. Not sure if this is just my Home Assistant setup playing up, or a wider bug?

1604

I get

Logger: ramses_rf.protocol.command
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py:148 
First occurred: 7:28:59 (7 occurrences) 
Last logged: 7:30:05

validate_command(): 'ZoneModes' object has no attribute 'auto'
1605

For those with insufficent data in their lives:

sensor:
  - platform: template
    sensors:
      system_mode:
        friendly_name: "System Mode"
        value_template: "{{ state_attr('climate.controller', 'system_mode') }}"
        attribute_templates:
          system_mode: "{{ state_attr('climate.controller', 'system_mode').system_mode }}"
          until: "{{ state_attr('climate.controller', 'system_mode').until }}"

      f9_heat_demand:
        friendly_name: "F9 Heat Demand"
        unit_of_measurement: "%"
        value_template: "{{state_attr('climate.controller', 'relay_demands').F9 * 100}}"

      fa_heat_demand:
        friendly_name: "FA Heat Demand"
        unit_of_measurement: "%"
        value_template: "{{state_attr('climate.controller', 'relay_demands').FA * 100}}"

      fc_heat_demand:
        friendly_name: "FC Heat Demand"
        unit_of_measurement: "%"
        value_template: "{{state_attr('climate.controller', 'relay_demands').FC * 100}}"

      fc_relay_demand:
        friendly_name: "FC Relay Demand"
        unit_of_measurement: "%"
        value_template: "{{state_attr('climate.controller', 'heat_demands').FC * 100 }}"
1 Like
1606

This is a new bug introduced in 0.14.6 - I will sort it out tonight (i.e. bug identified & fixed, just testing).

1608

It’s not fixed for me in 0.14.7 sorry. Slightly different symptoms now though.

If I call the service evohome_cc.set_system_mode directly (using the developer tool / automations), I just get errors in the logs. It doesn’t matter which mode I use (auto, eco_boost, away, day_off, heat_off, or custom), they all error in the log. For example:

service: evohome_cc.set_system_mode
data:
  mode: heat_off

Gives me the error:

Exception in async_handle_dispatch when dispatching 'evohome_cc': ({'unique_id': '01:073765', 'service': 'set_system_mode', 'data': mappingproxy({'mode': 'heat_off'})},) Traceback (most recent call last): File "/config/custom_components/evohome_cc/climate.py", line 422, in async_handle_dispatch self._call_client_api(self._device.svc_reset_system_mode, **payload[DATA]) AttributeError: 'Evohome' object has no attribute 'svc_reset_system_mode'

If I use the HA interface itself against the climate.controller entity, I am able to set the ‘operation’ to Heat or Off (Auto doesn’t work, but that’s not critical). But, none of the presets (Eco, Custom, Away, etc) work at all. If for example I try to set the Eco preset:

validate_command(): Invalid args: For system_mode=02, until cant be None
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 140, in _wrapper
    return fcn(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 545, in set_system_mode
    raise ValueError(
ValueError: Invalid args: For system_mode=02, until cant be None
1609

Wow, two bugs in one (should be set_system_mode, not svc_set_system_mode) - fixed now.

Bug introduced in 0.14.6 - this is fixed now.

1611

:slight_smile: getting closer!

The Home Assistant GUI works fine now, I can select presets galore and it works straight away. But, via the direct service call it still fails but with a slightly different error now:

Exception in async_handle_dispatch when dispatching 'evohome_cc': ({'unique_id': '01:073765', 'service': 'set_system_mode', 'data': mappingproxy({'mode': 'heat_off'})},) Traceback (most recent call last): File "/config/custom_components/evohome_cc/climate.py", line 422, in async_handle_dispatch self._call_client_api(self._device.set_system_mode, **payload[DATA]) AttributeError: 'Evohome' object has no attribute 'set_system_mode'
1614

A bit closer… a new error:


Exception in async_handle_dispatch when dispatching 'evohome_cc': ({'unique_id': '01:073765', 'service': 'set_system_mode', 'data': mappingproxy({'mode': 'heat_off'})},) Traceback (most recent call last): File "/config/custom_components/evohome_cc/climate.py", line 424, in async_handle_dispatch kwargs["until"] = dt.now() + ( TypeError: unsupported operand type(s) for +: 'datetime.datetime' and 'NoneType'
1616

Try 0.14.10

1617

Jackpot! It all seems to be working now. Thanks for sorting this, I’ll see how it runs for a few days now :slight_smile:

1618

When adding a fake sensor do you add a physical sensor to the controller or just the ability to send fake temperature readings to the controller?

1619

From the controller’s point of view, it can’t really tell the difference between a real sensor, and a faked sensor (or a real sensor that was turned off, and is now faked)… all it ‘sees’ is an RF signal.

You can fake any sensor you like, but it is only useful if it is bound to a controller, and is bound as the sensor for a zone. This is just like buying a physical sensor (e.g. a DTS92), it is no good to you until it is bound to the controller as a sensor for a zone.

TL;DR: So, if I understand your question correctly:

  • you are just adding the ability to send fake temperature readings to the controller

NOTE: You do not need to have a physical sensor, but the virtual sensor (the faked sensor) still needs to be bound to the controller as the sensor for a zone.

1620

I’ve worked it out.

I used the evohome call service to fake a device and created a sensor 03:123456.

I then used my controller to remove my spare room sensor binding and used the call service start binding and I got the message that it was Successful.

I then used the call service fake a zone temperature and set my room to 30 and it worked, my evohome controller showed 30.

1621

Well done. Were these instructions helpful?

1622

Upgrading from 0.10.6 → 0.14.10 I noticed a few things with the Hot Water entity:

  • The temperature control seems to be missing, the below is what is seen on 0.10.6, this is not present on 0.14.10 (I left it running for a few hours before downgrading again)

  • Likely the same cause, the purple line disappears on the graph showing the target temperature. I upgraded around 06:44:

1623

I have identified this bug - will push an update later on today.

All: I am sorry for the large number of bugs in this drop - I have no automatic testing of evohome_cc and ramses_rf had a major refactor from 0.11.x

Please keep on reporting any bugs you find.

1 Like
1624

updated from 0.11.0 to 0.14.10 but only the BDR91 relay demand not available.

1625

Disappeared a few versions back for me, made a template with states.climate.controller.attributes.heat_demand to give me a percentage