Hue Bulbs Intermittently Not "Reachable" (CoCoHue integration)

After noticing that certain Hue bulbs were occasionally failing to turn ON as instructed by RM, I created a rule that simply watches each bulb's "Reachable" attribute. To my amazement, some bulbs (example shown in this screenshot) oscillate between 'true' and 'false' at random times, multiple times per hour:

Each 'outage' appears to last for around a minute, typically, which roughly corresponds to how often the CoCo Hue integration pings each bulb.

I'm currently using the CoCoHue - Hue Bridge Integration to drive my Hub bulbs, all of which are more or less in line-of-sight with the Hue Hub itself, none more than 30 feet away. Has anyone ever dealt with this issue?

I've certainly searched the Forum for other examples of this behavior, and see a few, but read nothing conclusive about chasing down the cause:
Hue bulbs unreachable ◄— does not directly apply
Hue - No route to host (Host unreachable)
Hue bridge logging / troubleshooting
Hue control intermittent issue
etc.

Given the availability of more modern, less expensive Zigbee bulbs on today's market, would it be worth my while just yanking all the Hue bulbs and replacing?

I would first verify that your Hue bridge is working properly, with no network connection issues.

Used Hue bridges are cheap on eBay. Certainly cheaper than replacing 30 bulbs.

1 Like

On the strength of your recommendation, I just power-cycled the Hue Bridge, and observed that after all three blue lights briefly lit, only the first two remained so (Power and Network). Will hunt down some Hue-specific troubleshooting tips online to see why the third might not light up.

MANUAL SAYS: "Wait up to 5 minutes for all three lights to turn blue."
So I did, and they did. :slight_smile:

Fortunately, I only have 5-6 Hue bulbs in my setup, and only 3 or 4 of these are incorporated into daily routines, so they would not be too challenging to replace if necessary. I simply hadn't considered changing out the Hue Bridge 2.0 itself. Thanks!

UPDATE: Watching CoCo app's DEBUG Logs, it seems that restarting the Hub Bridge 2.0 quieted the 'false' chatter for almost 26 minutes, so that's progress! Still... hmm.

2 Likes

First light is power, second is it got an IP, 3rd light means it talked to home (Hue). As a rule I reboot my Hue hub weekly because of "not responding" issues. Since I've started rebooting it I haven't had them.

1 Like

Interesting. I wonder how coco hue is determining if a bulb is reachable. I don't see anything like that in this integration or the built in one.

I wish the hue hub had a log on it I could look at to see if the hubitat command was actually reaching it, or if it were a hue issue.

Whatever test it is running it happens every minute according to the debug logs. I may incorporate a quick check in my RM rules to see whether a particular bulb is reachable immediately before sending a command to it. But that kind of defeats the purpose of grouping bulbs in RL scenes.

There is no testing involved, at least not on the CoCoHue side; this information is reported for each device by the Hue Bridge, and CoCoHue simply reports that data. (If it's happening every minute, that must be what you have your polling interval set to. This data is probably also in the v2/real-time API but is not being used for this purpose yet.)

1 Like

Right, I just left the Coco settings at their default polling interval of 1-min., as shown here:

Can you think of any good reason to change that? And have you heard of this "Reachable = false" phenomenon cropping up before? I may just live with it as-is.

Polling interval is totally up to you and your needs; the biggest disadvantage to faster intervals is more hub load (I think 1 minute is a reasonable default, mostly because that's also what Hubitat's built-in integration defauls to, but if you're using eventstream, you can probably go less if you want to). I haven't seen any oddities with the "reachable" attribute, so it seems surprising unless you have a weak Hue mesh (unlikely with lots of bulbs and them all being near the Bridge) or lots of interference (Wi-Fi or other Zigbee networks on overlapping channels, for example, though Zigbee is still usually pretty resilient about this). I suppose a faulty Bridge, as guessed above, could hurt things, too (though that's not something I've seen myself--yet?).

2 Likes

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