Iâve been having this problem for months now with Hue Lighstrips. In my kitchen I have a row of plinth lights (called âKitchen Plinth Lighstripâ) and a row of worktop lights (called âKitchen Worktop Lightstripâ).
At random, the worktop lightstrip will come on to 1% brightness on motion even though the rules state 100% brightness. The only way to get it to go 100% brightness is after lights have shut off and then new motion.
The plinth lighstrip always come on at the correct brightness.
Regardless if I use a Rule Machine rule or Motion Lighting rule I get the same thing.; random 1% brightness
Iâm running the latest HE and Hue firmware. Hue lighstrips are paired to Hue Bridge.
Here is the ML rule:
I believe this is similar to a long standing issue I've had with the Hue Integration.
Basically I've found that setting level and color temperature or color often results in one command cancelling the other. My theory is that HE is so "fast" that it's overloading the Hue Bridge's ability to process the commands. My workaround is to separate level and color/CT commands with a short delay (1s) seems to work. It results in a longer rule, but it works consistently. I don't know if there is anything else that can be done to make this work more reliably using the HE Hue Integration.
I haven't tried it yet, but I'm guessing if you had a second HE with the Hue bulbs directly connected it would probably solve the issue, but I can't confirm this.
FWIW, I've had a somewhat similar issue but it only involves sending a daily turn on and set level to 40% command to a Cree bulb on the Hue bridge. Every so often I'll find the bulb is only at 1%.
Thanks @halfrican.ak. I will give that a try. That canât be done in ML can it?
Itâs weird how the plinth light strip never has the same issue; almost like set colour is higher in the execution list to set CT
I believe the issue is that a set color temperature and set color commands automatically sends an "ON" to the bulb), so if you set up the command with set color temperature and set level the bulb the Hue bridge is getting two commands that turn on the bulb simultaneously, resulting in the inconsistent results (Set CT interrupting the set level).
I don't believe the Hue bridge supports sending a set level/set CT command in the same "API Call", but I do believe it supports it for the set color/level so when the HE is sending a command with color and level the bridge is receiving it as a single "API Call".
Not sure if I explained my observations very clearly (long day) but I can say that my workaround of separating the commands with a slight delay works every time.
@halfrican.ak hehe your explanation is fine - I see exactly what you mean.
Have you raised this with Support before? I did months back but was told it would be fixed in a future patch but it hasnât been
Yes, on multiple occasions, along with the request for adding the "Notify" (aka Flash Bulb) API command to the driver. The last response I have from Mike Maxwell was that they have many requests for enhancements to the integration but no timeline is set.
@halfrican.ak and & I have discussed this before. I don't seem to have the issue, and he does. Not disagreeing that he & you have the issue, just saying it seems to be inconsistent.
The only think I can see in your rule that is "wrong", but likely isn't the cause, is the fade time of 1 second. I'm nearly positive the hue bridge won't accept a fade command like that. Halfrican showed me that it can be done through the device page, but I've never seen it work in a rule.
I doubt that would be the issue, but there is a slim outside chance that including that could upset the Hue bridge.
@AndyM the fade time is definitely not the issue. I added that to all my lifx and hue bulbs about 3 days ago in ML rules (seems to have worked for lifx bulbs hehe). The fade time matches the device page so i was aiming for consistency.
This problem I originally reported back on 2.0.8.107 back in March as I have the same issue on a Hue floodlight (which also does set CT value actually and always the same brightness level) as well as multiple hue Lighstrips
As @halfrican.ak has the issue and a solution, I'd go with his. But another possible solution would be a delay between the two lights versus separating into 2 separate commands.
So right now, a mode change happens, and 4 commands are sent to the bridge. A delay would at least cut it down to 2 commands, then a second 2 commands.
Interesting, so the LIFX bulbs ignored the device page setting, but follow the rule setting? And the hue bulbs on the bridge are the opposite? It's discovering fun things like this that make a couple simple rules take all night. And very likely not a Hubitat issue.
@AndyM is correct, I overlooked that, I also try not to send more than one command to multiple bulbs at the same time I put a "delay actions" between them. If I want to turn on multiple lights at the same time I use hue groups to achieve this (it's super easy now that hue added "zones" which allow bulbs to be a part of multiple groups, HE sees them as normal hue groups).
@AndyM Damn. Just tried changing driver fade to No Selection but it defaults to 500ms.
Lifx can be set to 0 fade in the driver though so ML definitely works but I guess as Hue already has a value > 0 it might be using driver value instead of rule value
I did some quick googling of Hue API "rate limits" and found a reddit thread that has a quote from the Hue API FAQ (this thread was pretty old so Gen 2 bridges might be different):
"How many commands you can send per second?
You can send commands to the lights too fast. If you stay roughly around 10 commands per second to the /lights resource as maximum you should be fine. For /groups commands you should keep to a maximum of 1 per second."
So it would appear that using "groups" is more restrictive than using commands for individual bulbs, but I'm sure the fact the Hue bridge has to receive the command, relay the commands to the bulbs, and reply to the API call adds to the complexity and potential inconsistent results. So I'd say that even Philips is saying not to send too many commands simultaneously, so using the "delay actions" is probably a good workaround.
I've also been having quite a few issues with my Hue bulbs recently including 1% instead of 100% issues. I've just had it happen with a single bulb called by a simple RM rule.
This is the rule and the log. The log actually shows that HE is trying to set it to 1% not 100%, so it doesn't seem like an error at the Hue side of things.
@Geoff_T same as in my logs for each of the individual devices in the original post. Yet the ML rule log showed it was sending a 100% brightness command
I've tried multiple times, I'm fairly certain it ignores it in rules.
