Ensure scheduler state (eg. manual run with checking time and conditions)

[fpytloun]

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

If there's some issue with entities scheduler is calling, there is no simple way to find out or fix the state. Eg. if scheduler triggers a light off but it remains on for any reason. Possible solutions:

1. I would expect repeat_type to repeat actions, so basically retry, but it does not seem to happen or there's some longer period, not able to configure. UPDATE: based on this, repeat happens every 10 minutes https://github.com/nielsfaber/scheduler-component/blob/061d882f686083cedf1ea4a50333ca030f305840/custom_components/scheduler/switch.py#L181
2. Have automation with scheduler.run_action to re-try actions but it will skip time checks so it also does not solve the issue.

Ideal solution would be to have action eg. scheduler.ensure_state or it would probably be same as what would happen after scheduler.edit as I think scheduler fires if updated 🤔

Additional info

[some example of how the new functionality should look like]

[nielsfaber]

If there's some issue with entities scheduler is calling, there is no simple way to find out or fix the state. Eg. if scheduler triggers a light off but it remains on for any reason.

Scheduler checks if an entity is unavailable, if this is the case the action is postponed until the entity becomes available, otherwise the action is executed directly. There is a maximum applicable to the amount of time that can be postponed (for a schedule using timeslots without start+end time), this could be the 9 minutes you are referring to.

I would expect repeat_type to repeat actions

No, this property relates to the repetition of the schedule itself, so whether a schedule should loop to the next day after ending, it has nothing to do with execution of actions.

Ideal solution would be to have action eg. scheduler.ensure_state

No idea what you mean by this.

Note that scheduler is only designed to execute a given action at given time and day. If an entity changes its state afterwards, this is not detected nor reacted upon. The behaviour you can expect from scheduler is equivalent of creating an automation that is triggered by time.

[pdcastro]

Ideal solution would be to have action eg. scheduler.ensure_state

No idea what you mean by this.

I may have some idea. Some definitions to make the discussion more precise:

• Scheduler Entity: a scheduler entity such as switch.schedule_0c9ddd.
• Controlled Entity: an entity such as switch.bedroom that refers to a physical object like a light switch, for which at least one Scheduler Entity exists (i.e., there would be at least one Scheduler Entity whose entities: property referred to the Controlled Entity).
• Implied State: the “implied” or “expected” state of a Controlled Entity at a given time. For example, if Scheduler Entities dictated that a Controlled Entity like switch.bedroom should be turned on at 8pm and turned off at 10pm (there being no other Scheduler Entities for this Controlled Entity for this period of time), then, from this information alone, it could be implied that the state of switch.bedroom should be “turned on” at all times between 8pm and 9:59pm. As such, the implied state of switch.bedroom for a given time of “9pm” would be “turned on”.

My impression of the meaning of an “ensure state” service is that, given a Controlled Entity ID, it would compare the current actual state of the Controlled Entity with its Implied State as defined above, and if these states differed, an action would be executed to change the current actual state so that it matches the Implied State. In other words: If a light switch was supposed to be turned on at 8pm and turned off at 10pm, and now it’s 9pm and the light switch is turned off, then turn it on!

If so, it’s something that in the past I had myself wished, not in the context of an unavailable entity, but in the context of the home assistant server being “down for maintenance” for a period of time. When the server was up again, such an “ensure state” service could “correct” the state of entities for which scheduled actions were missed while the server was down.

A less ambitious, perhaps pre-requisite feature would be a “scheduler.get_implied_state” service that, given a Controlled Entity ID such as “switch.bedroom” and a time such as “9pm”, would return the Controlled Entity’s Implied State such as “turned on”. A user could then setup an automation that ran periodically to compare a Controlled Entity’s current state with its Implied State, correcting the current state as needed.

[fpytloun]

Scheduler checks if an entity is unavailable, if this is the case the action is postponed until the entity becomes available, otherwise the action is executed directly.

So this will be probably my issue. Because some entities are not unavailable but changing it's state might not succeed (in my case Z-Wave devices). So one addition might be to wait a while and check if state was actually changed and if not then retry.

But what I wanted was to have option to know if actual state is matching scheduled state (eg. by having some sensor or attribute on scheduler entities) and option to enforce scheduled state (by service similar to scheduler.run_action but that will respect all scheduler settings).

[Floyd-Schramm]

+1 on this feature.

In my case, it would be nice to be sure a switch changed states successfully. I've got a schedule for switching on and off our pool pump to circulate the water. On hot summer days, this is really important, so no part of the schedule should be missed. The pump is controlled by a Zigbee smart plug, which will be switched by the scheduler. If there is an error in the Zigbee network and the packet gets lost, or a Timeout occurs, the smart plug is not switched and continues in the same state as before.

So it would be handy to have the scheduler being able to check if the state change really happened and, if not, try to switch the entity again. I would go even further and implement a notification feature, so the user could be notified if:

1. The entity change was not successful the first time, but it was able to switch the entity by the x-th try
2. The entity change was not successful after x tries

The timeline should look like this:

[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

[fpytloun]

Bump