Global Use Of "Enable command retry logic"

[velvetfoot]

I was thinking of going into each device and enabling command retry logic.
I don't think there's any way to do this globally in one shot, is there?
Any downside to doing this?
I guess I'll find out, lol.
Oh, and yes, I'll be making a backup first, lolx2.

[user2574]

Settings -> Command Retry

It lets you set all devices to use retry per protocol.

My feeling is that it creates a lot of unnecessary processing if not all devices need it.

[velvetfoot]

Wow.
Very Cool!
You saved me a bunch of work!
And so easy to undo!
Thanks again.

[velvetfoot]

I deleted a rule that turned all lights on/off twice, to catch any stragglers.
One cycle with the retry logic setting on, worked.
Small sample size, early days, etc, but encouraging.

[rob9]

@user2574

My feeling is that it creates a lot of unnecessary processing if not all devices need it.

Hopefully it's not too bad. It adds some processing--but it doesn't retry anything unless it thinks the device needs it. So, the overall load should be way better than just re-sending commands to every device multiple times (which was about the only option before when using rooms/groups).

It's often not that any specific device needs a retry--but, instead, when you change a bunch of devices at ones, a random handful don't get the message initially. Thus, having it on everything addresses that issue.

While there currently seem to be situations where the response from the devices doesn't get picked up by the hub, that's usually a very small number (they report extra retries and/or "failed" after 5 tries even though they did work). All in all, it works great--and, by limiting the retries, it greatly reduces the load on the network and speeds things up nicely.

[user2574]

@rob9

It's often not that any specific device needs a retry--but, instead, when you change a bunch of devices at one

Good point. When I change a bunch of devices at once, I put a small execution delay between each update, so I don't really see the multi update issue happening. I do have some Zigbee switches in a greenhouse outside, that are close enough to the house to stay connected, but will sometimes miss commands, so retry has really helped on those specific devices.

[rob9]

When I have a lot of lights to set, I'm now doing it with Room Lighting scenes, so it doles out the commands as it sees fit (previously, I used scenes). That way, I can add/remove/change device settings for my various setting groups without having to rewrite a bunch of code. Command Retry has been a godsend for that!

[rob9]

Also, @mike.maxwell chimed in here:

[2.4.2.164 C8P] Command Retry Question

command retry doesn't care about the transport protocol. My point was that if the initial command succeeds for any given device there isn't any appreciable overhead on the hub. Now if all your devices are off line and some rule tries to change the state of them, sure, its going to add quite a bit of traffic to any given mesh, but I might suggest in this case you've got other much bigger issues to deal with...

And in the comment right afterwards--his comments support the idea that using command retry globally isn't an issue.

[user2232]

You might not want to enable it on smart bulbs that you frequently turn off at the switch. If the bulb does not have power, the hub will try 5 times in vain every time it is to be adjusted.

With it enabled on many devices, I found that the extra traffic is enough to make communication noticeably less reliable when a lot is trying to happen at once, e.g. good morning, goodnight or goodbye.