Actually, I’ve never had the issue with connecting to the bridge, or losing connection to all lights at the same time (I’ve seen others have that issue). Mine has always been a light or two going unavailable then back to available a min or so later off and on throughout the day. If an automation happened to run during those times, then the light would fail to turn on/off. So far after a few days, I’ve not see the lights go unavailable. Not sure if I’m just “hiding” the issue or not. But so far my lights have turned on/off as expected.
i see, well, good for you;-)
will let it run a bit longer to see if I was concluding too soon.
1 Like
getting back to this, have you customized the lights (and hue groups) to show the show_last_changed? Without that it isn’t as easy to see the lights have gone unavailable.
You’d have to witness the act (which isn’t very hard to force to happen btw, just refresh the Lovelace interface et voila…)
update
just for the record: history component(s) seem to take their toll on the Hue connection. Think it was mentioned earlier, but taking recorder to MariaDB for example makes the lights stay available much longer. Without that in my setup it isn’t possible to see the lights longer than about 13 minutes, using MariaDB already takes them over the hours (check with show_last_changed).
Taking out discovery: in the configuration.yaml is supposed to help too.
Interesting about history component. In my case " allow_unreachable: true" did not solve my issues it just masked them. I did not have a single entry in my logbook (where I track them) as unavailable for days, but I had several issues where I ran automations to turn off multiple lights only to find a hue light or two had not turned off. Also, on two seperate occasions a scene that included some hue lights failed to turn on the hue lights to the correct level or color.
I’ve taken the " allow_unreachable: true" out of my config and sure enough the occasional unavailable bulbs are back.
Also, not that it matters, but I wanted to add one addiditonal data point. I changed hardware the other day from an old i3 to an old i5 processor, more powerful. Really did not make any noticible difference, just wanted to rule out hardware, disk, memory, etc.
I am having this A LOT…
Both with Hue and innr.
Always with GU10
never with bulbs
just as quick fyi, I must report some improvement.
today I noticed Samba and Duckdns had updates available. On my Mqtt hub those are 2 of the 5 (the other 3 are MariaDB, Mqtt which also have an update…and SSH) add-ons I have in action. They are of core functionality, so I was really reluctant to update, didn’t want to brake anything working. Searched the community and found only issues with the MariaDB, and the ongoing issues with MQTT, which started some time ago, and apparently still havent gone)
Bit the bullet and updated Duckdns first, since that is merely a onetime act, of updating the certificates. Went well, and Duckdns connected immediately.
Second step was Samba. Cant live without is. When the fronted won’t come bac due to some script error, or whatever, Samba always comes to the rescue with SSH. So, was kind of nervous to do so.
Lo and behold, all went well, all green lights, in the store. Restarted to be certain, and #knockonwood, the Hue lights havent displayed the unavailable yet, other than in the beginning after the startup process, when the system needs to settle.
Might be worth a shot, to test for you and see what happens. Cant start to explain why this would be of influence yet, but maybe samba does things under the hood and interferes with Hue connection. Both network related, so might not be too silly to consider.
anyways, thought I’d let you know.
I have moved from a celeron nuc to an i5 pc and it is exactly the same for me
I’m trying something new and will report back. I removed my Hue Integration and decided to add these to HA via the HomeKit Controller component. I did have to modify the homekit controller code a little bit, because by default the homekit controller compoent ignores Hue Hub.
Anyway, I was able to add the Hue Bridge to the homekit controller component. It was a bit of a pain, because I had to rename all the lights, the default names were very generic, so it took me a few minutes of turning lights off/on to figure out which was which. I also had to rename them all via the entity registry.
So now for the experiment: Will I still have lights going unavailable in HA when they are not being controlled with the Hue component.
I’ll report back when I get some results
Edit 1: It’s been 18+ hours, I have not had any issues controlling my lights, nothing has shown as unavailable. I will say that what I did notice is that any of the hue component “skills” are not available, such as random color or color loop, but I have to say I’ve only used them once in the past year and that was just to see what it would do.
Edit 2: its been a 36+ hours, so far all is still good. I will say that I purposely removed power from a hue bulb connected via HomeKit_controller, and it never reported offline. Which makes sense, probably does not report offline. Other than that, I have had no issues with lights failing to turn on/off, set levels or colors, with scenes and routines. I get that overall I’ve added a level of complexity (HA to homekit controller to Hue hub), but not having offline/online meesages all day has been nice.
I seem to have been able to stop the error messages by disabling auto negotiation on the bridge’s switch port. I’ve seen some discussions on line about the ethernet port on these bridges being a bit finicky, I’m guessing that’s the case for mine as well.
Since making the change a few hours ago, I went from getting the dreaded Unable to reach bridge messages every few minutes to none at all.
How is that done? I don’t see any such setting in the hue app for the bridge.
Oddly, I have not seen my lights go offine since I have updated all the bulbs to the latest firmware a week or so ago. I wonder if perhaps they fixed something in the firmware?
It’s a configuration option for some managed network switches, not something controllable from the Hue side. I have actually seen a few messages pop up since making the change so it may not be a full fix like I’d hoped, but it certainly made a big improvement if nothing else.
Just wanted to provide an update. I had my hue lights being controlled by the HomeKit Controller vs hue for several weeks. Never saw anything go unavailable, my lights all turned on/off 100% successfully. When I upgraded to .92.2 I had some issues with my HA install and ended up removing the Hue lights and adding back the Hue intergration. Back to unavailable showing up in my logbook on a reguluar basis throughout the day. Every few minutes to few hours. What I’m going to start tracking now is if my lights are actually affected. Are they going to turn on/off 100% as expected. If they do, I’m just going to stop tracking them in the logbook/history for a while. If they dont turn on/off as expected I’ll prob go back to homekit controller, since it worked so well. Only issue is that I’ll end up needing to create a custom component (because hue is ignored by homekit controller in the code by default), and I really dont want to do that. 
Since Update to 0.94(.1) all my hue devices are unavailable. I have removed and readded the hue-integration, but it doesn’t really change. After a restart I reliably have the hue basestation and a hue motion detector listed under integrations, but all lamps are and stay unavailable.
I even restored the old hue configuration in configuration.yaml, but that doesn’t change anything.
3 Likes
I’m getting this too. No idea why it’s suddenly started after working great previously. It’s having a very big knockon effect on the reliability of my Pi as a Hassio server as it discovers and undiscovers every few minutes and is savaging my MariaDB.
No idea why, but Hue is stable again. 0.94.3
All devices are recognized after start and work fine now.
Me too! Just magically fixed itself over the weekend without any significant intervention. Must be a server thing then!?
seeing this now (HA 0.94.3):
2019-06-18 13:47:29 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.1.212 ()
I’ve changed my zigbee channel in the hue hub https://www2.meethue.com/en-us/support/bridge/connectivity/what-is-a-zigbee-channel-change-in-the-philips-hue-app
and since then all my lights stay available.
My lights looked like this Philips Hue changed to unavailable
and now 
Maybe some others can try this…
1 Like
I tried this last night after noticing it was only my upstairs hue lights that were dropping out - seemed stable overnight but same problems this morning with intermittent dropouts.
So I may have found a solution but it’s very specific to my case use.
Resetting Hue hub, changing channels and repositioning lights all had limited effect but the problems still persisted. I was getting frequent ‘Unavailable’ status updates for only my two upstairs Hue bulbs, and even then the unavailable episodes did not match up in time with each other.
I recall the problems started shortly after I migrated my DB from the SD card to a MariaDB on my Synology NAS but didn’t think the two could be related.
However, since reverting back to the SD card DB all my Hue lights have been rock solid. I think rather than an availability issue, it’s more of a “network stuttering prevents HA from reading last saved state from the DB” issue.
Will continue to monitor and update if it flakes out again, but worth considering if you have a similar setup.