Do not re-trigger schedules when HA restarts

[nielsfaber]

Checklist

• [x] I checked for similar existing requests (both open and closed) before posting.
• [x] My request is generic, other users may benefit from it too.

Proposal

Currently, when HA restarts, any schedules with timeslots currently active will be re-triggered. This can have undesirable effects (e.g. a thermostat could be set to heating while it was manually turned off before). The proposal is to change this, do not re-trigger schedules upon HA restarting.

Additional info

The case of a scheduled event being missed due to HA restarting exactly in the minute it was supposed to trigger should be detected. Possibly with some grace time (e.g. 5 minutes), such that all schedules which were due in that timeframe, are still triggered.

[sddgit]

I disagree with this becoming a blanket change. The way I look at it, if you have scheduled events controlling equipment, often carefully set up so that dependencies are taken care of (things like pool filters and sweeps), you want that equipment to always be in the state you have specified at that time of day. Currently, HA can be down for any length of time, even through perhaps a power cut, and when the system comes back up I can be certain the equipment is in the proper state.

I know it is always desirable to keep card complications to a minimum, but how about having an option in each schedule for whether this new behaviour takes effect, defaulting to the current behaviour so this is not a breaking change?

[macbih]

Thank you very much, Niels @nielsfaber, for addressing the issue!

Currently, when HA restarts, any schedules with timeslots currently active will be re-triggered. This can have undesirable effects (e.g. a thermostat could be set to heating while it was manually turned off before).

This is also my observation! In my case, heatings were supposed to heat but their thermostats were reset to night lowering of the heating upon HA starting. Especially in winter, that is not only undesirable but also annoying for family members who do not understand what has happened and what is it good for. In other words: They (including me) would like to trust what they have set on the heatings.

The proposal is to change this, do not re-trigger schedules upon HA restarting.

Every now and then there is a need for restarting HA. It would be an absolute relief to know that this would have no effect on manual settings until next switching point. So I absolutely second this change!

how about having an option in each schedule for whether this new behaviour takes effect, defaulting to the current behaviour so this is not a breaking change?

Maybe a global option for all schedules could do it either, whatever is easier to implement. Also with Re-trigger schedule upon HA starting = True as default so it won't break anything.

[moustic999]

I'm really annoyed too with this restart. At home I have everything KNX, and the idea they propose is done via an option in the config. it is possible to choose what to do after power loss and after a restart. I'm not sure in HA if we have the diff between a restart and a power-loss ( maybe an event is sent before a restart) We could imagine a new option for schedule with such choices:

Behavior after a restart : do nothing, apply current calendar value Behavior after a power recovery ( or fresh start ) : do nothing, apply current calendar value, apply a default value (to be defined)

[nielsfaber]

@moustic999

I'm really annoyed too with this restart.

What do you mean? The restart itself? The fact that schedules are re-triggered? The suggested change that schedules will no longer be re-triggered?

I'm not sure in HA if we have the diff between a restart and a power-loss ( maybe an event is sent before a restart)

Scheduler cannot distinguish.

I am currently thinking of offering a global option to allow the user to choose whether schedules will be re-triggered on startup or not*. This will not be per schedule.

* There might be an exception for schedules which were likely missed during the restart (i.e. they were due <5 mins ago). These should be triggered still.

[moustic999]

What do you mean? The restart itself? The fact that schedules are re-triggered? The suggested change that schedules will no longer be re-triggered? Sorry, for confuision, I'm annoyed by this re-trigger of schedules.

I am currently thinking of offering a global option to allow the user to choose whether schedules will be re-triggered on startup or not*. This will not be per schedule.

That would be perfect in my case.

• There might be an exception for schedules which were likely missed during the restart (i.e. they were due <5 mins ago). These should be triggered still.

Before Home-assistant restarts, an event "shutdown" is sent, maybe scheduler could use this event to decide whether or not to reapply the schedule ? if shutdown event, keep trace that is will be a restart, then after initialization, don't reapply schedule. If power loss, as there is no info about restart, schedule will be reapplied.

[nielsfaber]

@moustic999 I just made a quick test, I saw that I can indeed have scheduler store the moment (in time) when HA was stopped by using the shutdown event. After restarting, scheduler can determine which schedules were missed from that moment (so the once that triggered in the meantime), and execute those. I suppose this is a quite elegant solution which wouldn't have bad consequences for anyone, so I would say this approach eliminates the need for a setting altogether.

[moustic999]

@nielsfaber It look a nice idea. but what will happen in case of power loss ? at such case, you don't have the shutdown event, what would happen ?

[nielsfaber]

@moustic999 In case of power loss HA is not 'gracefully' shutdown, and indeed no event is triggered. This also implies that this mechanism will not be able to detect which schedules are missed in the meantime. Those would not be re-triggered once HA is restarted.

