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

[galaxy_explorer]

@zxdavb

… the fan mode is not yet exposed to the fan entity, but I will add it in due course.

That’s wonderful. Currently I need to remove the ceiling diffuser to view the tiny status LED to work out whether the heater mode is on, this would eliminate that. I do wonder whether it’s also possible to know when the heater element is actually on, I currently monitor the power consumption (wattage) and create a sensor template from that. i.e. high power consumption assumes the heater is on.

You may recall that I previously created a PIV enhancement wishlist here for further exploration. More than happy to test the updates as they come

[behold81]

Yeah I would like to fake a humidity sensor at some point. That way I can set it up to run boost if the room gets above a set point. I believe it will run longer than the 30 mins boost button.

Still not sure was wrong with the 10E0 not being accepted by the send command. Did you find an answer to that?

As to other functions from the nuaire.

I believe there are a few bits that would be useful. Not sure what is possible.

Current modes.
Fan Speeds
Purge or boost mode
Heater auto or off.

As mentioned if we can know when heating element is in to track that would be good.

I believe it can track filter replacement. Think it might be a timer. Not sure if it is it means it can be reset too.

There are 2 temp sensors in the unit i believe to control the heater element if the difference in temp is over x difference and to turn the unit off if the temp is over x.

Honestly. Just having the unit working via HA as it is now is massive. So thank you so much for that.

[behold81]

Oh an if you need any testing let me know. Happy to test and log for you.

[zxdavb (David Bonnes)]

@galaxy_explorer

That’s wonderful. Currently I need to remove the ceiling diffuser to view the tiny status LED to work out whether the heater mode is on

Why cant you use the sensors?

sensor.30_xxxxxx_fan_info

… and:

sensor.30_xxxxxx_post_heat

[behold81]

Both of those attributes on mine show no changing info. Always 0 or Auto.

[zxdavb (David Bonnes)]

Oh yes - mine is the exact same!

My PIV reports:

• auto for mode (always)
• the relative humidity that it gets from the sensor (this changes)
• 0% heating (I don’t know if it ever leaves 0 - the heater has never been on?)

I don’t think there will be a fix for that! The fan just isn’t reporting what is is doing!

[zxdavb (David Bonnes)]

Someone had the remote (Landlord) scanner for Nuaire PIVs (DRI-ECO-RM) - can they PM me pls.

[behold81]

I take it the relative humidity is not from your fan? But your RH controller?

I’m trying to build a remote for the 4 way in HA. Shame I can’t tell fan setting so it might change the switch to normal when it comes off boost.

Need to setup a timer for it for now. Also trying to make a picture card for the current status of the system.

[phdelodder (Philippe Delodder)]

Running 0.31.1 and noticed that the battery_low binary sensor has 2 attributes of battery_level, how can I select it using a template?

id: "04:231770"
battery_level:
  battery_low: false
  battery_level: 0.5
device_class: battery
friendly_name: 04:231770 Batterij

[Lloyd (Lloyd Adams)]

I’d use something of this form, where class is a nested attribute of schema

{{ state_attr(“climate.evohome_cc_01_185426_04”, “schema”)[“class”] }}

[galaxy_explorer]

Just a thought but have you tried reaching out to Nuaire directly to see whether they will share their protocol implementation? This would save having to reverse engineer it, perhaps I’m being too optimistic!

[ionutm80]

Hi guys, I desperately need your help and some guidance. I have an EvoHome system comprising 12 individual zones each one with its own DT92 thermostat. I have an HGI80 connected to Home Assistant and ramses_cc installed through HACS. It recognizes all my zones and temperatures readings are ok. I have also tried to make some automations that turn the heat off in case an window is open for a zone by using a community blueprint: Window open, climate off - Blueprints Exchange - Home Assistant Community (home-assistant.io), and some Aqara door and window sensors. However it seems that the ramses_cc integration is only exposing 2 modes: Auto and Heat and does not expose the Off mode. I have also installed the cloud integration for EvoHome and there I have the Off mode exposed and the automation based on the blueprint above is working, except that I do not want to rely on cloud and would prefer to have everything local. I will attach 2 print screen for the same thermostat, one coming from ramses_cc and the other one based on EvoHome cloud integration to see the exposed modes. What am I not getting right here and how can I make the ramses_cc exposed climate entities work with the automation above? Thanks a lot in advance!

