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

Share your Projects!
1094

In version 0.6.6 the default was AdvancedOverride when changing you setpoint using the standard thermostat card. So If you want it back in the current version (0.7.9), change line 248 in custom_components/evohome_cc/climate.py

self.svc_set_zone_mode(setpoint=kwargs.get(ATTR_TEMPERATURE))
to
self.svc_set_zone_mode(setpoint=kwargs.get(ATTR_TEMPERATURE), mode=ZoneMode.ADVANCED)

My main reason is that I have a schedule defined in Evohome and through HA interface it’s easy to make a temporary change, knowing that for some reason at some point in time the Evohome will set it back at to the schedule setpoint.

I have looked at changing the services calls using the custom card (simple-thermostat), still can’t seem to figure out on how to change to use the evohome_cc service calls. If someone could provide me with an example that would be great.

If default zone mode could be configurable that would also be a nice addition.

1095

Had spotted that this had changed yet - I upgraded to 0.7.9 from 0.6.6 - might have to do the same hack. Otherwise, it’s only a matter of time before my other half adds an override after I’ve gone to bed…and it will run all night, presumably.

1096

Need to gather some more information, but has any one else on 0.7.9 noticed the below? This is around 48 hours after the last restart

  • Stored Hot Water, battery sensor not showing? All other battery sensors are showing, just not ‘binary_sensor.07_014869_battery’
  • Stored Hot Water, temperature sensor showing as unavailable? The water_heater entity shows the temperature, but the older ‘sensor.07_014869_temperature’ does not

Wondered if it might actually be a battery issue coinciding with the last restart/update, but water_heater entitying is showing temperatures, so presumably not:

1097

Yes, this was taken out of evohome_cc, with an intention to have moved it to evohome_rf. This was because of compatibility issues, which are more easily addressed evohome_rf (the ‘Profile’ feature).

I am working on this and will be introducing it soon. The first feature (nearly complete) is a structured way of enabling eavesdropping.

1098

DHW attributes, like those of zones comes from the controller and not from any other device (the only exception to this is a zone’s heat_demand). In addition, the DHW sensor device has it’s own HA entities:

  • battery level, and
  • (current) temperature

The distinction between a water_heater entity and the DHW sensor entities may not make much sense in this case, but the DHW is just a fancy type of zone, and so it’s useful to consider a zone with:

  • a round thermostat, and
  • two TRVs

This will result in the following attributes (in this case HA sensors):

  • 3 x battery levels
  • 3x (current) temperature
  • 2 x heat demand
  • 2 x window state

But the zone attributes include:

  • current temperature & setpoint
  • heat demand
  • mode, etc.

For example, the zone does not include a battery level.

[ That is, the evohome devices provide sensor data to the controller - which constructs zones/DHW from that data, and send instructions to relays & actuator devices (which affect the sensor data & so on). ]

With this in mind, it seems the controller can see the DHW sensor, but either:

  • the USB dongle cannot ‘hear’ the DHW sensor (the RF signal reaches the controller, but not the dongle), or
  • the DHW sensor just wasn’t created for some reason?

I assume it used to work before? And the issue survives restarts of HA? If so, I’d say it was a bug in the new restore_state feature?

You are welcome to provide a HA log / packet log pair & I can have a look at it.

1099

Just pushed v0.8.0 - expect bugs, as usual - please report them here for now.

There are two major features (and other minor changes/fixes/etc):

Don’t Restore State

If your saved state is ‘bad’ - this will prevent the system restoring the saved state on HA startup:

evohome_cc:
  restore_state: false
  scan_interval: 30

Notice that this is under evohome_cc: because it is an instruction to evohome_cc.

As you’d expect, state is still saved every 3 minutes, and so you can subsequently restart HA without this switch, then the new state will be restored.

Setting a shorter scan_interval may be useful when you’re in a hurry to make a new state, however: the interval at which the state is saved is hard-coded to 3 minutes.

Eavesdropping

Sometimes discovery just doesn’t work. In these cases, you can use a hard-crafted schema, or enable eavesdropping :

evohome_cc:
  config:
    enable_eavesdrop: true

Notice that this is under config: because it is an instruction to evohome_rf.

I recommend you do not use enable_eavesdrop unless required.

The main use for this would be for this with HR80s - it can be used instead of a hard-coded schema. Both these options are not without their issues…

It can eavesdrop:

  • devices as members of a zone (e.g. HR80s)
  • devices as sensors for a zone (including the controller as a sensor - I am not sure if this is useful)
  • the heating relay (boiler control / appliance control device - useful for battery-powered controllers)

Note that some devices, such as HM80s, do not ‘speak’, and so cannot be eavesdropped.

Entity Attributes

Not new this drop, but recently added:
image

1100

Thanks David! Will test this out tomorrow. Cheers also for the override explanations.

1101

David, first let me tell you that I greatly appreciate your work. This alllows me to have a greater insight in what is happening on my EVOhome network. I already saw some “questionable” aspects of my home setup, something I need to talk to my vendor about. Also, I am a complete n00b in terms of what I can and cannot expect in this integration, so I might very well have overlooked an answer that has already been given.

Having said that, I see a lot of entities appearing when I run this integration, but no devices that “link the entities together”. Is this on purpose?

1102

HA’s general strategy is to split a a ‘real-world’ thing into as many entities (in this case Sensor, BinarySensor, Climate & WaterHeater entities) as required, then recombine them (usually the Sensors/BinarySensors) into Devices (a HA term) as is sensible.

