Whaw!
I’m going to test all these new features quickly !
I spent some time searching but I don’t see anything as conditions of exclusion…
A condition is mostly an entity state ATM:
OK
But input_boolean is not ok…
groups:
- name: Conditions
icon: mdi:tooltip-account
include:
- person
- input_boolean
- alarm_control_panel
I’m going out of my mind. Even with the latest update I cannot get the scheduler component succesfully installed.
No service running and no entries in logs indicating a crash.
If we add entities so that they are used in the conditions they appear not only in the conditions but in the possibilities of the card, which creates confusion…
It should be a group_condition or an include_condition, or something like that…
Can you uninstall it from command line, remove from HACS, restart, install it again, clear cache, refresh, add it from integrations UI, and see if it works?
Is uninstalling from command line just deleting the directories for the integration? I can try that but what I previously did was remove it using HACS UI, then verified via command line the directories were all removed (they were)
That should be enough.
I tried it bu deleting the folder first via command line, then removed via HACS UI to ensure it was consistent.
Restarted HA.
Reinstalled.
Restarted HA.
No luck still.
So it doesn’t show up in the list of integrations in UI?
Correct, it doesn’t show up in Configuration > Integrations even though it’s installed via HACS, confirmed to have the directory there in command line, and no errors in logs.
Thank you so much for this. Coffee on the way.
1 Like
If you set logs to info, and do a search for scheduler, does anything show up (like “setting up scheduler”)?
Trank you very much for your work!
I would love to use it for my climate automations. Therefore any option for repetitive condition checking would be great! For example:
From 10-12pm set the temperature to 20 degree Celsius. If the window sensor is “on”, then don’t change the temperature. If the the scheduler detects, that the windows is “off” again, then apply the temperature 20 degree Celsius again.
In the current version it only checks the condition at the specific start time of a scheme, right?
Hi,
Yes.
This:
Is out of scope for scheduler. It is triggered on closing the window, not on time.
My intention is not to make scheduler an allround replacement for HA automations.
Thanks for your answer!
I totally agree with you. Right now I am comparing this to the appdaemon application “schedy”.
On one hand there could be a (from scheduler completely separated) automation that turns down the temperature if the windows is open.
On the other hand there could be your scheduler that checks if in the time scheme the condition (windows = “off”) is matched and then applies if true. A ‘force’ action mode or something like that.
But this could easily become really complicated 
The funny thing is that this intelligence is already more-or-less in place.
In case an entity, which is used in a condition, has state unavailable when the schedule enters a timeslot, the component cannot evaluate this condition.
So in fact, the scheduler will keep watching (up to the entire duration of the timeslot) for the entity to change its state (to anything except unavailable), and if so, re-evaluate the condition, and possibly execute the scheduled action.
Your use-case would be similar, except that you would like the ‘window open’ state to be interpreted kind of the same as unavailable.
The big question remains, what if the window opens a second and a third time within a timeslot?
The behaviour you are looking for is more like interlocking. Which makes sense, because heating up the planet will help no one 
Long story short: it would be very much doable. The big question is, how to integrate this in the card in a way that users will know what behaviour they will get.
And what would you expect to happen if your door is flapping open/closed repeatedly due to wind (theoretical scenario…)
This functionality could be added to the roadmap, but I want to avoid overcomplicating things right now…
If you keep adding features at the current rate it will end up as an alternative automation engine. 
I’m of the opinion that conditions are best suited to scripts and automations that can then be be scheduled with your application.
6 Likes
Ditto
Scheduler is… just a timetable, HA has automations and scripts with all the bells and whistles- conditions, repeat/run control etc.
IMHO keep scheduler as service/simple frontend for now.
Best, JR
4 Likes