edit: Actually the solution I mentioned in https://github.com/nielsfaber/scheduler-component/issues/234#issuecomment-1346419985 can be extended to cover this scenario: At startup, in case no time of stopping HA is stored, we assume there was a power interruption. In this case all schedules will be triggered (as is now the case). If there is a time stored, we use the stored time to determine which ones were missed in the meantime. The stored time can simply be erased from storage when startup is done.

[sddgit]

edit: Actually the solution I mentioned in #234 (comment) can be extended to cover this scenario: At startup, in case no time of stopping HA is stored, we assume there was a power interruption. In this case all schedules will be triggered (as is now the case). If there is a time stored, we use the stored time to determine which ones were missed in the meantime. The stored time can simply be erased from storage when startup is done.

I was going to suggest exactly that. I think that would be a terrific enhancement that should satisfy everyone!

[nielsfaber]

I implemented this as discussed, it works like a charm for me. For those who would like to test it, I included this in the new v3.2.13 release. I will keep this topic open for a while to allow further discussion about possible improvements..

[sddgit]

I’ve given this a go with the HA restart scenario. Works very nicely. I manually switched off a climate control and, on restart, it was still off.

I did have to change one parameter in my generic_thermostat configurations. I had a parameter initial_hvac_mode: "off" for some reason, but the climate entities used to always be put into the correct state by the scheduler once it kicked in. After this change, that didn't happen, so the climate entities were always off on restart. I removed the parameter and all is well. Not sure whether an initial mode is needed at all though. Can anyone enlighten me?

[SeByDocKy]

I have the same problem, after each restart, the last statement of the scheduller program is no more set to its value .... Annoying bug

[SeByDocKy]

