I have a Rule that sets individual LEDs on 4 Inovelli Blue dimmer/switch units to have a daytime set of ON/OFF colors, and a nighttime set of ON/OFF colors. The IB units seem to take a bit of time to make individual LED changes, so I've padded the rule with explicit delays of 3 seconds between moving on to a next LED. The Rule actions are called by a scheduling rule, so it has no explicit trigger.
I've also found that it sometimes takes the IB units a few tries to get set to a new LED setting, so my Rule repeats the actions 5 times, with an original repetition period of 30 seconds.
The Rule (image of current below) has generally been running fine for some months, but in the past week I've gotten hub messages about the 4 IB units using a lot of hub resources (and HE response has become glacial). Looking at the Rule, it shows as "Repeating". I initially thought that the loop was repeating before all of the delays and actions had completed, so I increased the repetition period to 120 seconds.
I was still getting the hub message re resource usage, so I added a loop counter (vLoopCounter), and tonight found that the loop was at 258 cycles (rather than 5) before I killed it. Accordingly, just tonight, I've added an IF action to exit the Rule if the loop counter is greater than 5 (so the Rule image below has that new IF action).
Am I misunderstanding how the "every x seconds" aspect of the REPEAT action work? Or is it broken? Or am I trying to solve this problem in a very awkward way?
I do have the "command retry" setting enabled for these devices.
However, it's unclear to me that the "command retry" setting extends to custom commands (which appear to be required to change the individual LED settings on the Inovelli Blues).
Once I enabled that, I've had great luck with all my devices in general.
If you're doing "command retry" AND you're manually repeating commands every few seconds, you're likely to create congestion and confusion.
Personally, my Zigbee devices seem to work well almost every time (it's my z-wave ones that get tripped up--but, I have WAY more z-wave devices right now).
Have you had problems with them behaving with command retry enabled and no retry loops? Or, was this an issue you were dealing with prior to the "command retry" feature?
You can look in the logs to see if the command retry feature is trying multiple times and if, after like 5 attempts, it gives up.
In my case, I often see it give up on some z-wave devices after 5 tries--but the devices are almost always set properly now. I'm my case, it's the status not getting back to the hub causing the issue (and that generally gets updated after a delay). I think it's a bit of a network load issue.
As I noted, I do have the "command retry" setting enabled for these devices. I used to NOT have it enabled, but was having problems with the actions taking effect for individual LEDs, so I enabled the setting.
These IB switches and dimmers seem to just take their time changing individual LED settings, hence I've found empirically that delays and repeats have been needed (note that I have 3 other sets of IB switch/dimmer units that have similar rules that function fine with the delays & repeats I've set for them -- however, I change ALL of the LEDs at once for those other sets, so not quite the same situation as for this problematic Rule).
It may be that you are right that doing BOTH "command retry" and Repeat is causing congestion. For now, I've kept "command retry" enabled, but I've increased the delay between individual LED setting actions to 10secs and that seems to be working. I did turn logging back on, but I have not seen any indication that commands are actually being retried.
More fundamentally, I'm still not clear on why the Repeat action never stopped.
However, I've built in a conditional that forces a loop exit if the number of passages through the loop exceeds the defined number of repetitions, and also instrumented the loop and the entire Rule to determine and report on the amount of time required to run the Rule and one passage of the loop.
Just to allow any retries to complete, going with at least a 10 (maybe 20-30) second repeat would be good.
If it's just that they're slow to change, repeats/retries won't help that. But, setting a 30+ second retry loop might let you see if they eventually catch up without a redo.
