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

Cinamon · October 10, 2021, 8:37am

@zxdavb i think that a fan entity the right kind of entity is for an itho fan. What are the benefits of a climate entity? What do you need for kind of logging?

stevieb12345 · October 10, 2021, 9:43am

I’ve got a nuaire DRI-ECO-LINK-HC PIV with
DRI-ECO-2s switch
DRI-ECO-RH sensor
DRI-ECO-C02 sensor

Would like to be able to use the boost function through automation.

zxdavb · October 10, 2021, 11:35am

TBH, I think an Itho ventilation system is more Climate than Fan - have a look at these two links:

Would you expect it to be implemented as a Fan, or Climate entity, or both?

For example, Climate includes humidity, and temperature, whereas a Fan does not.

However, a Climate entity doesn’t really have fan speed like the Fan entity does.

For now, just a packet log where the Itho devices are not filtered out. It will help if you use the switch a few times.

@stevieb12345 See the above for you - the log you sent me has the PIV in it, but neither sensor, nor the switch.

Mahmoud-Eid · October 10, 2021, 12:34pm

greyed out

what am I missing
the controls get greyed out
this is the log message

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:306
First occurred: October 9, 2021, 10:55:49 PM (463 occurrences)
Last logged: 1:20:50 PM

I --- 01:062035 --:------ 01:062035 0009 003 FC00FF # has expired (187%)
I --- 04:024680 --:------ 01:062035 2309 003 000320 # has expired (127%)
I --- 04:258712 --:------ 01:062035 2309 003 057EFF # has expired (135%)
I --- 01:062035 --:------ 01:062035 0009 003 FC00FF # has expired (196%)
RP --- 10:032432 01:062035 --:------ 3220 005 0040130000 # has expired (167%)

I have PMed you the packet.log
It gets fixed with a restart but comes back again

Many Thanks

zxdavb · October 10, 2021, 3:23pm

Generally, you can ignore these expired messages. Do you have any other errors elsewhere?

zxdavb · October 10, 2021, 4:24pm

@Mahmoud-Eid Please use:

evohome_cc:
  enforce_known_list: true

I cannot recommend strongly enough for people to do this.

See: 4. Config (reliability) · zxdavb/evohome_cc Wiki (github.com)

Mahmoud-Eid · October 11, 2021, 8:51am

Thank you
I must have missed that
thank you again for such amazing work

stevieb12345 · October 11, 2021, 2:59pm

I now have a few extra entities.

DRI-ECO-LINK-HC PIV
30:079129 (boost_timer) Doesn’t work.
30:079129 (fan_rate) always unavailable
30:079129 (relative_humidity) readings coming through ok.

DRI-ECO-RH sensor
32:168240 (relative_humidity) sending readings to 30:079129 ok
32:168240 (temperature) works ok

DRI-ECO-2s switch?
32:166025 (relative_humidity) always unavailable
32:166025_temperature always unavailable

DRI-ECO-2s switch?
32:172522 (relative_humidity) always unavailable
32:172522 (temperature) always unavailable

zxdavb · October 11, 2021, 4:26pm

I’ll need to see a packet log to sort this out, I’m afraid (I think you’ve PM’d me one).

zxdavb · October 11, 2021, 7:38pm

So, here is the challenge for Itho & Nuaire HVAC systems…

With Honeywell central heating / hotwater (CH/DHW) systems, you can tell what type of device you’re dealing with by looking at teh first part of it’s name, for example:

13:123456 starts with 13, and so is a BDR91 (BDR91A or BDR91T)
10:123456 starts with 10, and so is a OTB (R8810, or R8820)

With the ventilation system, that does not appear to be the case - devices need to be fingerprinted by what they’re saying, rather than their device id.

This necessitates a change in the code that will be a bit of an architectural change…

Please bear with me.

zxdavb · October 11, 2021, 9:32pm

@stevieb12345 Please send another log, but where the switch has been used.

32:168240 humidity sensor
32:166025 CO2 sensor
32:172522 switch?

06:46:26.546 ||  32:166025 | NUL:------ |  I | device_info      |      || {'unknown_0': '0001C85701016CFFFF', 'date_2': '0000-00-00', 'date_1': '2016-06-17', 'description': 'VMS-23C33',    '_unknown_1': '00000000000000000000'}
14:20:44.479 ||  30:079129 | NUL:------ |  I | device_info      |      || {'unknown_0': '0001C90011006CFEFF', 'date_2': '0000-00-00', 'date_1': '2016-09-09', 'description': 'BRDG-02JAS01', '_unknown_1': '00000000000000'}
14:21:14.518 ||  32:168240 | NUL:------ |  I | device_info      |      || {'unknown_0': '0001C85803016CFFFF', 'date_2': '0000-00-00', 'date_1': '2016-09-12', 'description': 'VMS-23HB33',   '_unknown_1': '000000000000000000'}

