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.
I have raised it on github. It is number 16689. I put in what I could which wasnt easy in a hospital waiting room…
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.
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
thanks, would love to, really, but since I use Hassio, patching that file won’t be as easy as that I fear…would be cool if we could set in in the configuration of Hue? can’t we?
Ah, I see. I’ve never tried Hass.io but instead use a setup which is very similar to Hassbian and is probably more flexible when trying out local code changes. The timeout value is hardcoded in the Hue light component and is not configurable at this point. I don’t want to create a pull request for a real code change before someone else can confirm if this mitigates the issue outside of my local setup.
I’ll give it a shot if someone tells me where I change it when using docker please?
Same here. I’d like to give that a try but using Docker. So not sure how.
suppose it would be a good idea to post the patch to the GitHub thread, and ask the dev’s?
Changed the value to 30 manually. I’ll report back how it goes. Thanks!
I have always wondered why the Hue integration became unreliable after Asyncio (or the change mentioned here Philips Hue changed to unavailable) and the Tradfri integration stayed solid as a rock.
You don’t happen to use Tradfri lights too do you, and can have a look in the files to see the difference between the 2?
I have a Tiles setup with all my lights and it is a ridiculous sight when the Ikea lights keep burning while the Hue lights go on and off… While in fact they are glowing beautifully in real life with a hitch.