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

Share your Projects!
871

That’s the problem I think. The eavesdropping doesn’t seem to work any more. My schema after days of running looks like this

Schema = {'controller': '01:020766', 'system': {'heating_relay': None
}, 'orphans': ['00:000392', '00:000474', '00:000494', '00:000498', '00:000548', '00:000551', '00:000554', '00:000558', '00:000567', '00:00
0595', '00:000599', '00:000606', '00:000795', '00:000806', '00:000951', '04:017575', '04:024117'], 'stored_hotwater': {}, 'underfloor_heat
ing': {}, 'zones': {'00': {'heating_type': None, 'sensor': None, 'devices': []}, '01': {'heating_type': None, 'sensor': None, 'devices': [
]}, '02': {'heating_type': None, 'sensor': None, 'devices': []}, '03': {'heating_type': None, 'sensor': None, 'devices': []}, '04': {'heat
ing_type': None, 'sensor': None, 'devices': []}, '05': {'heating_type': None, 'sensor': None, 'devices': []}, '06': {'heating_type': None,
 'sensor': None, 'devices': []}, '07': {'heating_type': None, 'sensor': None, 'devices': []}, '08': {'heating_type': None, 'sensor': None,
 'devices': []}, '09': {'heating_type': None, 'sensor': None, 'devices': []}, '0A': {'heating_type': None, 'sensor': None, 'devices': []},
 '0B': {'heating_type': None, 'sensor': None, 'devices': []}, '0C': {'heating_type': None, 'sensor': None, 'devices': []}, '0D': {'heating
_type': None, 'sensor': None, 'devices': []}, '0E': {'heating_type': None, 'sensor': None, 'devices': []}, '0F': {'heating_type': None, 's
ensor': None, 'devices': []}}}

I think previously it used to get updated from the messages that TRVs send out all the time since they include zone.

872

@skundrik Restart HA and send me the two logs & I will see what we can do.

873

@phdelodder Your issue is a bit similar to @skundrik - can you confirm things ar eOK after restarting HA?

874

Thank you for all the updates today. The latest version works flawlessly.

875

Sent you the logs with all TRVs as orphans.

You can also that zone name requests

RQ --- 18:138267 01:020766 --:------ 0004 002 0500
RQ --- 18:138267 01:020766 --:------ 0004 002 0600

seem to be missing. I have also seen in some previous logs that Controller would not respond to the RQ/0004 request immediately but would a little bit later. I wonder if the amount of RQ messages on start isn’t a bit too much. Unfortunately RQ/0004 don’t seem to be retried if for some reason they don’t get discovered on start so zone name may stay blank.

876

Thanks that’s really helpful. And is there a way to install on Hassio/HassOS at present?

877

I do not know.

878

Reasonable starting place :slight_smile:

879

It keeps updating, on my end it keeps updating. It’s at the start op HA it could be that is incomplete.

Could you also check https://github.com/zxdavb/evohome_cc/issues/15 ?

After checking all the orphans are gone on my end as well!

880

Has anyone on this forum managed to install this on Hassio?

881

Hi @zxdavb - are there plans for this to control the TRVs at all? So theoretically could you write your own algorithms to control the heating and/or more simply force a TRV to call for heat?

882

There are long-terms plans to completely replace the evohome controller… at least 2 winter’s away. though.

1 Like
883

Yes, I run it via HACS and works fine.
Except I can’t control the temperatures yet, but that’s not to do with the fact it’s running on HASSIO, read further up the topic for more on that (evofw and nanocul868).

884

Mine’s just been installed on the locked down Odroid based Blue and works, installed via HACS, although I have the TX issue on a evofw3 dongle. Worked fine on earlier firmware.

885

Someone asked me:

Can the attributes listed below be add to the actuator binary sensor?

And I thought I’d post the answer here:

This is not that easy, because of the way evohome devices are mapped to home assistant entities.

This device - an OTB - is actually two distinct ‘things’ - a OpenTherm bridge, and a heater relay - and so you would expect it to be implemented twice in HA (I’m ignoring OT presently, but it will happen - as a collection of distinct entities)…

In any case, its actually, it’s worse than that!

One issue is that a heater relay can be either a OpenTherm bridge (R8810), or a simple relay (a BDR91) - they have several attributes in common, and others not (after all, one modulates, the other uses TPI).

The other issue is that HA wants ‘physical’ devices split out into multiple HA entities - think about a single TRV, which is implemented as four such HA entities:

  • 2x binary_sensors: battery_low, window_open
  • 2x sensors: heat_demand, temperature

Now (as an example), a TRV also has an attribute, setpoint - this can reasonably be a state_attribute of the TRV, but of which of the TRV’s HA entities should be be a property of - all four? This leads to repetition and is somewhat unsatisfactory & I wont countenance it…

In this specific case, I have attached it to the temperature entity, but you could reasonably argue it should with be heat_demand.

Another complication is that there are 6 distinct roles that a BDR91 can have - not all roles support all attributes (this is a moot point if you’ve a R8810, but it’s another example of what I’m dealing with).

I do not want to implement something, then have to undo it - so we move slowly on this.

886

Amazing thanks! Just got it installed myself - excited to test it out

887

So, just pushed version 0.5.26 - please test & feedback.

You may not notice much this release, but the next one will have some new stuff.

888

I just pushed a new version of evohome_cc, 0.6.0 which adds in all the native service calls for DHW:

reset_dhw_mode()
set_dhw_boost()
set_dhw_mode(mode, active, duration/until)
reset_dhw_params()
set_dhw_params(setpoint, overrun, differential)

So, for example:

service: evohome_cc.set_dhw_params
data: {"entity_id": "water_heater.stored_hw", "setpoint": 65}

… and:

service: evohome_cc.set_dhw_mode
data:
  entity_id: water_heater.stored_hw
  mode: permanent_override
  active: false

… and:

service: evohome_cc.set_dhw_mode
data:
  entity_id: water_heater.stored_hw
  active: true
  duration: {"minutes": 135}

Once this has been tested, and bugs resolved, I will add in the native services for a) the Controller, and; b) the Zones.

1 Like
889

There is a version mis-match, not a problem i assume?
“evohome_cc v0.6.0, using evohome_rf v0.5.26 - versions don’t match (this is bad)”

Installed and updated through HACS

890

evohome_cc v0.6.0, using evohome_rf v0.5.26 - versions don’t match (this is bad)

Today, this is not bad. :slight_smile: