Hi @Gromy,
Can you please explain:
I don’t get it
Sure, here is the story: imagine I have schedules so that temperature is set at 19° before going from work to home, let’s say at 18h00, then 17° at 23h00.
If I have some guest at home, or if Misses wants to override it and go into manual mode she will set the input select I made from auto
to manual
and this would trigger a script that will deactivate the schedules and let us set the temperature (from a conditionally displayed card ) to let’s say 20°. Then if at 22h00 we set it back to auto
this will just activate back the schedules but will not set the temperature back to 19°. At 23h00 it will work fine and trigger the action though.
It is nearly the same feature request than @LeadUr to trigger the actions at HA restart.
It’s an issue the author of heaty / schedy already noticed and solve with another conception. But I’m not ready to go one with that much installation complexity. A gold solution would be a UI/UX friendly solution like you made with this catch on schedule feature like he has.
Having the ability to activate a scheduler after a restart would be awesome.
There are some cases when you have power loos. If a scheduler should trigger when the system was off, then you lose an action. Imagine you want to start a water heater at 4 PM, but the system was off from 3:50 PM to 4:05 PM. You come back home, want to take a shower and the water is cold
This is just a simple example, but ideally, there should be an option to enable scheduler after system starts.
I think that the hard part is that you only store the start time and not the duration or the end time.
But maybe there is a way to overcome that limitation
@Gromy Ah i get it.
Well, this is something that i have to deal with in my own house as well
The request of @LeadUr to have the scheduler (re)trigger an action that has been ‘missed’, either due to HA downtime or downtime of the device, will be implemented.
The second part of the request, to have the scheduler ‘watching’ for changes to a device during a certain timeslot, and act on changes, is still open for discussion.
Ofcourse you want to be able to override a schedule and manually change a temperature setpoint. The question is, if at some point, the scheduler should take back control and revert to the scheduled setpoint.
Honestly, i’m not sure yet what is best here. Would like to look at the big players (Tado, Nest, etc.) see how they behave. Input is very welcome.
Hooray
By the way, now that we are discussing the topic of timeslots.
I made some progress with the new timeslot editor.
It works quite well already, i just need to add some finishing touches.
Here’s a preview:
The biggest open issue with it, is that while you are assigning actions to timeslots, in fact the actions are only executed on entering the timeslot. Hence the view is currently a bit misleading.
If a light is unavailable, can you make it do the right scheduled thing once it comes online too?
@KTibow I would say, only if you made a schedule for it with this new timeslot editor.
The way i see it, the timeslot editor and the (current) timepicker will both keep existing.
You create singular tasks with the timepicker, these will be of type ‘fire and forget’.
Defining timeslots will be more reliable, you can assume that the schedule will ensure the device will be in the state that you want it to be.
The big question is how to deal with the manual overrides. I’m thinking of some sort of extra checkbox for adding ‘grace’ where you want it.
Hello,
after the last update, temperature slider is missing for me too.
I’m using Chrome and i cleared my cache also.
No theme used.
You miss-understand me on this. The goal would not be to watch changes on a device, but applying the same logic we would think about for catching up schedules on HA boot also on schedules toggle back on.
The same way a schedule wouldnt be missed on HA downtime, a schedule could be cought up on schedule back on. I really think it is the same shared logic.
@Gromy turning on a disabled schedule, will cause it to re-evaluate in which timeslot it needs to start. The behaviour would be the same as due to HA restart.
In the same way, if you create or edit a schedule, as soon as it is saved, it may also trigger an action immediately.
I chose the schedules to be switch
entities exactly for the purpose of making them hackable for extra condition checks.
@Cadster @guims78 I just found out that the ‘disappearing slider issue’ is caused by updating to the latest version of HA (0.115.2 ‘birthday edition’).
I will work on a fix, I expect it is a simple thing.
I keep you posted!
Also - as others have already mentioned - take a look at Schedy. It is a very versatile scheduling tool, but without a GUI.
It is - for example - capable of resending commands if somehow the device did not receive it. (eg.: Z-Wave devices often do not receive packets, so when it sends a setpoint command it waits for HA to confirm and if it cannot confirm, resends the setpoing command again for a couple of times, waiting inbetween, before giving up)
Hello, i have another question about Group management.
I don’t understand how and where to define group in scheduler card.
I created some groups in a folder (as i managed to split my configuration.yaml) by creating 2 files, one for climate and one for light.
How can i tell scheduler card to take into account my groups file ?
A group within the card is not the same as a HA group integration.
By group is simply meant what categories show up when you create a new schedule:
The code needed for changing these, is explained here.
Hello,
i don’t know where to put the code.
i have this card :
with this code :
But the code doesn’t seems to match with the card.
The actions are only shown when you create a schedule, not in the overview.
Slider is back !!!
Very nice job.
Thanks