Fail safe when command doesn't get through

📐 Rule Machine®
1

Any recommendations (or perhaps something is already in place) whereby a control command doesn't get to a device?
I have a socket-outlet that is programmed to turn on everyday at 6am.
Checking the socket this morning it didnt turn on so can only guess there was a hiccup.
i could put a second command in place at 5mins later as a belt-and-braces approach but where do i stop?
Does HE validate the device has been set as requested?
It is a z-wave PLUS device so HE is aware of the current state.

2

You could use a While loop to continue to send an On command every 5 minutes. For example:

While (Outlet is off) Repeat every 0:05:00
		On: Outlet
END-REP
1 Like
3

nice tip! thanks.
What app would you use to perform this?

4

Rule Machine

1 Like
5

Under rated concern that many don't become concerned about until they have an awful lot of HA configuration in place.

Wish there was some inherent "built in" aspect of the protocols and HE device handling whereby whatever combination of: a) lack of communication, b) garbled communication, c) indigence on the part of the device, or d) act-of-God that prevented the command from being acted upon so that HE could a) repeat for X, or b) advise in an unavoidable manner...as a matter of course.

6

This is a terrible idea.

Suppose, just to give one example, that a device has been unplugged, or its breaker popped. If the hub starts banging away at it that degrades the mesh network, and will never succeed. As @UkSub asks above:

There is no good answer to this question. When a device doesn't respond, it is necessary for the user to find out why and correct it. That cannot be automated, your intelligence cannot be replaced. Attempts to automate doing this will fail and possible harm the performance of your hub.

You can use apps to give you notifications about devices that are not responsive. For example, this one in our public repo notifies about devices with dead batteries:

4 Likes
7

Sure, "repeating till the cows come home" is a terrible idea...but there's probably a little better solution to the core issue here. Seeing the creative things you've come up with ...I can't believe "not knowing until the next battery check" is your best idea for a higher level handling of this.

But I understand that a lot of this is dependent on the user. Thus the duplicate sensors I employ when irrigating fields overnight and depend on a CLOSE to be heard and acted upon.

8

Battery reporting is horrible in these devices, generally. Some will report 70% and then be dead the next day. Any predicative algorithm is sure to fail. So really the only reliable thing to do is to notice that the device hasn't reported after the fact. If you have a notification running to report batteries at < 20%, some will simply fail before that happens, and some will keep on going for a long time.

So, it's not that this is the "best idea", it is simply the reality of the way these things work in the real world.

4 Likes