You’re welcome. Feel free to ask when you’re facing any issue.
Working now, thanks
A suggestion for improvement
The following 2 schedules don’t behave the same, whould be nice if we can used it like this.
schedule
#first rules dont work after midnight of the end date
#special days
- v: 72
start_date: { year: 2019, month: 6, day: 7 }
end_date: { year: 2019, month: 6, day: 10 }
rules:
- {v: "69", start: "23:30", end: "2:54"}
- { start: "16:00", end: "20:39"}
- {v: "71", start: "23:00", end: "23:39"}
- { v: "off"}
#end special days
second rule works wvwn after midnight of the end date:
special day in 1 line
- {v: “69”, start: “23:30”, end: “2:54”, start_date: { year: 2019, month: 6, day: 7 }, end_date: { year: 2019, month: 6, day: 10} }
Se the avove 2 examples, the first has defined the start date and end date in the outer node, on the night of the 11th (after the end date) the rule is no longer valid
In the second example, on the night of the 11th it is still valid, as the whole row is evaluated as the same time, i wonder what the correct way is.
@yabuts Hmm, the correct way here would be extending the validity period by shifting the end_date to 11th June. There’s no other way to do it, since the evaluator never reaches the inner rule on 11th June.
EDIT: It’ss all because of end_plus_days being set to 1 on the inner rules, which results in a larger time frame than that expressed by the outer rule… This would face the same issue:
- weekdays: "6-7"
rules:
- { v: 20, start: "22:00", end: "01:00" }
That one would run Saturday from 0:00 to 1:00 and Sunday from 22:00 to midnight.
I’ll think about a way to improve the situation, at least the behaviour has to be documented clearly. But maybe I’ll even change the constraint checks.
Yes, i thought thst the same will apply to weekdays,
So it only adds to the need to have a proper way of doing this, as its common to do sleep time heating/cooling for weekdays and weekends wich always spans over midnight, and extending the weekend schedule to Monday is not an option as it will olso kick in at Monday night till midnight.
For instance
- V: 72
Weekdays: 6-7,1
{start: “20:00”, end: 7:00}
Wi result in the schedule to run Monday night till midnight, wich is unwanted
The only way currently is
, doing it in a single line and repeating the weekdays
- V: 72
{start: “20:00”, end: 7:00,Weekdays: 6-7}
Perhaps you change is to evaluate any inneer subrule thatbwill result i a end_plus_days >0 even if the outer rule evaluates to false, but i an not sure its what logically
i have to deal with situations like this since the beginnig (its not just in schedy but in every type of automation.
what you actually do with:
V: 72
Weekdays: 6-7
{start: “20:00”, end: 7:00}
is say that it must happen when it is on the chosen days AND between the times
in my eyes there is only 1 real solution
V: 72
Weekdays: 6-7
{start: “20:00”, end: 7:00}
V: 73
Weekdays: 1
{start: “0:00”, end: 7:00}
V: 74
V: 72 or V: 73
if you start adding the night from 1 to de day from 7, you will end up with others gettin in trouble.
with 1 combined rule its possible, because you add the start time to the startdate amd the endtime to the enddate. so then there is no problem.
@ReneTode
You are correct, but i liked the beauty of schedy with the automatic end_plus_days,
So i used this in the past
rules:
{start: “20:00”, end: 7:00, weekdays: 6-7}
And it works , the only issue is , that it doesn’t work putting the weekdays in a separate line
I would need some help setting up my first schedule / config for my bedroom for testing. What I need:
- window/door sensor
- device tracking (if nobody is at home … then don’t heat)
- a switch (maybe input_boolean??) to turn off all or just one climate.xxxxxx and schedules (something like master switch for heaty)
I you could point me to the right direct in or someone else her … would be great. I am beginner and / noob 
@thundergreen I plan to write a tutorial, but that’s not going to happen soon.
Hence I suggest you simply make your way through the docs. Start from the beginning and carefully read the chapter about schedules, especially the contained examples.
You are correct, but i liked the beauty of schedy with the automatic end_plus_days,
Thanks 
Try again the current state in master branch. It should now behave like you expected. This one will be at 20 degrees till Monday 2.00 am.
schedule:
- weekdays: 5-7
rules:
- { v: 20, start: "18:00", end: "02:00" }
- v: "off"
And please give feedback, I substantially reimplemented the algorithm that decides which rules are active. I hope there are no side effects, but I already did some testing which was promising.
Will play around tonight, and get back
Would be great but for the moment i have to get it running first… dunno why but it won’t start in my docker. i made the config.yaml file but it won’t start… let m investigate first … heaty works well for the moment
Is working a as expected, great job
Works really great, now i want to take it to next level:
My goel to have start_date end-date as a dynamic expression (and/or weekdays or any filter parameter), so i can have let say variable holiday days or vacations days from hass wil a set of sub rules in it.
@yabuts That won’t work and won’t be implemented either. You can simply access a template binary_sensor you defined in HA which is on when your ruleset should be active and off otherwise. Create a sub-schedule with a first rule like this: x: "Skip() if is_on(...) else Break()" and add your rules afterwards.
@yabuts The latest version in master also accepts negative end_plus_days values and hence allows creating rules that span backwards in time. This won’t be used widely, but it was a simple addition with some real use cases, if you’re interested in trying it out, here are the docs: https://hass-apps.readthedocs.io/en/latest/apps/schedy/schedules/basics.html#rules-spanning-multiple-days
In addition, many calculations performed during schedule evaluation are now cached to increase performance with very large and complex schedules that are re-evaluated regularly. This is again something probably nobody will ever notice directly, but it seems cleaner to do it to me.
Indeed this works very well and I use this for all my exceptions to the standard rules. One use-case I could initially not fulfill was turn on the heat for 2 or 3 hours with a manual trigger. I ended up with a script in HA with sets a Boolean to tell Schedy to switch on the heat and after a delay of x hours reset the Boolean. This way both start and end time are very dynamic. This works independent at which moment the manual trigger is given, so even with midnight in between.
@taste Exactly, that’s a nice separation of responsibilities. Let Schedy do the scheduling and HA automations do manual interventions.
EDIT: What you could have done as well is fire the schedy_set_value event with a dynamic rescheduling_delay to set a fixed value for some period of time.
@roschi thanks for this tip, did not know it is possible to modify the rescheduling delay dynamically. Will sure find a use if this somerime.