In my home automation setup it happens from time to time that I execute a command to a device but somehow the device doesn’t receive the command and doesn’t change it’s state as requested. This is not a problem of HA but e.g. of the Zigbee command not making it through to the device.
That such command drops exist is evident e.g. when you have set up a group of several blinds in HA and all blinds run the “Open” or “Close” command but randomly one blind may just not execute the action. As stated this happens randomly.
My feature request/suggestion is:
To improve the overall reliability of HA based smart home activity there should be a global feature in HA that automatically checks for all / selected devices/entities if after a state change was requested the requested entity state is actually being reported by the device/entity after a configurable time (for a blind that takes 20 seconds to close/open I’d like to e.g. set an automatic state check to happen after 1 min).
Based on the outcome of this state verification check there should be the option to either
repeat the command if the device/entity reports back that the state is not as it was requested (x times, this should be also configurable, incl. time interval setting)
and/or
e.g. send a notification or execute e.g. set a variable and execute a selectable automation which then can be used to run custom follow-up actions.
Apologies if the technical terms used in my description may not all be accurate with respect to HA architecture. HA experts will certainly know different/more efficient ways to implement such a functionality.
Service calls can now return values, but all the integrations needs to implement it too.
Your solution is far from perfect though.
First you need a sensor that can detect the change and that sensor needs to report it’s update frequency, because a timeout lower than 2x that frequency would make no sense and you can not rely on the users to know this information.
Then you also need to handle events where an automations runs in serial and not as yours in parallel. What happens when device does not respond in a serial setup and what happens when the device does not respond after the retries? Should the automation stop or even do a roll back?
And what with devices that are not related, like a switch that triggers a lightbulb.
@WallyR Thank you for your additional thoughts and detailing the (potential) challenges with such an implementation. From what I think to have understood from your remarks I’d like the add the following thoughts:
Regarding your argument of update frequency of sensors: I think this information is probably not provided currently by any device. But I would assume that most devices - if not all - which accept state change commands would normally immediately report their changed state/value, at least that is what I’ve seen so far with my devices that accept state change commands (covers, lights, trvs, sockets). For other sensors sending unidirectional information only my request wouldn’t apply.
Regarding automations running in serial configuration: Why shouldn’t it be possible to integrate such a check in the background after each automation step (for those devices/entities which accept state change requests)? If an automation step doesn’t report back the expected value this would also be an option to cancel the automation (such an option could be offered in the automation settings).