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

@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?

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.

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.

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

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

@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)

1 Like

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

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

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

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.

@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'}

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)

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.

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

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.

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.

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

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
1 Like

Coming soonā€¦ heat_demand for UFH zones.

1 Like

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).