Is there a way to have Smartthings retry commands if they fail? I’ve been working with many devices for many years and have always just accepted that sometimes, things don’t do what I ask. But do I have to?
When issuing commands, there are times where it just doesn’t happen. I don’t get an error message, I have no idea if it’s retrying or how many times it might be. Etc.
Is there a way to get feedback from Smartthings? Command successful. Not successful. Retrying 3 times. Etc.
I would like to have a little more confidence in the system rather than trying to remember to check the device status in 10 minutes to make sure the light is on, door is locked, etc.
At least stock Zigbee and Matter drivers do not retry anything, they send the command and don’t care about the device response.
However, since they subscribe to the state, you can automate the check that everything is in order to retry and / or send you a notification if the state is not what it’s supposed to be.
For instance, you could create a routine like “If Security Mode is Armed for 2 minutes and door is unlocked, send a notification with text the lock failed”.
it would be nice to have either “try again” in 10 minute feature or a driver level check. Industrial controls often have a means to “prove” that their enablement is in fact working or they can take an action. I often have my “go to sleep” manually run/ scene miss something, presumably due to network traffic. It would be nice that these all get turned off soon after I initiate this.
Matter at least does indeed retransmit messages if needed, 5 times by default during the course of a few seconds with exponential backoff. That adds some reliability in case of network congestion, but an automation would not know if the operation was successful.
It’s an interesting topic, while I would not trust a smart home platform for some unattended scenarios, with a virtual switch and a couple routines it would be possible to mimic a manual “let’s see if this light is off as it should be and turn it off if not”. Doing it at driver level would just save creating the virtual switch and the routines.
Inside the drivers it should be a custom capability with a “Ensure it is Off” action for instance that would keep trying until the device reports it is off or there’s a timeout. And maybe even an attribute to check the state (trying, success, failure) so a routine can send you a notification. But, again, that can be done with routines.
The confirmation is sent by the device, in Matter it’s the InteractionResponse. They don’t seem to handle it, just print the log, for instance to turn on a light:
If it was a failure or lack of response, the driver or the automations would not know. Drivers could handle it to implement other kind of retries or expose the errors for added reliability / information.
In the end however what a user needs is confirmation that the state is correct, and since the state is available for routines may as well check it in one.
When this is of most value to me is when I run a scene with many lights turning on/off. This is usually when I’d need it. I suppose I could generate an automation that runs after the scene and essentially either runs it again, or check that correct state of each and then generates a warning or runs it again if it one item fails? Seems doable, but messy.
Yes, could be a few routines if you have many devices. The basic idea would be a virtual switch that you would turn on to go to sleep, let’s call it “Sleep”.
If Sleep is on, Then turn off light X
If Sleep is on for 1 minute, Precondition light X is on, Then turn off light X
That would essentially retry the off for a light that didn’t turn off. Although it would be better to know why they are not turning off in first place.
We’ve been there it seems, WiZ has an interesting bug in their lights when you schedule dynamic modes in their app: when the time arrives, the Matter part thinks the light is off and does not report an “on” even if it’s clearly emitting light.
I’ve definitely seen reported state issues with other things as well that get “stuck”. An independent measurement as @Andreas_Roedl would work but might be complicated to do with lots of lights or plug loads unless your had lots of sensors.
