Such an original idea!
It should be very much possible to configure this with scheduler.
I would choose the following approach:
Each d1mini has its own schedule for turning on the corresponding switch
Each schedule is configured to execute daily at 08:00 AM (or whichever is preferred)
In the options tab, the schedules have a period assigned from 12/19 - 12/25 for the first, 12/20 - 12/25 for the second, etc.
In the options tab, you could choose to stop the schedule afterwards (it becomes disabled), or delete it.
By doing so, the schedules repeat themselves daily until Christmas, so you could turn them off at night (either within the schedule or differently). If they are kept on, the repetition would have no effect (you could also restrict the period to a single day).
I recommend to do a test run (but you have plenty of time for preparations…)
Thank you so much for the response.
This is pretty much what I thought I could do with it.
Though I do have a few questions.
Can a schedule be copied and only the entity name changed. This will save a lot setup time.
Is it possible to access a calendar in the setup to specify a date. If available I have never used the function on the two dozen schedules I have setup.
For duplicating a schedule there is a scheduler.copy service which you could use (based on its entity ID). Duplication is currently not possible via the card.
The card should show a date picker when clicking on the text fields for defining the date period.
Unbelievable, found all of it. Started with a small test and will see how it goes.
Thank you so much @neliss this card has saved me a lot so that I do not have to create sarcastically hundreds of automations.
@neliss thanks for a great component but I wonder if you could clarify how the re-evaluate conditions works please.
For instance if I have a time-slot with conditions then the conditions are evaluated at the start of the timeslot, if they pass then the timeslot is executed, if not then are the conditions continually re-evaluated whilst the timeslot is active and if they become true at any point then the timeslot is executed otherwise it doesn’t? I presume once the conditions are met then the checking stops?
Thanks again.
PS. The schedule card documentation doesn’t yet have any mention of re-evaluate option.
Conditions are not linked to timeslots, they apply to the schedule altogether.
With the re-evaluate conditions option disabled, the conditions are only checked in the transitions between timeslots (or when the schedule is enabled).
With the re-evaluate conditions option enabled, the conditions are checked continuously, in case the conditions are met, the action of the timeslot which is currently active is triggered. This can also occur multiple times.
Example use-case:
if you have a schedule for controlling the heat of the living room (using thermostat), you could add as condition that the living room window must be closed.
If the window is open at the time the heating must become active (so at the start of a timeslot with action ‘heat’), the action will not take place. If later the window is closed, the schedule automatically picks up and starts heating (if the option is selected).
Note that when opening the window while heating is active, the schedule will not stop the heating. This would require an additional automation (or a second schedule running in parallel with the condition that window must be open), which commands the thermostat to turn off.
In most cases you have the choice between using the re-evaluate conditions option, or using automations to trigger the enabling/disabling of the switch entity corresponding to a schedule. The effect is quite similar (since enabling a schedule causes the conditions to be evaluated), but possible you can save some automation rules by using the option.
Many thanks for the explanation, I’ll use an alternative way of achieving my aims. As a suggestion being able to have different conditions for each timeslot would make it much more flexible even if the default was for the same conditions for the whole schedule. I have a couple of scenarios.
90% of the time a fixed schedule works fine for our heating and hotwater. However, 10% of the time people are out when they are normally home or vice versa. In this case I was hoping to prevent the transition to the next time timeslot temperature if people were still home but make the transition if they left.
We have solar energy so the hotwater schedule is mostly fixed but if it’s a very sunny day then we have surplus energy at midday, so I normally overheat the tank as the energy is free. So I was hoping to have a fixed time slot for 2 hours at midday that would only transition to a higher temperature if the solar was greater than a threshold.
I can achieve this with automations but I was hoping to be able to encapsulate it all within the schedule rather than add yet more automations to the balloning list which cannot be grouped or structured together, but that’s a problem for another day.
Thanks for the great work with the timer, If I may put forward another use case for better gui integration of automations, I am currently setting up a schedule to turn a light on and off via mqtt between certain times, and while timer is on the light switches on for 10 min of every hour. The best thing about using your timer is the redundancy if a message isn’t received immediately so I would like to keep the re-evaluation. Bonus points if we could adjust timer start, stop and interval via input text or timedate.
Currently I am using 2 schedules, one controlling automation and the other confirming the off period. Pretty easy really. Any idea how to set both timers using input text or datetime? Would be great to be able to set from dashboard, maybe even have calendar events update the input text and timer schedule
Can anybody here help to make this repo build on github?
I’ve added a build action to my fork, but I’m unable to make it build. I’ve spent the whole day eliminating errors, but without success.
This is my first attempt to build any node / js stuff, but it seems to be a nightmare. After resolving package dependency errors, lint errors I was unable to resolve errors with rollup like semantic error TS2305: Module '"../node_modules/custom-card-helpers/dist"' has no exported member 'FrontendTranslationData'..
I’m sure I’m on a wrong track, so I’ve hard reset my fork to the beginning.
I have some MQTT button entities with entity id “button.XXXX”.
But I cannot find any button entity when adding entities to the include list.
Did I miss any steps?
Button component is relatively new. I didn’t add it to the card yet.
You could add it yourself if you want, using the customize configuration (YAML-only feature).
I hope you could help me with this. I have a heat pump that I control with automation with an external temperature sensor as a trigger. Can I somehow have the scheduler card control the heat pump by looking at the external temperature senor readings (not the one build-in into the pump).
@neliss Hi, suddenly the component doesn’t work with my installation. It worked this morning (my alarm scene fired off at 08.00) but after around 1-2 hours I noticed it said the card couldn’t connect to the Scheduler component. I then updated HA from 2022.5.2 to 2022.5.3 hoping it would solve it. Sadly it didn’t, also re-installing from HACS didn’t help. After restarting HA I noticed it came back very shortly and then was gone again. Log mentions this:
2022-05-11 11:18:40 INFO (MainThread) [homeassistant.components.switch] Setting up switch.scheduler
2022-05-11 11:18:40 WARNING (MainThread) [custom_components.scheduler.timer] failed to calculate next timeslot for schedule 4a413b
2022-05-11 11:18:40 WARNING (MainThread) [custom_components.scheduler.timer] failed to calculate next timeslot for schedule 4a413b
But nothing else mentions this component. In the past I noticed this issue very rarely, but refreshing the dashboard fixed it. Sou it was a front-end bug. But but it seems it’s a backend issue, since the log mentions it can’t calculate the next timeslot. The service calls of the component do work however. Using scheduler.run_action works.
Any idea what could be the issue and how to fix this / troubleshoot?
Could it be a schedule with an end date in the past?
If so, this bug may be related.
I actually made a fix for it this morning, but it’s not released yet.
This was indeed the issue. I read the ticket before but didn’t see the connection with my setup. After your feedback I realized I have created a schedule that’s only active this week and stops on this day (first time using this). So I deleted that schedule using the service call and indeed everything worked again.
I’ll update to the latest release when it becomes available and for now I will remove the date expiration of others. Thanks!