[SmartLiving.Rocks (Amon Reich)]

@ionutm80

2 modes: Auto and Heat and does not expose the Off

Please check what hvac_modes: are supported under Developer Tools → States

[ionutm80]

Indeed it’s only auto and heat, what can I do?

[ionutm80]

And this is for the cloud integration with EvoHome:

[ionutm80]

I have posted the issue also on Github:

'Off' mode is not exposed for ramses_cc integration

[behold81]

I thought about that. I did ask them years ago how they connected and they did inform me it was RF but would not tell me much more. They might if you ask however. No harm in trying.

[zxdavb (David Bonnes)]

@galaxy_explorer

Just a thought but have you tried reaching out to Nuaire directly to see whether they will share their protocol implementation? This would save having to reverse engineer it, perhaps I’m being too optimistic!

Too optimistic.

When I first started, I had this device that would pop up - no idea what is was - eventually worked out it was my Nuaire PIV (think: ventilation unit, like Orcon/Itho).

It was totally unexpected to me that RAMSES_II would support anything other than CH/DHW!

Took a while to decode the frame fully - a very complex payload… Not helped by lack of documentation.

It was obvious then that Orcon/Itho had much more going on in their payloads than my Nuaire, and others helped me - now the 31DA / 31D9 are almost fully understood - remarkable, really.

In all that time, I never received ‘official’ documentation from a vendor - not even under an NDA.

My PIV got decommissioned years ago, but I kept it, and have just revived it in my test bed - I’ll see what I can will be gleaning from it with (say) an RQ|10D0, etc.

[zxdavb (David Bonnes)]

@ionutm80

However it seems that the ramses_cc integration is only exposing 2 modes: Auto and Heat and does not expose the Off mode. I have also installed the cloud integration for EvoHome and there I have the Off mode exposed and the automation based on the blueprint above is working, except that

The mapping between evohome modes and HA modes/pre-sets (and thus, HomeKit / Google / etc.) is not straight-forward.

For example: zones are never truly ‘off’. They only have three modes:

• FollowSchedule
• TemporaryOverride, and
• PermanentOverride

However, the TCS (the controller, i.e. a collection of zones +/- DHW) can be off:

• HeatingOff (the DHW remains on)

I think the obvious thing for a zone to be set ‘off’ is for it to be set to 5 'C indefintely (PermanentOverride) - but others may disagree.

And the difficulty is not so much turning a zone ‘off’, but working out when it is ‘off’…

You could easily say a zone is ‘off’ if it’s setpoint is 5 ‘C (and what is the relationship of that to the zones min_setpoint - I have never fully checked), but there are 4 reasons why a zone setpoint can be 5’ C:

• PermanentOverride - set to 5 indefinitely
• TemporaryOverride - set to 5 for a while
• FollowSchedule - set to 5 as per schedule
• OpenWindowMode - is any PO/TO/FS, but set to 5, regardless of setpoint, for a short while

[ There are other reasons why a zone’s TRV can be set to 5’ C! ]

Then, what part does the TCS mode play? What happens if the zone is FS, set to 5 'C, but the controller is (say):

• Auto
• Away
• HeatingOff

I am the ‘code owner’ of HA’s evohome integration, and I have long recognized that the mappings I made when first implementing that integration are not satisfactory.

They need correcting, so that integration with 3rd-party systems via HA work seamlessly… But these corrections will be breaking changes.

I have always had it on my to-do list to fully understand what changes are required & implement them - but I want to do it only the once - get it right first time.

TL;DR: I would then like this integration, ramses_rf, to be compliant with evohome, and for them both to be ‘right’, but doing so is a breaking change, and I haven’t got my head around it.

[freekeys]

Hello! Been a while since I’ve read up on this project. Has the possibility of faking TRVs been explored? I.e. replacing Honeywell TRVs with generic (eg Zigbee) TRVs and having them operate as if they were Evohome ones?