At the moment two scheduled are needed, one to turn it on at sunset and one to turn it off at sunrise. The scheme would replace both.
It doesn’t really matter if it’s one light or a group of a million lights.
There’s an added benefit that schemes have a certain amount of self healing. (Checking which state an entity should be in if for some reason a time was missed, an actioning that state.)
Thanks for the heads up I hadn’t really played with the scheme before, but it seems very powerful 
I just noticed that there are still issues with daylight savings times and updates, have you seen any progress on this?
Unfortunately I don’t know how to make scheduler aware of changes in daylight saving time.
As far as I know, HA does not offer any method for notifying a component that the internal time has changed, such that the timers can be recalculated.
The HA documentation on this is quite poor (non-existent) and I haven’t been able to find any code example that deals with this.
Easiest way for now is to just restart HA (or all schedules) when daylight saving time has changed.
1 Like
Hi all,
i have problem for scheduler a disarm of my alarm. this is the code of the card
views:
- title: Scheduler
path: scheduler
badges: []
cards:
- type: 'custom:scheduler-card'
include:
- alarm_control_panel
- binary_sensor
- climate
- cover
- light
- media_player
- vacuum
customize:
alarm_control_panel.alarm:
actions:
- service: alarm_disarm
service_data:
code: 1234
and this is the code of the alarm:
alarm_control_panel:
- platform: manual
name: Alarm
code: 1234
# Don't require the code to arm the alarm
code_arm_required: false
# Arm again after triggering
disarm_after_trigger: false
# Delay from arming and becoming armed, eg. to leave the house.
arming_time: 10
# Allow time to disarm the alarm before it triggers, eg. when arriving home
delay_time: 10
# Amount of time the alarm is triggered for
#trigger_time: 600
trigger_time: 10
i have enabled debug for schedule component and the debug show only:
2021-03-19 09:30:00 DEBUG (MainThread) [custom_components.scheduler.switch] start of executing actions for switch.schedule_cffea2
2021-03-19 09:30:00 DEBUG (MainThread) [custom_components.scheduler.switch] Executing action alarm_control_panel.alarm_disarm for entity alarm_control_panel.alarm.
the alarm is not deactivated after the execution
if i try with developer tool:
service: alarm_control_panel.alarm_disarm
data:
entity_id: alarm_control_panel.alarm
code: 1234
It’s works!
Hi,
I set up a schedule for my aircon. However it seems to fail to set it to COOL mode but instead will set to DRY, even though I selected COOL:
Does it matter whether the aircon was ON and set to another mode before? I don’t have any condition set in the scheduler.
I tried your action by copying your alarm and scheduler config.
For me it worked fine actually: alarm was in armed_home at 20:48 and was automatically disarmed at 20:50 by my schedule.
Maybe you selected the wrong action?
With your customisation there are two “disarm” actions, the one you configured doesn’t have a nice label and/or icon:
Could you try performing the same actions with Developer Tools → Services?
If the problem still persists it is related to your AC integration, not with scheduler.
I took a look at the scheduler code but couldn’t find anything regarding mix up between cool ↔ dry modes, so I’d say it should work fine.
Which service are you calling?
climate.turn_on? If so (and it replicates the behavior I see), I noticed that it won’t turn on AC in COOL mode but will turn it on in the mode it was last.
We probably need to set the hvac_mode on top of turning it on when selecting COOL.
Scheduler calls climate.set_hvac_mode.
You need to select this action:
climate.turn_on is not used by scheduler, usually an AC turns on automatically when you set the hvac_mode (in fact climate.turn_off sets the hvac_mode to OFF).
If your AC unit requires climate.turn_on together with setting the hvac_mode, you might need to create a script that runs this sequence of actions, and schedule this instead.
1 Like
I can’t select COOL while using the SET MODE option.
Only FAN, DRY, HEAT/COOL are available.
SO I guess I have to go through a script?
Setting “cool” requires a temperature setpoint (like heat).
So this action is available separately.
Yes that’s what I am using. But it won’t set the AC to COOL but to the latest mode it was on.
PS: I am using a Daikin unit that works well on the default card.
awesome! thanks for creating this!
Allows the misses to now easily do things, without having to ask me to code YAML automations
It would be great to have a notification if something happened, eg. when something is turened off, call the notify service to let you know, however reading other posts, i think thats no in the plan right?
usecase:
we have a backup “turn off” schedule for if we left things on at night (forgot to turn off before bed) - so in the old automation we would send a notification, to remind us that home assistant has turned it off and that we were idiots for leaving it on!
I tried to manually set hvac_mode: cool in the developer tools and it worked as expected.
What does the scheduler choose when I set a schedule with COOL and not SET MODE?
The COOL action in the scheduler sequentially calls:
climate.set_hvac_modewithhvac_mode=coolfollowed byclimate.set_temperaturewithtemperature=Xwhere X is the chosen setpoint.
Only calling the SET MODE is not practical, as you typically should tell the device to which temperature to cool to (otherwise it might use a previous setting, or it might not do anything, depending on your device).
Anyone know where the schedules get saved? I believe I deleted a schedule but it still keeps firing the event, want to make sure it got actually deleted.
really strange… when I trigger the service manually it works, but it doesn’t with the scheduler.
Some other user once reported that zigbee2mqtt has an issue that if you send multiple commands in a row without delay, some commands could be ignored.
Sounds like you have a similar issue.
You could test if this is the case by creating an automation that sends the same commands.
Unfortunately it would be a very device/integration specific problem, so I’m not sure scheduler should/could be changed to fix it.
Sure I can test that. How should I do?