I have similar issues with lights becoming randomly unavailable, hoping someone can look into this!
Same issue and on a NUC too. I deleted my Hue hub and then rediscovered it , paired and so far it has been robust
…some more info.
I’ve also tried doing a factory reset of the the Philips Hue hub. It works fine through the Philips Hue iOS app, and though any HomeKit app, so the only problems I was seeing was through Home Assistant.
Did this an hour ago… and all lights unavailable yet again… this is a joke
and it is now happening every 10 minutes.
https://github.com/home-assistant/home-assistant/pull/13109
Only now do I realize this is explicitly introduced and thus intended behavior…
have had issues with this ever since.
I had a few links for reference lined up: Any hope to get hue.hue_activate_scene back?
Btw, I thought to have it solved, (by disabling the CC hue.py and killing all my python scripts listening to the lights). It isnt though , lights are still showing unavailable at irregular and often times.
Unfortunately it is still very unstable.
We might want to raise the issue again on the Github… This newly introduced Catch should mark lights unavailable when the hub is, but as I can safely report, this happens even when the Hub is available just fine. Got 3 device_trackers to prove that 
Like everyone else here, I’ve had this issue off and on for several months, I also have a device tracker for my hue hub, but…It could still be connected to the network, but not responding to “hue” commands, etc. At least I could see that possibility.
I do think you’ve found the “cause” though. Seems very plausible that the hub is not talking well with HA for a bit of time, and the bulbs are then being set to unavailable. That makes more sense. I’ve been troubleshooting this as a mesh issue, or a bulb issue, but sounds like a hub communication issue with HA. Any logs I could look at to see what the actually communication issue might be? Next time I happen to notice it I’ll make 100% sure I can still control the bulbs with my hue app. For me the flapping only lasts for short periods of time, so its not always easy to catch.
nothing in the logs besides the things I have posted many times now. I fear the Catch if Hue bridge goes to unavailable triggers when in fact it shouldn’t. Maybe that should be rewritten somehow, I havent checked that, and, probably can’t…
Before I always thought it coincided with upgrading to the asyncio , but now believe it has to do with this. If so, thats hopeful… since reiterable
Good deal. I agree, i think you are correct as far the hue bridge being marked as unavailble when it probably should not be.
Cool, hope to have found it indeed! Cant wait for this to get solved…
Now how to get the dev’s attention and ask them if this could be the long awaited solution. Since #balloob (note the non-tagging #) explicitly told us not to do that, I wonder how else we can get on the radar with this? Would you care to raise another issue on the github referencing this thread, and possible cause introduced in 12 Mar 18 change: Catch if Hue bridge goes unavailable?
Raising an issue is the right way to bring things that need fixed to the devs attention.
1 Like
I have raised it on github. It is number 16689. I put in what I could which wasnt easy in a hospital waiting room…
2 Likes
So, I’ve gradually been adding things back to my new installation from my old setup. Everything went fine until I started adding back all my automations. It then started showing all the Hue lights as unavailable again 
I’ve now stripped out all the automations that are triggered by, or turn on Hue lights. I’ll now see how that goes for the next few days.
1 Like
Probably not much use, but here is what happened during the day today, it’s pretty typical.
5:07 PM Right Shelf Lights turned off
5:06 PM Right Shelf Lights changed to unavailable
5:04 PM Bedroom Lamp Two turned off
5:03 PM Bedroom Lamp Two changed to unavailable
5:02 PM Bedroom Lamp Two turned off
5:02 PM Bedroom Lamp Two changed to unavailable
2:30 PM Right Shelf Lights turned off
2:30 PM Right Shelf Lights changed to unavailable
12:32 PM Bedroom Lamp Two turned off
12:32 PM Bedroom Lamp Two changed to unavailable
11:18 AM Kitchen Cabinet Tops turned off
11:18 AM Kitchen Cabinet Tops changed to unavailable
10:48 AM Right Shelf Lights turned off
10:48 AM Right Shelf Lights changed to unavailable
8:50 AM TV Backlights turned off
8:50 AM TV Backlights changed to unavailable
The only automations that ran were around 4:53 when someone 1st came home. The rest of the times, nothing was going on
Id like to check that too, how’d you get this printout?
I just copied and pasted from logbook. Then I pasted it into notepad++ and then I cleaned it up a bit
ahh, hoped you had some fancy automation 
still, how to get that info in the log? If I click on Logbook or history in the left side bar, my HA instance locks…
<rant>
This issue has really bugged me and my family for a while as well. To the point where I even started testing proxies and emulated API’s between HA and the Hue bridge. The issue started immediately after HA migrated to aiohue while at the same time no Android app or other code talking directly to the bridge outside of HA was affected at all. The error message used to appear in the log intermittently with a few minutes up to a maximum of half an hour between them (most of the time around ten minutes). The issue was also triggered almost every time a bulb was manually switched via the HA frontend making all bulbs unavailable for a few seconds and the switched one didn’t turn on. Another attempt immediately after that worked most of the time. Bought several wall mounted switches to mitigate that annoyance but at least they work every time and are at least a fallback if the automations fail to trigger for whatever reason. When the setup can’t fulfill it’s primary purpose (which is home automation and not home control) it’s pretty useless though.
</rant>
While troubleshooting I figured it might help to increase some of the timeouts on the HA side and at least in my case it seems to have helped tremendously. After changing a timeout value in the Hue light component a few days can pass before even a single related error message appears. My assumption at this point is that a bridge needs more time to respond, the more populated it is. I don’t know what the optimal value of the timeout should be or if the changed value has any negative side effects but so far I haven’t noticed any on this setup.
Would be interesting to see stats from other people with this issue versus where it’s working as expected. This setup has 15 bulbs, 7 dimmers and at least a dozen groups but I don’t know if that should be considered many since the hub has support for up to 50 bulbs. Has anyone here tested a fully loaded hub with HA?
See the following patch (would be nice to see if it improves the situation for someone else as well):
--- hue.py.orig 2018-09-06 21:44:11.000000000 +0200
+++ hue.py 2018-09-19 11:59:25.053508771 +0200
@@ -164,7 +164,7 @@
api = bridge.api.lights
try:
- with async_timeout.timeout(4):
+ with async_timeout.timeout(30):
await api.update()
except (asyncio.TimeoutError, aiohue.AiohueException):
if not bridge.available:would love to test it for you, but wouldn’t know how… ?
@Mariusthvdb
Save the patch to a file locally and apply it to homeassistant/components/light/hue.py or change the value manually from 4 to something higher like 30 using your favorite editor (timeout value should be found on line 167 if you run Home Assistant 0.78.3) and restart Home Assistant.
To apply the patch you should be able to do something like this:
cd PATH_TO_HOMEASSISTANT/homeassistant/components/light && patch -p0 < PATH_TO_PATCHFILE