Still not working with 3.2.14 :(

[bigbread59]

Is Re-trigger schedule upon HA starting working?

How to use it correctly?

[nielsfaber]

@SeByDocKy @bigbread59 A schedule is only triggered once, either upon entering a timeslot OR when starting HA OR when enabling/creating/modifying a schedule.

As mentioned in this issue, the new behaviour is to NOT re-trigger all schedules when HA restarts. Before the 3.2.14 release, schedules consisting of timeslots would always be triggered when restarting HA. Since the 3.2.14 release, schedules consisting of timeslots will only be triggered when restarting HA if the entering of the timeslot occured while HA was shutdown. The only exception to the above is an uncontrolled shutdown (i.e. power removed of the hardware which runs HA). In this case all schedules consisting of timeslots are triggered when restarting HA.

If you experience negative consequences of this change, please explain as I'm not aware of any downsides.

[bigbread59]

@nielsfaber A schedule is only triggered once, either upon entering a timeslot OR when starting HA OR when enabling/creating/modifying a schedule.

I have a simple "climate" schedule based on time slots. From 06am to 05pm 20°C. From 05pm to 06am 17°C. The "target_temp: 17°C".

If I restart HA (for whatever reason) at say 10am, the thermostat stays at 17°C until 06pm, which is not nice.

This for me is the inconvenience.

[SeByDocKy]

I am using also scheduler to drive a binary_sensor (linked with a ESPhome node). Here the scheduleur :

As you can see, the binary_sensor must be 1/on from 6am to 10.30pm. If I restart HA anytime inside this interval,, the binary_sensor turns to off/0. It's annoying. You should add an option to drive this behaviour.

[nielsfaber]

@bigbread59

I have a simple "climate" schedule based on time slots. From 06am to 05pm 20°C. From 05pm to 06am 17°C. The "target_temp: 17°C". If I restart HA (for whatever reason) at say 10am, the thermostat stays at 17°C until 06pm, which is not nice.

No, in this case the schedule would have been triggered at 06am, and set your thermostat to 20°C. If you restart HA, your climate device should restore to its previous setting, so 20°C (unless you manually updated it in the meantime).

@SeByDocKy

As you can see, the binary_sensor must be 1/on from 6am to 10.30pm. If I restart HA anytime inside this interval,, the binary_sensor turns to off/0. It's annoying. You should add an option to drive this behaviour.

I don't completely understand what you mean, since in HA you cannot write the state of a binary_sensor (they are read-only). It looks like you're setting an input_number entity instead. If you restart between 6am and 10.30pm, scheduler will do nothing, your input_number entity should keep the prior to the restarting, which is 1 (as set at 6am). Note that the input_number entity has an initial setting, which may cause the entity to start at 0 instead, depending on your configuration. I don't see this related to scheduler.

[SeByDocKy]

@bigbread59

I have a simple "climate" schedule based on time slots. From 06am to 05pm 20°C. From 05pm to 06am 17°C. The "target_temp: 17°C". If I restart HA (for whatever reason) at say 10am, the thermostat stays at 17°C until 06pm, which is not nice.

No, in this case the schedule would have been triggered at 06am, and set your thermostat to 20°C. If you restart HA, your climate device should restore to its previous setting, so 20°C (unless you manually updated it in the meantime).

@SeByDocKy

As you can see, the binary_sensor must be 1/on from 6am to 10.30pm. If I restart HA anytime inside this interval,, the binary_sensor turns to off/0. It's annoying. You should add an option to drive this behaviour.

I don't completely understand what you mean, since in HA you cannot write the state of a binary_sensor (they are read-only). It looks like you're setting an input_number entity instead. If you restart between 6am and 10.30pm, scheduler will do nothing, your input_number entity should keep the prior to the restarting, which is 1 (as set at 6am). Note that the input_number entity has an initial setting, which may cause the entity to start at 0 instead, depending on your configuration. I don't see this related to scheduler.

You are right, in practice for ESPhome it's an number object with min=0,max=1.(not a HA input_number)

[sddgit]

@nielsfaber A schedule is only triggered once, either upon entering a timeslot OR when starting HA OR when enabling/creating/modifying a schedule.

I have a simple "climate" schedule based on time slots. From 06am to 05pm 20°C. From 05pm to 06am 17°C. The "target_temp: 17°C".

If I restart HA (for whatever reason) at say 10am, the thermostat stays at 17°C until 06pm, which is not nice.

This for me is the inconvenience.

Check the configuration of your Climate entity in config.yaml. Do you have an initial state specified? If so, try removing it.

[bigbread59]

@sddgit , @nielsfaber

Thank you for your suggestion.

I use, with great satisfaction,

https://github.com/ScratMan/HASmartThermostat

I had set: target_temp (Optional)

I have now removed it and the scheduler is working fine.

Thanks again.

[galambert75]

@sddgit , @nielsfaber

Thank you for your suggestion.

I use, with great satisfaction,

https://github.com/ScratMan/HASmartThermostat

I had set: target_temp (Optional)

I have now removed it and the scheduler is working fine.

Thanks again.

Not convinced that removing the target_temp is a good workaround...

I have a similar problem with initial_hvac_mode: "off". When I do a graceful restart of HA (let's say after a version update), all my thermostats are switched off by this parameter in generic_thermostat. Before the v3.2.13 release, Scheduler took care of switching my thermostats on. Not anymore.

Removing the initial_hvac_mode: "off" feels like giving up a system safeguard (what state do I want if they system unexpectedly reboots?).

Personally, I'd like to have the option in scheduler to decide which of the two behaviors I want (pre or post v3.2.13).

[sddgit]

The theory is that you want things to be in the state you left them before the restart. I think the change accomplishes that, if you remove initial mode. The change was designed to address the situation where someone manually changed, say, a target temperature, and wanted that change to stay in effect over a restart. Can you think of a situation where this new behaviour isn’t desirable?

[galambert75]

Only what I mentioned before: having a failsafe way to ensure thermostats are always initialized to "off". Then, if my schedulers are on, they can change the state to whatever I have configured.

Can you think of a situation where this new behaviour isn’t desirable?

[nielsfaber]

@galambert75 I don't think its a good idea to consider scheduler as responsible to restore the state of your climate devices after restarting HA, this should be handled by the device itself. This is not really failsafe anyway, since you can manually turn off (or change the setpoint of) your thermostat during a timeslot, in which case scheduler would not restore the state correctly in case of a restart.

[catalinbordan]

Hi, I'm also looking for some ideas for my strange behavior of my schedulers setups in the last weeks... I found that my schedulers for heating, filters, fresheners sometimes works, sometimes do not.... Why? Did not find it... First I was thinking that HA updates breaks something (I was reading a little about how now the entities are updating the states in the comments releases) Coming here on github, I found that I had a bad version(outdated) for card. Reinstalled and happy that I solved the issue for that moment, but latter in a few days I found that I still have some situations where my scheduler did not trigger when my conditions changes. Turn off and on the switch of scheduler solve the issue... Now reading this page I may consider that I found the what it is the problem: the restart of HA, because I remember today when I was coming home the schedulers did not trigger the heating climates and today @work in the morning I have done an minor update of HA.

Could be that on restart of HA, the states of conditions are lost and scheduler do not know what to compare(old state versus new state on changes)? Here my case: for example 2 schedulers control the same climate heater: one for @home and one for away. I have a condition: I to be home or away and to revaluate once the state is changing.

Another issue I have, but I thinks it is off-topic I can not succeed to make a schedule with 2 conditions: a person@home AND sun below horizon with revaluate on change of state. Do not want to account the state of sun.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days