Hue Bulbs status lag, its effect on RL, and suggested cures

Regrettably, testing with "Restore the lights to the state they were in before Activation" engaged reveals a caveat (somewhat obvious yet worth mentioning):

If the captured devices do not reliably/timely report their status, then RL may ignore their pre-automation state, yielding unexpected results upon Turn Off.

For example, whenever such an RL includes one of my Hue bulbs -- whether listed as "CT" or "Dimmer" in the RL capture table -- the bulb must have settled for at least a minute in order for that pre-activation state to be reliably restored when the RL turns Off.

This aligns perfectly with RL's general inability to capture the current state of my Hue bulbs (which use the 'hueBridgeBulbRGBW' driver) accurately, or at all, unless they were placed in that state more than 60 second prior, sometimes longer. NOTE: The behavior is also mirrored in the Hue bulb's main page under Devices.

Scenario 1

Start with Hub bulb fully Off. Go into RL "Set Up Periods" table for editing purposes. Tell Alexa (or any method not involving HE switch/rule or device's own main page) to "Dim Fireplace Bulb to 60". Wait 5 seconds, then click "Re-Capture" button.
Continue clicking "Re-Capture" every 5 seconds until actual, known state of Hue bulb changes to match (e.g. "On" and Level (60))
in table. Note that this may take up to 8-10 presses!

Scenario 2

Start with Hub bulb fully Off. At time = 0s, set bulb Level to 60 using Voice Assistant and visually verify brightness fades up and remains at that level. At time = 10s, activate (by clicking "Activate" or turning On Activator) an RL whose sole action involves setting that Hue bulb to Level 99 and has "Restore the lights" engaged (as shown above). At any later time, de-activate / Turn Off the RL. Observe that the Hue bulb does not restore to Level 60, but instead turns completely Off.

I post this as an advisory for users with wayward devices like my Hub bulbs, which have flummoxed RL (and me) since its initial release. Let it serve as a warning to take your time setting up these automations, as well as when troubleshooting them! I cannot stress enough, however, that the aforementioned caveat is NOT a shortcoming of the Room Lighting app, more a limitation of certain devices/drivers.

READ ON FOR VERIFIED SOLUTION(s) TO THIS "STATUS LAG" ISSUE!

This is a general issue with the Hue Bridge integration because the current Hue API is polling-only. The default polling interval for Hubitat's Hue Bridge integration is 1 minute, which explains the behavior you see. It can be reduced in the app if needed, or a "Refresh" command on the Hue Bridge device is a way to force one immediately, but I wouldn't do either of these unless there's a real need.

For most Zigbee and (modern) Z-Wave devices that are directly connected, this is not an issue. Hue is developing a v2 API that offers the ability for external systems to get real-time updates; if Hubitat's integration ever switches to this API (which is not yet finished, and I wouldn't expect much before then), it should change things. Even currently, this is not an issue when sending commands from Hubitat because the integration infers the new state from whether the command was sent successfully.

This is outside the domain of Room Lighting, as you noted at the end. Apps can only know about a device what the device knows about itself, and for polling-only devices, this is the only behavior you can expect when they need some time to catch up.

4 Likes

Just an FYI - This is only an issue if one uses the Philips Hue Skill to link Alexa and Hue together directly. If the Hubitat Alexa Skill is used to bring the Hue bulbs into the Alexa ecosystem instead, then the voice commands will result in the Hubitat Hue devices having the correct state without having to wait for the next polling interval.

4 Likes

Amazon Alexa has a built-in local Hue bridge integration capability. It was one of the first Alexa integrations. IIRC, it does not even require a Skill. I am not sure how one would disable that original form of integration… :thinking:

You may need to go into the Hue mobile app and look for the integrations, and remove Alexa? Just a guess.

1 Like

That switch is to prevent having duplicates Hue lights from appearing in the Alexa app.

Many users come to Hubitat with existing Hue and Alexa devices already paired together. Hubitat tries to avoid the confusion of duplicate devices by defaulting to not sharing Hue devices via the Hubitat Alexa Skill. You will need to turn that feature off if you want your lights to show up in Alexa.

To remove apps that are allowed to control your Hue bridge, you’ll need to go to account.meethue.com. There you can see what apps are tied to your Hue bridge and will be able to remove them, as shown below.

I am guessing that Alexa is allowed to control your hue bridge directly.

1 Like

Glad to hear! Enjoy!

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.