llevering · October 13, 2021, 1:08pm

I would be curious what features people may be hoping for?

Please keep reporting bugs!

A little late, but as we became parents and the time for HA became a bit sparse.

I have no bugs to report everything is working very well. My OTB doesn’t seem to offer any more information then already implemented. The fake sensors work great and as it is working so well I found myself adding more zones (which is relatively easy with underfloor heating). My setup worked reasonably well, but adding zones cheap and easily makes for fine-grained control. Again thank you for all your efforts, it is really appreciated!

As for feature request I have quite some ideas and I don’t know what would be possible and what isn’t:

Fake BDR91 (using for example a Shelly 1 as a fake BDR-91, maybe possible to make any switch-domain device a possible ‘target’)
Group entities from the same Evohome device in a HA-device (so the temperature and the battery level of a thermostat would be grouped in one device)
More zone-info when combined with underfloor heating. Currently the climate-entities don’t show heat_demand for zones heated with under_floor heating (the attribute is always null).
A bit more of the above, but very likely protocol limited: make all underfloor heating zones status information available in HA. So I can see if the zone ‘open’ or ‘closed’ for all 5 or 8 (with the HCE80 extension). To take it even further: control the status of the relais (in our case it needlessly switches on/off as we have no separate water pump for the ufw.
End goal (but likely not possible) have the ability to completely fake a controller and make the Evohome unit obsolete (probably very few peoples cup of tea, but the Evohome controller has some quirks in my specific setup and I would love to get rid of them)

zxdavb · October 15, 2021, 8:27pm

This is doable - the bones are there - I just don’t know how much demand there would be. What does the teh Shelly-1 turn on/off?

There is this feature in HA - just needs to be implemented. I would be keen for someone to consider taking over some of the HA development… any takers?

This is doable - I just don’t have many people with UFH sending me packet logs, and none since before last Summer - that would be the first step.

This was the intention, but it is a long way away.

PAGR · October 16, 2021, 11:44am

Hi all,

Can evohome_cc be configured to “listen only” mode (like ramses_rf can do “listen” mode iso “monitor” mode), i.e. not periodically send requests to the controller?

I’m occasionally missing messages from some devices and I tracked some of them down to the time when evohome_cc is sending its burst of queries to the controller.

I have configured:

disable_discovery : true
enable_eavesdrop : true

Not sure what they are supposed to do, but they do not seem to prevent evohome_cc sending queries.

Paul

zxdavb · October 16, 2021, 1:43pm

Almost all of the ramses_rf params can be passed over from evohome_rf using the config: in configuration.yaml:

evohome_cc:
  config:
    # disable_discovery: true
    # enable_eavesdrop: true
    disable_sending: true

I have always meant to change config: to ramses_rf:, so I think I’ll make that breaking change in the next drop.

zxdavb · October 17, 2021, 10:37pm

So I have switched over from TPI (using a BDR91) to OpenTherm (OTB) - there seems to be a lot of bug (before, I was reliant upon people reporting them, now I can see them).

@stevieb12345 The above doesn’t apply to your situaton, I’m afraid.

We’re going to have to change the way state is restored too.

There will be some big changes coming.

xAPPO · October 18, 2021, 1:09am

David, I’m about to change to (dual) opentherm too so I’m glad you’re walking in front with the torch !

zxdavb · October 18, 2021, 11:51am

Is there anyone with UFH who can do the equivalent of this for me & return the result?:

python -O client.py -rr -ns monitor /dev/ttyUSB0 -x "RQ 01:123456 000C xx09" -o packet.log

… where:

01:123456 is your controller ID
xx is the zone_idx of an UFH zone

zxdavb · October 18, 2021, 6:12pm

Coming soon… heat_demand for UFH zones.

llevering · October 19, 2021, 5:44am

The Shelly 1 is a wifi relay, on the electrical side it is exactly a BDR91 with a dry-contact that can be switched. Maybe the way to implement something like this might be to send an event from the custom component. In that way a user can use the event to trigger an automation that toggles the state of the device (in my case a Shelly 1, but for others maybe a Zigbee based relay).