Binding does not support temporary set point override based on schedule

[Nebula83]

Only permanent changes are supported. Binding needs to be aware of the schedule of the zone and use that info to create a temporary set point override with a maximum duration of 24 hours.

[VibroAxe]

Some thoughts on this to kick off discussion on how is it best to handle temporary set points,

3 options spring to mind

1) Apply setpoint until next schedule point (this is how the evohome_python rules perform) Definitely my personal preference as it's easiest for the end user and offers similar functionality to standard heating controllers / the evohome controller itself

2) Provide a config option as part of the thing to specify how long the override should be applied for Simple to implement, but not "easily" changable at runtime

3) Provide a channel option to specify how long the override should be applied for ie: Set channel overrideTime to 4 hours Change set point

[Nebula83]

1. Yes, this would be my proposal as well. Still allows for configuration, albeit via the evohome device itself
2. Not very practical I think as well
3. Crossed my mind as well. It isn't very OH-ish though; having a 2-stage rocket.

[smar000]

WRT 3, if this is an optional channel then would it be really against OH approach? For example, the default for this override duration channel could be 0. In this case, the binding simply carries out option 1, ie. any temporary change expires at the next schedule change. If the value in this channel is >0, then it is taken as the number of minutes for any overrides to that zone. I am using a similar approach at the moment via python scripts to achieve temporary set points.

[Nebula83]

Interesting approach, and I'm not saying I'm against it. But usually channels do not influence each other in my experience. The override time channel would do nothing but set some internal state instead of actually doing something on it's own. If you do know about an example in the existing binding then I'm eager to learn about it.

[smar000]

The override time channel would do nothing but set some internal state instead of actually doing something on it's own

Sorry, I don't think I explained clearly as I didn't mean that the override time channel should do anything by itself - it should work exactly as you state by setting an internal state. The temporary setpoint channel would then use this state only if it had been defined.

An example could be say the DMX binding (https://docs.openhab.org/addons/bindings/dmx/readme.html). I haven't used the binding myself but from reading the documentation, it looks as if the color channel sets the desired colour that the light will be set to once it is turned on. However, only the brightness channel can turn it on or off - i.e. the colorchannel itself will not turn the light on or off, but just holds an internal state.

[Rick-Jongbloed]

in the Evohome (Android) app we have a few defined statuses:

• Energy saving: ECO
• Away
• Day off
• Special day

If we could support these statuses it would be great (possibly in addition to a manual set).

For example, my schedule is set to use the heater from 18:00-22:00 every work-day and from 10:00-22:00 in the weekends. I would like to overrule this default setting based on presence information from Openhab. This way we can automatically set Away when there's no presence detected in the weekends, or set it to Day off when there's a presence through the week.

[Nebula83]

@ricadelic but this you can do already with the current binding. The system is available for reading and writing.

Topic of discussion is influencing a single zone in the system.

[Nebula83]

@all currently there is only one channel for setting the zones set point. I'd like to make a binding setting for the operation of that channel. Mode 1: permanent. Mode 2: override until next scheduling point. Any other variation you can then do with timers within openhab.

[VibroAxe]

Seems a sensible way to handle it

[CurtisFeatures]

Not sure if its possible, Think someone else already suggested this but it would be useful if you gave the end use the option of how long to set it for. Whether that me minutes or hours or both.

[Nebula83]

@curtisfeatures That could be a third option, indeed. If you could raise that as a separate issue?

[VibroAxe]

Having just had a poke at the latest version (which I believe doesn't do mode 2 yet) I would actually suggest that mode 2 should be the default, as this is the Evohome control display default action.

Also, if mode 1 sets a permanent override, how do you get it to return to schedule? (does setting the mode string reset this i'd assumed it was read only?)

[VibroAxe]

@Nebula83 Having finally got my home install up to date and running the latest version of the binding (fantastic work btw) I've run up a dev environment and started having a look at this over here: https://github.com/VibroAxe/openhab2-evohome/tree/setpoint-modes

[Nebula83]

@vibroaxe as a user you will be able to select the behavior. Personally I think permanent override suits openhab better. Ideally you'd set up your schedules in OH. The schedule bound overrides don't make much sense then.

Returning to schedule can be done by sending a zero to the O override channel, as per the docs. Give it a minute or two to snap back.

The mode is not read only, it allows you to set the actual mode as well. This was actually the reason for me to start the binding in the first place 😊

[VibroAxe]

@Nebula83 yeah I discovered the setting 0, didn't see that in the docs :S

The problem with evohome and openhab running the schedules is that if your net connection goes out / tcc is down (an unfortunately regular occurrence at the moment) then your entire heating stop running. Personally I'm a big fan of specifying the basic schedule into evohome (as I suspect most users with an evohome already have) and then being apply to apply overrides as appropriate.

This is also replicates the setpoint override from the TRVs and the TCS display/app itself.

I appear to have got slightly carried away in my initial investigations and came up with a PR which largely implements what we've been discussing here over the last year.

[Nebula83]

It's this bit: https://www.openhab.org/addons/bindings/evohome/

SetPoint Number Allows for viewing and permanently overriding the temperature set point of the zone. Sending 0 cancels any active set point overrides.

And yeah, what you discribe is how I would use it as well :-) Regardless, it's not necessarily the OH way of doing things. The main reason to not do permanent overrides really boils down to not trusting the communication channel. I think it be different if the controls where local like with a hgi80.

Anyway, thanks for the PR. I'll have a look and see if we can get it in!