It is up to evohome_cc to do this second step, and that is on a to-do list - it may happen at some future stage.

Now you got me curious!

1103

Oh, nothing big. The vendor quoted a setup with underfloor heating and a BDR91 on/off boiler relay, and installed a R8810 Opentherm relay. Honeywell doesn’t support this setup.

I found it because the boiler relay shows as ID 10:xxxxxx instead of 13:xxxxxx.

1104

My controller is in my hallway, so rather than using the TRVs temperature measurement on the hallway radiator (and so I didn’t have to install another thermostat in a ‘reasonable’ place), I use the controller sensor for the hallway zone. So being able to see this value would be useful in this scenario?

1105

It did, on 0.6.6, yes.

Just upgraded to 0.8 + patches, with ‘restore_state: false’ for the HA restart, temperature sensor data is there again now for the DHW. Am hopeful that the battery state will be learnt as well in due course.

Many thanks.

1106

@zxdavb Spotted this appearing a couple of times in my logs. Any ideas what is happening? Initially thought it might be a neighbours device so I’m now running with an allow list which doesn’t include the rouge controller.

Logger: evohome_rf.message
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/message.py:621 
First occurred: 7:21:27 (1 occurrences) 
Last logged: 7:21:27

043 RP --- 13:045348 01:000730 --:------ 0008 002 0000 < Inconsistent state: 13:045348 (BDR) has changed controller: 01:210309 to 01:000730 (try restarting the client library)
1107

TL;DR: it is simply not possible to see the value of the controller’s temperature sensor

Or maybe you started with the wrong premise:

  • “the value of the zone temperature is useful” (yes, or course it is), versus
  • “so the value of the controller’s temperature sensor is useful” (N/A)

I am sorry, I have failed to explain this before…

The zone temperatures are all easily determined via discovery: evohome_rf just has to ask the temperature control system (TCS) for them.

In addition, many evohome devices have a temperature sensor - evohome_rf will pick these up by eavesdropping the announcements sent between those devices and the TCS (most of these devices are battery-powered and will not respond to any request for data)

There is one device which has a temperature sensor, but it does not make any such announcement - the controller (which is why you cannot get this value - there is nothing to eavesdrop).

Oh, and the TCS is also the controller.

This is why the temperature Sensor entities have names like

  • 34:123456 (temperature) instead of Kitchen (temperature)

BTW, there are other devices that have temperature sensors that have nothing to do with zones, such as the DHW sensor.

1108

Battery state is generally broadcast once every 24h - this is why the restore state feature is so useful.

1109

Yes - it is a corrupt packet, it looks like this:

043 RP --- 13:045348 01:000730 --:------ 0008 002 0000

… but should be more like:

043 RP --- 13:045348 18:000730 --:------ 0008 002 0000

More correctly, the preceding RQ is corrupt, and should have been:

000 RQ --- 18:000730 13:045348 --:------ 0008 002 0000

So there never was a ‘rougue’ controller clled 01:000730!

Solution:

The only solution to this is a stricter allow_list. Currently, this is accepted:

043 RP --- 13:045348 01:000730 --:------ 0008 002 0000

… because 13:045348 in is your allow list, even though 01:000730 is not.

I am toying with the idea of making allow list strict, so that both addresses must be in your allow list.

1110

i have these errors sinds 0.8.0:

Logger: evohome_rf.transport
Source: /srv/homeassistant/lib/python3.8/site-packages/evohome_rf/transport.py:481
First occurred: 7:48:49 (13 occurrences)
Last logged: 8:48:49

PktProtocol.resume_writing()

Logger: evohome_rf.transport
Source: /srv/homeassistant/lib/python3.8/site-packages/evohome_rf/transport.py:474
First occurred: 7:48:44 (14 occurrences)
Last logged: 8:48:49

PktProtocol.pause_writing()

I rebooted ha 1 hour ago and now is already have 14 messages, before te reboot i had over 400.
climate entries are taking longer it look like.

1111

Ignore them - they are not errors from your point of view.

1112

oke, than i ignore them

are these discovery messages:

Logger: evohome_rf.transport
Source: /srv/homeassistant/lib/python3.8/site-packages/evohome_rf/transport.py:683
First occurred: 7:48:49 (13 occurrences)
Last logged: 9:03:06

PktProtocolQos.send_data(RQ|01:155341|000C|0208): boff=1, want=RQ|01:155341|000C|0208, tout=2021-04-07 07:48:54.940227: RE-SENT (1/2)
PktProtocolQos.send_data(RQ|01:155341|2349|01): boff=1, want=RQ|01:155341|2349|01, tout=2021-04-07 07:54:19.978609: RE-SENT (1/2)
PktProtocolQos.send_data(RQ|13:189740|0008|00): boff=1, want=RQ|13:189740|0008|00, tout=2021-04-07 08:03:06.261934: RE-SENT (1/1)
PktProtocolQos.send_data(RQ|13:189740|0008|00): boff=1, want=RQ|13:189740|0008|00, tout=2021-04-07 08:03:06.261934: EXPIRED
PktProtocolQos.send_data(RQ|13:189740|0008|00): boff=1, want=RQ|13:189740|0008|00, tout=2021-04-07 09:03:06.377811: RE-SENT (1/1)
1113

The warnings are from the QoS engine - saying that packets had to be re-transmitted for some reason (some are ‘expected’, others are ‘true’ transmission failures that needed re-transmission),

The packets themselves are discovery packets.