I'm using HE with HUE Hub for controlling about 35 hue lights. I have Hue Motion sensors all around the house. Since I want to override the lights at any time I have set the rule machine to set the lights at different levels for turning on based on modes (level 11 for Night, 61 for Evening). When turning off the rule checks if the lights remained at level 11 or 61 before turning them off.
In Living Room I have 10 lights, Hallway 6 lights, Main Bedroom 7 lights and the rule machine (motion trigger) sometimes (8/10 times) doesn't turn on one or two lights at the required level, breaking the check for turning them off and the lights remain on.
If I use the Hue Dimmer (or Hue App) to turn on the lights they ALWAYS turn on correctly, so it's not a communication issue between the Hue Hub and the lights.
I have tried setting the rule machine to turn on the group of lights (Bedroom, Living Room, Hallway) and individual lights one by one and there is no difference.
I'm tired of manually turning off the lights because this system doesn't do it's job.
I refuse to link the lights directly to HE because I have Ambilight TVs everywhere and Hue has a better interface for setting live scenes in rooms.
Can you share a screenshot or description of your rule setup? Also, it sounds like you have a lot of bulbs being controlled at one time. I don't think the Hue API (that Hubitat uses) has any official rate limit, though there used to be something published that recommended something 10 bulbs per second max, which you might be close to or over. If you're setting a lot of bulbs to the same thing all at once, I'd consider making a Hurt group and using the group (imported from Hue, not a new Hubitat group) instead of individual bulbs. Just a guess without knowing more.
If your hue motion sensors are paired with the Hue hub instead of HE that can cause delays if you're polling the Hue hub, but generally wouldn't cause some lights to work and others not. But out of curiosity are your motion sensors paired to HE or Hue?
While it might not be related to Zigbee radio on the Hue bridge, although I wouldn't totally discount that, I would be looking closely at the LAN, as it could be that packets are lost between the Hubitat hub (after the app triggers the commands and the bridge receiving the commands) and the Hue bridge.
To make sure that the issue is not on the Hubitat side, you may want to enable the logging on the Hue devices and app to see if something else is going on:
There are never more than 10 bulbs controlled at a time. The groups are imported from Hue, not grouped in HE. This also happens in the kitchen with only 2 lights.
The motion sensors are paired to HE (because Hue is a disaster when paired with their own sensors).
Are the lights in your rule Hue Groups, then? (The names sound like individual bulbs, but I don't know your naming convention, of course.) I should also mention that Hue used to recommend an even lower per-second limit for groups, though again, I don't know if they still have any formal recommendations.
Looking at the logs I see that motion sensors are not the problem. They always report motion correctly. I mean that the lights turn on, but not all the lights. And for example the hallway motion is in direct view of HE (about 4 meters). The lights in the hallway are 1-4 meters from the HE and Hue Hub.
Tonight I will redo the Rules with the groups and come back with the results, maybe there will be some improvement. I know I tried this the first time I made the rules some time ago.
As you can see in the screenshot, I have to use two commands, one for color, one for level. Maybe this is the problem because if I set one command for color and level the level is ignored (or color - can't remember right now).
My brain hurt making it... but do you know a simpler way of creating the rule? I just want the rule to turn on the lights (using motion) based on mode and to turn them off IF there is no change to the lights. Sometimes I want the light to stay on (manual override).
I meant in terms of troubleshooting the group issue. Otherwise if the rule works I wouldn't mess with it But you might take a look at the new room lighting app... I think it would get you almost all the way there. After you figure out what's up though.
Tonight I'm trying the room lighting app aswell, but it works 50% of the time so far. This app seems to see the lights ON when they are off and doesn't turn them on (in log it says the lights are active? - but the lights are off), and after 5 minutes (without touching anything) it works ok... or turns the lights on and forgets to turn them off (the lights are at the correct level visually and in HE) because "level changed".
As I'm typing this, the lights remained on... the log shows:
[app:629]2022-09-07 21:12:10.748 [info]All motion inactive, scheduling off in 0.5 minutes
[app:629]2022-09-07 21:12:10.746 [info]Turn Off Event: 'Hallway Motion' motion inactive
[app:629]2022-09-07 21:12:00.857 [info]setColorTemperature: Hallway, temp: 2500, level: 11
[app:629]2022-09-07 21:12:00.759 [info]Activating for Night
[app:629]2022-09-07 21:12:00.756 [info]Activation Event: 'Hallway Motion' motion active
it's been at least 5 minutes since the last entry.
If you want to continue troubleshooting your original rule, can you re-state what it is that you want it to do? The actions look a bit odd right now. It seems that you are setting level, then color temperature and level, or sometimes color. This is quite a lot of commands in quick succession, which alone can cause problems, but there is also some overlap. For example, you can set level along with color temperature. (I'll ignore color since it looks like it's only used in one mode that doesn't overlap with the others).
That last thing makes me think: it's possible RM doesn't like per-mode actions when the current mode isn't specified--this would be easy to test and might be your problem, but I have no evidence for that. You could enable action logging for this rule, or just all logging, and see what happens for yourself, which may help with troubleshooting. Then there might be evidence, or at least something that could help troubleshoot more.