zxdavb / ramses_cc

HA integration for CH/DHW and HVAC systems that use the RAMSES II RF protocol
GNU General Public License v3.0
71 stars 16 forks source link

'Off' mode is not exposed for ramses_cc integration #129

Open ionutm80 opened 8 months ago

ionutm80 commented 8 months ago

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) 1, 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!

EvoHome cloud integration: IMG_4405 IMG_4407

Ramses_cc integration: IMG_4404 IMG_4406

zxdavb commented 8 months ago

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.