Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ionutm80 opened this issue Jan 7, 2024 · 1 comment
Open

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

ionutm80 opened this issue Jan 7, 2024 · 1 comment

Comments

@ionutm80
Copy link

ionutm80 commented Jan 7, 2024

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
Copy link
Owner

zxdavb commented Jan 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants