'Off' mode is not exposed for ramses_cc integration

[ionutm80]

'Off' mode is not exposed for ramses_cc integration

[zxdavb]

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.