Hi @Krzysiek_Zet, if you want GUI just for updating the schedules you can take inspiration from my project: https://github.com/tristone-cz/hass
It is a bit outdated, still including Heaty, but for inpiration it is fine. I have newer configuration with Schedy in place, just not in GtiHub. If you need I can provide on demand.
Yeah , I get there are people that likes more vi than click, but I wont force my wife to learn this stuff 
I also get you may not want to develop UI but as I’m a progremmer I’m looking for possibilities to integrate Schedy with custom UI.
One would be by rest calls but I assume its not supported
Second, by editing the config file. Is this feasible option, I mean are changes in the config taken on every change ? Can we split config file that the rooms section is in another file ? This would be also interesting as we could have several schedulers (summer, winter) that can be changed by renaming files.
One would be by rest calls but I assume its not supported
Correct.
Second, by editing the config file. Is this feasible option, I mean are changes in the config taken on every change ?
Yes, changes to AppDaemon YAML app definitions take effect immediately.
Can we split config file that the rooms section is in another file ? This would be also interesting as we could have several schedulers (summer, winter) that can be changed by renaming files.
I think there are no YAML inclusion directives provided by AppDaemon. However, this is exactly the application for dynamic schedules. Instead of renaming files, you could make your season schedules depend on date constraints or simply on an input_select which you can then control via HA.
In general, the idea is to write your schedules in a way that makes them configurable via a domain-specific interface (which can consist of whatever HA entities you like), not to make the raw schedule reconfigurable at runtime, since even when your wife had the ability to do so, she would need to learn the semantics of Schedy. A custom interface tailored to match your exact usage scenario is far more ergonomic to use. Have a look at the tutorial and the various examples to get a sense of how it’s supposed to be done.
You are right. You can get same functionality by conditional schedules based on triggers / dates /temperatures. And this is much cleaner solution.
If I decide to create UI to enable remote editing config files i’ll let you know.
Cheers.
It seems my schedule isn’t quite working the way I want and doesn’t turn off when it should. Is anyone able to spot where I’ve gone wrong. The below is based on the tutorial but running a switch not a thermostat. Schedule has 4 states based on an input select to run my normal weekday schedule, at home schedule (wfh), totally off or constantly on, with the weekend schedule being the same for either the normal or wfh state.
`
schedy_coffee: # This is our app instance name.
module: hass_apps_loader
class: SchedyApp
actor_type: switch
expression_environment: |
def schedule_mode():
return state("input_select.schedule_mode")
watched_entities:
- input_select.schedule_mode
rooms:
kitchen:
actors:
switch.powerplug:
schedule:
- v: "on"
rules:
- x: "'on' if schedule_mode() == 'On (constant)' else Next()"
- x: "'off' if schedule_mode() == 'Off' else Next()"
- weekdays: 1-5 #Mon-Fri
rules:
- rules:
- x: "Next() if schedule_mode() == 'Normal' else Break()"
- { start: "06:00", end: "08:00" }
- rules:
- x: "Next() if schedule_mode() == 'WFH or on leave' else Break()"
- { start: "06:30", end: "15:00" }
- weekdays: 6-7 #Sat-Sun
rules:
- { start: "06:30", end: "10:00" }
- { start: "12:00", end: "15:00" }
It seems my schedule isn’t quite working the way I want and doesn’t turn off when it should. Is anyone able to spot where I’ve gone wrong.
Your schedule never evaluates to "off". As I already told you in the other thread, you need a fallback rule at the bottom that does catch when nothing before did. Additionally, the two rules for constant on and off don’t need to be in the sub schedule, they can reside at the top as well.
Ah, such things can be spotted nicely when you enable debug logging via debug: true and observe the schedule evaluation, which will show you exactly which rules were picked and to what results they evaluated.
Hi, I appreciate the help but this is really not familiar to me. I don’t know where this debug setting is made either. Not sure what you mean by “at the top”. The permanent on and off are the first rules in the list before the week day subrules. Also, if I place an off value at the end of the list, the schedules don’t even start. I don’t have a similar example to compare to otherwise I’d be able to see where I’m going wrong.
Edit: I think possibly the below is a fix but was through trial and error rather than the docs. More applied examples and templates with explanations of what is going on would help. I just wanted a simple schedule that worked not to become an expert in the syntax for the app.
schedy_coffee: # This is our app instance name.
module: hass_apps_loader
class: SchedyApp
actor_type: switch
expression_environment: |
def schedule_mode():
return state("input_select.schedule_mode")
watched_entities:
- input_select.schedule_mode
rooms:
kitchen:
actors:
switch.powerplug:
schedule:
- x: "'on' if schedule_mode() == 'On (constant)' else Next()"
- x: "'off' if schedule_mode() == 'Off' else Next()"
rules:
- weekdays: 1-5 #Mon-Fri
rules:
- rules:
- x: "Next() if schedule_mode() == 'Normal' else Break()"
- { v: "on", start: "06:00", end: "08:00" }
- rules:
- x: "Next() if schedule_mode() == 'WFH or on leave' else Break()"
- { v: "on", start: "06:30", end: "15:00" }
- weekdays: 6-7 #Sat-Sun
rules:
- { v: "on", start: "06:30", end: "10:00" }
- { v: "on", start: "12:00", end: "15:00" }
- v: "off"
I don’t know where this debug setting is made either.
Well, in your Schedy config at the top level. Docs tell you where.
Not sure what you mean by “at the top”.
Before any other rule.
The permanent on and off are the first rules in the list before the week day subrules.
No, they aren’t. They are the first two rules in your all-encompassing sub-schedule, and as the purpose of sub-schedules is to declare common attributes (v: "on" in your case) once for all children and your constant on/off rules do return a value ("on" or "off") themselves, they don’t need to be part of that giant sub-schedule.
Edit: I think possibly the below is a fix but was through trial and error rather than the docs.
Now you attached the sub-schedule to the constant off rule… which makes all child rules inherit the expression that checks for constant off mode. This is certainly not what you wanted. You want the constant on/off rules to stand for themselves, followed by a sub-schedule rule that sets v: "on" for all it’s children. And please rethink the position at which you inserted the v: "off" rule, that should have a greater scope than just the weekend sub-schedule, otherwise it wouldn’t act as a fallback when nothing else cought.
More applied examples and templates with explanations of what is going on would help. I just wanted a simple schedule that worked not to become an expert in the syntax for the app.
The concept of sub-schedules is crucial for slightly more advanced scenarios (like yours with selectable operation modes) and you have to fully understand it’s syntax and semantics to do something meaningful. You’re not even using any “expert” features yet.
I put a lot of effort into the docs, especially into the chapter about scheduling basics, because that’s really the fundamental part you have to get right. But after all, Schedy is a one-man-show and there surely is room for improvement. I’m always trying to help people out with their schedules and concrete questions about semantics, but of course there is the chance that Schedy simply doesn’t fulfill your expectations.
Thanks. Could you do me a huge favour and edit my updated config by way of explanation. I still don’t get it. I think it could be a matter of changing the indentations but would value your help. I know you are doing your best to school me on this, but a picture paints a thousand words.
The updated config is a bad starting point. Better take the previous version.
The point simply is that your schedule never evaluates to "off". Ask yourself what Schedy does when it evaluates the schedule and none of the rules applies. This happens every weekday when none of your "on" rules catches (= outside the timeframes). If you can’t imagine, enable debug logging and watch the output. It’ll find no value to send to your actor.
So what do you need? A simple rule that returns "off" as fallback, and since rules are evaluated from top to bottom (cp. docs), this should be the last rule in your schedule. It also shouldn’t depend on a particular weekday or anything, so it shouldn’t be part of a sub-schedule either and - yes - that means it must be indented exactly as deep as the first rule in your schedule.
I really can’t explain it any different. Hope that helps.
That’s what I thought I had done in my last update. I have an off rule at the end that is at the same level hierarchy as each sub rule (so not associated with just the weekend rule) and the on and off rules are now the first rules. If it’s immediately obvious to you where my code needs a minor edit, the three pages of explanation you have written could have been avoided by just showing me the code!
One more try…
## This goes in schedy_coffee.yaml in AppDaemon’s apps directory:
schedy_coffee: # This is our app instance name.
module: hass_apps_loader
class: SchedyApp
actor_type: switch
expression_environment: |
def schedule_mode():
return state("input_select.schedule_mode")
watched_entities:
- input_select.schedule_mode
rooms:
kitchen:
actors:
switch.powerplug:
schedule:
- v: "on"
rules:
- x: "'on' if schedule_mode() == 'On (constant)' else Next()"
- x: "'off' if schedule_mode() == 'Off' else Next()"
rules:
- weekdays: 1-5 #Mon-Fri
rules:
- rules:
- x: "Next() if schedule_mode() == 'Normal' else Break()"
- { start: "06:00", end: "08:00" }
- rules:
- x: "Next() if schedule_mode() == 'WFH or on leave' else Break()"
- { start: "06:30", end: "15:00" }
- weekdays: 6-7 #Sat-Sun
rules:
- { start: "06:30", end: "10:00" }
- { start: "12:00", end: "15:00" }
- v: "off"
That’s what I thought I had done in my last update. I have an off rule at the end that is at the same level hierarchy as each sub rule (so not associated with just the weekend rule) and the on and off rules are now the first rules.
Not quite. You had removed the v: "on" and instead attached everything as a sub-schedule to the constant on rule, making all child rules effectively inherit the expression that checks if mode is set to constant on, instead of a plain v: "on".
Additionally, you had indented the v: "off" one level to much, which would in your case not change the behavior but looks a bit confusing.
One more try…
Looks good so far, however you still could pull the constant on/off rules out of the sub-schedule:
schedule:
- x: "'on' if schedule_mode() == 'On (constant)' else Next()"
- x: "'off' if schedule_mode() == 'Off' else Next()"
- v: "on"
rules:
- weekdays: 1-5 #Mon-Fri
...
- v: "off"
Apart from that, well done!
Thanks. Do you mean push those two lines above the schedule: line? What would that achieve? I think your use of the term sub-schedule is what has confused me from the start. To my mind the subschedule is where the weekdays split out, unless you counting each room schedule as a subschedule. Anyway, thanks very much for your help and providing this great app, and apologies if I came across a bit chippy - just a bit frustrated as I have messed with this for hours.
Below is the result. I can switch between different schedules, lights tell me when the coffee machine is actually powered on (either when constant or during the on periods in the schedules). it also senses a power usage threshold to give a light indicator for the heating element as a visual indicator that the boiler is heating up from cold or cycling to keep it to temperature (mimicking the lights on the actual machine). Finally, Alexa gives voice announcements whenever one of the schedule settings is selected.
Thanks. Do you mean push those two lines above the schedule: line? What would that achieve?
No, I just pulled them out of the v: "on" sub-schedule, not out of the schedule: section.
I think your use of the term sub-schedule is what has confused me from the start. To my mind the subschedule is where the weekdays split out, unless you counting each room schedule as a subschedule.
A sub-schedule is the ruleset defined under the rules: parameter of a schedule rule and whose rules thus inherit their properties from the parent rule. And since the constant on, constant off and the fallback v: "off" rules don’t need to inherit anything, I pulled them all out as demonstrated in the sample in my previous post.
Nice that it’s all working for you now.
Hi Robert,
I am still experiencing the problem described earlier in #830. I have checked with the people over at dresden-elektronic and the problem seems to be that the zigbee hub reports that the state has changed although the change might have not yet been promoted to the thermostat. It happens that the thermostat does not react immediately and the change is scheduled for the next time the thermostat reports back to the hub. But then it reports also its old temperature setpoint value. Thus leading to the confusion.
Although I am hopeful for a solution from the deCONZ side, I wanted to ask if you see a way to work around this issue with schedy. Could it be possible, for example, to block manual changes for a certain amount of time after a scheduled event has occurred?
And how is schedy working internally? I guess that a new value is set by firing an event inside HA? Is there a difference how a new temperature setpoint and setting the thermostat to “OFF” are handled? I am asking because I never had the mentioned issues when using “OFF” inside a schedule or for the window-open overlays.
Thanks again and best regards!
Hi @Sk4zz
I am still experiencing the problem described earlier in #830. I have checked with the people over at dresden-elektronic and the problem seems to be that the zigbee hub reports that the state has changed although the change might have not yet been promoted to the thermostat. It happens that the thermostat does not react immediately and the change is scheduled for the next time the thermostat reports back to the hub. But then it reports also its old temperature setpoint value. Thus leading to the confusion.
That sounds reasonable, and - though without knowing much about the ZigBee internals - I guess the proper way of handling this would be to not report the changed state back until it really was transmitted and confirmed by the ZigBee component, possibly leading to a longer time to confirmation of course, but at least not lying about the real state. This would then cause Schedy’s re-sending logic to kick in and work as normal.
Although I am hopeful for a solution from the deCONZ side, I wanted to ask if you see a way to work around this issue with schedy. Could it be possible, for example, to block manual changes for a certain amount of time after a scheduled event has occurred?
No, this is not something Schedy supports.
And how is schedy working internally? I guess that a new value is set by firing an event inside HA? Is there a difference how a new temperature setpoint and setting the thermostat to “OFF” are handled? I am asking because I never had the mentioned issues when using “OFF” inside a schedule or for the window-open overlays.
Schedy just calls the normal climate.set_hvac_mode and climate.set_temperature Home Assistant services. There is no difference to what happens when you change HVAC mode or temperature via web UI. If there’s a difference between setting the HVAC mode to off and changing the temperature while in heat HVAC mode, maybe the deconz component is handling these calls differently.
Another possibility is that only the first of two subsequent calls is transmitted immediately while a second one fired directly afterwards stays in the pipeline for a while (maybe due to duty cycle restrictions in ZigBee, I don’t know). Turning the thermostat to off mode via Schedy involves only one call, while setting a temperature is two calls (set mode to heat + set the desired temperature value). This would also explain the difference.
Either way, there is nothing Schedy can do at the moment to reliably resolve the issue. The deconz side should fix it to only reflect the new state after it has been transmitted and confirmed to have a logically correct order of events.
Best regards
Robert
I wanted to turn down the termostats if i am on vacation, but didn’t quite understand the docs. See the example beneath, is this the right way to do it? If the input select vacation is on, i want the temp to be set to 15 degrees, no matter time or day, but i am unsure if the “x:-command” overrides all 3 “v:-commands” or just the first?
kjellerbad:
rescheduling_delay: 240
actors:
climate.kjellerbad_gulv:
off_temp: "OFF"
schedule:
- x: "15 if is_on('input_boolean.vacation') else Next()"
- v: 21
weekdays: 1-5
rules:
- { start: "07:00", end: "09:00" }
- { start: "20:00", end: "00:00" }
- v: 21
weekdays: 6,7
rules:
- { start: "08:15", end: "12:00" }
- { start: "20:00", end: "00:00" }
- v: 17
Hi @ATWindsor
Let me quote the docs:
This is how schedules work. The first matching rule wins and determines the value to set. Consequently, you should design your schedules with the most specific rules at the top and gradually generalize to wider time frames towards the bottom. Finally, there should be a fallback rule without time restrictions at all to ensure you have no time slot left without a value defined for.
Doesn’t this answer your question?