Let’s say I have a number of time slot schedules controlling all my pool equipment - filter, sweep, heater, chlorinator etc. I shut down HA when all this equipment is, say, in an “off” time slot. It just so happens that when HA restarts, the time has moved on enough to be into one of more “on” time slots. The equipment won’t turn on if the schedules aren’t re-evaluated on restart. Or perhaps I purposely shut down HA for a longer period to do some network maintenance or something. Again, I’d like the time slots to be taken notice of on restart. This is one of the major things that attracted me to the card in the first place. Hope that’s clear. Or maybe I’m misunderstanding your intended change!
I was talking about the re-triggering of the current timeslot after restarting HA.
I understand that you don’t want to miss the first triggering of a schedule if it occurs in the minute that you’re restarting.
For me this is a different case. I don’t see this related to timeslots either, also schedules with a singular time shouldn’t be skipped due to a restart.
I believe there are already provisions in place for this, otherwise I will make sure to add them, e.g. by triggering (in this case, possibly re-triggering) all schedules which were due in the ~5 minutes prior to the restarting.
I think I’m with you. Now what if there’s a power cut for a couple of hours. When power is restored, would all the equipment be put into the state dictated by its time slot?
In case HA would be down when a schedule is supposed to trigger, it will only be (re)triggered upon startup in case the start of a timeslot is less than 5 minutes ago.
So in case of power outage for >5 minutes, schedules could be skipped.
I opened a feature request for this topic.
If you (or anyone else) want to discuss it further or have a good idea for an in-between solution please share.
certainly have no intents to introduce breaking changes, so if you have concerns I would like to hear them.
1 Like
Thank you for reply. I will try using a script as you suggested !
Hello Scheduler fans,
For a special case, I need to have 2 Scheduler on the same entity, each with a different schedule. Of course, only one should be running at a time (or conditions should be set so that only one is running at the same time).
It seems not possible. If I try to create another Scheduler card on the same entity, it get back the first one and don’t create a new one. Is there any solution on this ?
A little confused by wording of card.
As a reference today is Sunday December 11th.
I want to schedule a Hanukkah Candle to come on at 5 PM Sunday December 18 and every day at 5 pm until December 25th (8 Days). Then it will go off at 10 PM.
This is what I did.
I then chose options
And set the dates I wanted. I then saved it.
But this is what is displayed on the Schedule Card
What I am concerned about is that it says “Next Monday at 5:00 PM” Should it not say “Next Sunday at 5:00 PM”
Any help greatly appreciated.
I am more than a bit confused I must say.
Your expectations are correct, the card is supposed to indicate next Sunday.
I created the same schedule as you have it for testing, I can confirm the schedule will really trigger on Monday:
DEBUG (MainThread) [custom_components.scheduler.timer] Timer of 134641 set for 2022-12-19 17:00:00+01:00
There must be a bug somewhere in the code, causing the date to be 1 day off.
This only applies to start date, the end date is processed correctly.
I will investigate what causes this problem to happen, hope to be able to patch it soon.
In the mean time, you should rely on the text displayed in the card, by setting the start date at 12/17 it will actually trigger next Sunday.
I’m sorry for this inconvenience, thank you for reporting!
Thank you for looking into this.
99% of the time when things like this happens it is something in my coding or understanding of the “app” itself.
Glad I am not going crazy.
I love the card, have about a dozen devices using it.
A few minutes after my previous post of today, I updated HA to a new version 12.3
I went back to check things out and noticed that it now displayed the correct information.
I know it was not the version that made the change, but possibly a restart of HA.
Could this have solved the prooblem?
The problem seems to only occur in case the time at which the schedule is planned (i.e. when the schedule is created/edited or after a HA restart) is later than the planned time.
In other words: you probably encountered this bug when it was after 5:00 PM (or at least, this is when you saved it). And I’m guessing you updated HA somewhere in the morning. Does this sound right to you?
That is exactly what I did.
If you have multiple work day sensors how the system know which one to select?
My tuya thermostat doesn’t seem to accept the high low command which seems to be mandatory with the new version of Scheduler. In the old version I could simply use set temperatures and it worked perfectly. How can I fix? Thank you
Error executing service: <ServiceCall climate.set_temperature (c:01GM56H1PFRZW1TJQS2AJGS8Q0): hvac_mode=heat_cool, target_temp_low=24.5, target_temp_high=24.5, entity_id=['climate.cronotermostato']>
Error executing service: <ServiceCall climate.set_temperature (c:01GM56H6JVEEYFH1F515QNVQPG): target_temp_low=24.5, target_temp_high=24.5, entity_id=['climate.cronotermostato']>
Hi,
I don’t see any option in the service calls provided to allow to disable a scheduling.
I would like to turn off/on a couple of schedules through an automation or script, but i don’t see how.
In the documentation, it is mentioned:
Schedule will disable (turn off) itself after completion. It has to be re-enabled by the user or through automation in order to repeat.
Each schedule has a switch exposed, named after the name of the schedule. You can simply turn the switch off in an automation.
1 Like
I released a new version v3.2.13 of the scheduler custom-component, which contains a bugfix for this.
Thank you for reporting this issue.
Scheduler looks for binary_sensor.workday_sensor. Any other entity will not be seen nor used.
It seems that your entity advertises to support the heat_cool hvac mode. In this mode there are a lower and upper bounds for a setpoint range used. If your device needs a single setpoint, you can overwrite the built-in action with custom one, see here.
You can also create a bug report if you think the built-in support for your device should/could be improved.
2 Likes
I just wanted to say how brilliant this component and card is. Thank you for taking the time to not only build it, but keep engaged with the community and post updates and bug fixes. It’s really apprecaited
1 Like
works perfectly, thanks.