I had some Zigbee issue that caused me to pay really close attention to my automation routines. Those issue were resolved but I was still having issues with Room Lighting reliability that I think had been around for a while, possibly since I migrated to my C-8 Pro in the Spring.
It would be very hit or miss as to whether or not any given light would turn on or off. I'd say the success rate was about 60%. What was consistent was that if I went into the app and clicked the Activate button they would always work. I tried a few things including moving everything to Rule Machine with a similar outcome.
But what did work was this:
I added a small offset to each of the Room Lighting instances for both the Activate and Turn Off conditions. Since doing that (3 days ago) none of my lights have missed a single command which has not happened for months.
Warning: Speculation
One of two things is probably happening.
A large number of commands are issued and the network is being instantaneously flooded. I am about 50%/50% Wifi and Zigbee and I would see failures in both areas, but I would say that there were more in the Zigbee group. Perhaps it is worse on my C-8 Pro with the extra CPU allowing it to push out Zigbee commands faster. It was always reliable on my C-7 and all the same Room Lighting instances were there and mostly kicking off successfully.
There is something in the serialization of commands that causes them to be dropped when there are too many in a short burst. The Room Lighting logs would always be correct and say that the commands were issued by Room Lighting, however the devices did not show a corresponding activation.
Hope this helps others as there are quite a few posts regarding Room Lighting reliability.
Thanks for your post, as Room Lighting itself isn't the issue. We did implement flow control around both radios, but your report suggests that isn't working properly. We will take a look. How many devices would be turned on/off in one go (if they all worked)?
I have had the same issue ever since I moved into this house about two years ago. Rather than reuse devices from my old house, I started out fresh with 90% of my devices using zigbee. Mostly Inovelli Blue switches (about 40) and Hue bulbs and downlight retrofits (about 50). No sketchy no-name devices that could cause problems.
Like the OP, I would randomly experience things not turning on or off via automation, yet worked fine when controlled manually either in the device page, or manually activating a RL app, etc. Upgrading from a C7 to C8 Pro didn't make the problem any better or worse.
As to the number of devices on/off in one go, I have a lot of things that come on at sunset. Maybe 10 Inovelli switches and 8 zigbee groups consisting of around 20 bulbs. A lot of things go on or off based on mode changes as well. Sleep mode turns most every switch in the house off, although typically there will only be about 10-15 switches actually on, and maybe 6 zigbee groups of Hue bulbs.
And like the OP, I largely solved the issue by putting random delays all over the place. in RL and RM, as well as using your All Off app. It works but is a bit unwieldly to manage and keep track of.
I've tried all the recommended things to solve zigbee issues (channel selection and power, hub location, etc. etc.) but nothing made the slightest difference, other than inserting these delays.
Maybe flow control isn't working properly, or it isn't optimal for every given circumstance. Would some sort of user-controllable system-wide delay be possible, to avoid having to sprinkle arbitrary delays all over the place?
BTW, I have tried to curb unnecessary traffic by disabling energy reporting in the Inovelli switches, and anything else I could find that wasn't needed. I also use zigbee groups wherever possible.
I had 11 lights being activated at Sunset, 6 Zigbee and 5 WiFi.
At 10:00 PM 8 of those lights would be turned off and three would be dimmed. In addition the back door lock (Zigbee) would fire at 10:00 PM, both thermostats would flip into the overnight schedule and the Envisalink (LAN) would be also changed for overnight settings. In addition there are some routine tasks that might fire on the hour but they do not involve network communication.
Does not seem like a lot but those are the two busiest times in the automation day at my house. As I mentioned this was not noticeable on the C-7 and I had no special accommodations to try and serialize events.
It's been a while since I've seen that option. I was aware of it and looked through Room Lighting to see if I could find it and try it out, but never did find it.
The advantage with group messaging is one command is broadcast to control the members of the group, vs one discreet command per device being controlled.
This is generally the best way to control a large number of zigbee devices for a goodnight routing ect.
This is not a large number. I have a garage group which uses WiFi so not relevant to the Zigbee discussion. My other lighting group is the Patio which has two lights.
So the net effect on the lighting group would be:
Before Group Messaging: 11 lights being activated\addressed at Sunset, 6 Zigbee and 5 WiFi.
With Group Messaging: 10 (effective) lights being activated\addressed at Sunset, 5 (effective) Zigbee and 5 WiFi.
I have zigbee groups with as few as two devices in them, simply for ease of management within apps.
In any event try it and see if there's any reliability improvement.
They are now reliable by having a small gap in their execution and I'm O.K. with that now that I understand it. I was just reporting it for others and as a possibility for improvement in the product.
I do as well. Did not help the zigbee unreliablility issues though, but I imagine it would probably be a lot worse without using groups.
Only the delays, staggered trigger times and use of the All Off app fixed it. Operated individually, every zigbee device works perfectly. That seems to indicate that there's something going on with too many zigbee messages occurring within a certain timeframe. I don't have any idea how to diagnose it though.
Mike - my understanding has been that using groups created in Groups and Scenes and groups defined in RL (per below) provide the same result. Just wanted to re-confirm that since your comment specifically mentioned Groups and Scenes and not RL.
