This was going through my mind this morning. Love to know how you have done it.
A ‘Holiday’ mode is a key task for today 
@taste, can you please explain how are you controlling the boiler switch with the statistics please? Also, I’m interested in learning cycle.
@roschi, please allow me to not agree on that. When I started reading scientific papers, the first thing that surprised me was the redundancy. Authors of such papers repeat several times things that have been said in order to make it easier for the reader to understand. Actually, when you write the doc, you know the context and forget that the reader may not be as confortable as you are. So you need, on regular basis, to remind him the context and explain things, even if that has already been said.
1 Like
@radar
Currently I pull the max value from the statistics which indicates the current maximum difference between the target and actual temperature of the rooms listed in the statistics section.
Next I have a standard automation which checks if this value is > 0.4 the boiler is switched on, when it drops < 0.4 it is switched off. The value of 0.4 is chosen to avoid an overshoot of the temperature. I am playing with the values.
This solution has a disadvantage in case for any reason you would miss the trigger to switch on/off. It will never trigger again. Therefore I will replace this with an automation that is triggered on each change of the max value and a condition to detect if the boiler needs to be on or off.Might be possible to do this directly with templating in the action. This is also a good preparation when I add an Opentherm gateway i.s.o. a on/off switch.
@radar there is value in redundancy, thats true.
but with a changing piece of code, redundancy make it hard to keep the docs correctly maintained.
so from the view of a developer you need to keep redundancy as low as possible untill the product is ready and then you can start adding extra things to the docs.
1 Like
You’re right with that.
@roschi, in the logs, what does rescheduling_time means when it is set to None? That no scheduling from Schedy will be done?
rescheduling_time set to none means the normal schedule is followed.
When it has a value there was a manual change, e.g the thermostat is manually increased. The defined rescheduling_delay for that room indicates how long it takes before the normal schedule is restarted.
This is useful to avoid a manual change stay’s there until the next scheduled action (which could be the next day)
I think I have misbehaved yesterday and I don’t know how I should have done.
I have a virtual switch named Schedy and this schedule_prepend rule
- x: Abort() if is_off("input_boolean.schedy") else Skip()
So yesterday, I was leaving the house for more than my longest rescheduling_delay. Thus, I manually changed my thermostats then switched off Schedy virtual switch. When coming back, I switched it back on and fired a schedy_reschedule, hoping that Schedy will set everything as needed. But all the rooms remained at the temperature I have set manually.
I tried rescheduling rooms individually with no success.
How should I have proceeded to stop Schedy then start it back?
Thanks.
Thank you for the clarification.
In my case, I have one virtual switch per room and the boiler turns on if one of these virtual switches is on. Each room has its own delta value to decide if its virtual switch should turn on or not.
@roschi, is it possible to add some information in the schedy room panel? It’d be interesting to have the time and value of next schedule. The only issue I see is that you cannot guarantee that the value is the same that will be at the time of schedule beginning. Maybe just the next scheduling time?
@taste Thanks for explaining the purpose of rescheduling_time so well. However, that’s an internal state attribute of Schedy and shouldn’t be manipulated manually.
@radar When you turned the switch back on, the scheduled value was probably the same as it was when you turned it off the day before, hence you need to re-schedule with mode: reset instead of just reevaluate (which is the default) to have the scheduled value applied forcefully. The meanings of the modes are described in the Events chapter of the docs.
I was not manipulating it, just trying to understand what’s happening in reading the logs.
I read that and tested it. But wanted to know what is the right procedure to do.
Thanks.
@ReneTode Yes, exactly, keeping the docs in sync with changing code is quite challenging and becomes more challenging when redundancy is added.
That’s not comparable with scientific papers that get written and published once, after which they aren’t touched anymore.
2 Likes
I completely agree with the last statement.
@radar Ok, just want to clarify that when such a schedule on/off switch is toggled, you should always re-schedule with mode: reset to get the intended behaviour.
Yes, I’ll add an automation. Thanks.
@taste and @radar What came to my mind regarding the boiler switch control and the related problems, why not just fire up a second instance of Schedy with the switch actor type (or maybe you have such one running already) and add a room for the boiler with just a single schedule rule:
- x: "'on' if float(state('schedy_stats.foo', attribute='max') or 0) > 0.4 else 'off'"In my case, I don’t need it since I have one generic_thermostat per room that triggers the boiler.