I agree, it shouldn’t… but it does.
Didn’t say it was the only source of system delay, but it adds to it. Might be instance dependent. Try to refresh the Lovelace frontend and check your hue lights.
btw, might be a good idea to link these threads: All my hue lights randomly becoming unavailable - #53 by Mariusthvdb
How so though? I’m not seeing unavailable devices on my frontend. They only show up in the history graph. The frontend isn’t even being rendered at the time the lights are shown as unavailable. There’s no user interaction at all.
not really clear what you’re saying here. You don’t have a front-end at all, when this happens? Or are your lights always available in the frontend?
anyways, in my system, when the frontend in Lovelace is being loaded for the first time, or refreshed, which can take its time too, the hue lights are unavailable most of the time. Signalling some serious resource troubles.
I’m saying that at 03:00 in the morning my lights show as unavailable in the history graph. No one is awake and no one is using HA at that time. Its completely separate from loading the frontend.
Yes, that is a known issue… Happens all the time, without users having a clue as to why it does.
see here for an example: Howto create battery alert without creating a template for every device of LL taking its toll on performance…
The fact that everyone is a sleep doesn’t mean your HA instance is 
History is being recorded all the time, and maybe other IO things are happening without user interaction. That is the main reason for existence of this and a few other treads: share info and experiences with our fellow community members, so they might together finally lead to a solution for this rather frustrating business.
OK I may have fixed my issue. I had and Orbi RBK40 and I upgraded to a RBK50 (with new beta software) as it is reported there are issues with wired backhauls. 3 days on and not a single hue unavailable. A drastic and unexpected result…
I had a thought and may try this out of curiosity. Has anyone tried using the homekit controller component to control the hue lights. It would still be local control. Just an interesting way to see if it makes any difference. Also maybe using a real homekit device (apple tv, etc) to control hue, via HA.
I’m getting a little tired of having a light or two not turned on/off with a scene. Not every time, but every once in a while.
Just had an experience I need to share…
recently updated to HA 92.2 and had noticed that my Hue lights stayed available, and the very frequent loss of connection to the Hue hub, showing all lights unavailable had minimized. Excited I was… Only thing taking my lights out, was the reloading of Lovelace after having edited files. Lovelace does take a lot of processing power…
But, and here comes the point, I had lost my history also (No more history since 92.2)
silly me of course, having made an error in the history includes and excludes, which made recorder only record 6 mobile devices, and all other entities weren’t there anymore.
After I noticed and repaired that, restarted the machine, and yes! my history was back for the long list of entities I need recorded.
But, very very unfortunately, I noticed also that my Hue Lights weren’t even loaded. The Hue integration shows all new sensors, but at each and every light it also shows entity unavailable.
So, must conclude that history impacts Hue integration in a most severe way.
Cant live without either though, so wouldn’t know the solution for this one…
Btw, I have a main system still on 84.3 which has steady Hue lights. I have only upgraded my second system to the newer HA versions since that, and it has always been 1 system going fine, other system losing Hue. The former is running Hassos 1.12, the latter Hassos 1.10.
They are different is the Pi’s, one is a 3b, the other is a 3b+…
There were some changes in Hue sensors for 0.92.0 & Hue fixes in 0.92.2 It might be useful to look at the docs again.
I’ve had the same issue.
I removed the hue:-section from my configuration.yaml and activated discovery: - and everything came back, now working as expected.
Have the same issue.
-> turned off or changed to unavailable
Running Vers. 0.91.4.
Its spamming my history.
Anyone have some solutions?
Not a solution, but I ended up removing my Hue lights from logbook and history because of all the noise. This issue has been going on for quite a while now. I’ll say that 95% of the time my lights turn on/off with automations as expected, since my lights are “online” much more often that “offline”. Regardless, I’d love for this to be fixed some day. 
Should we update to 0.93? Is the bug fixed or not yet?
My Logbook is spaming:
15:37
Garage turned off
15:37
Garage changed to unavailable
15:37
Eingang turned off
15:37
Haustuer turned off
15:37
Eingang turned on
15:37
Haustuer turned on
15:36
Eingang turned off
15:36
[Haustuer(http://192.168.178.22:8123/logbook#) turned off
15:36
Eingag turned on
15:36
Haustuer turned on
15:36
Garage turned off
15:35
Garage changed to unavailable
15:35
Garage turned off
yes, me too. Unfortunately, the more I build my Lovelace setup on the test machine, the worse it gets…
Somehow I fear the front-end which is extremely busy in Lovelace, takes its toll talking to the backend. I know devs say it can’t be, but voila, there you have it.
my 83.4 setup doesn’t lose the Hue hub. Still legacy Ha. Which proves btw, that the Hue hub isn’t the culprit. the exact same Hub and lights are steady as can be on the one system, while the other loses the lights every few minutes or worse.
anyone else seen their reappear in the logs? Seem to only be able to relate it to Hue lights being unavailable. Had the error in the logs before, but only after updating to 94.4 it became this frequent…
2019-07-01 11:08:44 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.1.212 ()
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6ce552b8>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c32b3d8>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6cceba08>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c32bbb8>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6d51f660>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c2db2b8>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6ac46108>
2019-07-01 11:08:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6ac46978>
goes on and on, this is only a small snippet
I am experiencing a similar problem with the following error popping up 80-100 times over the course of a day. All my Hue lights flip to “Unavailable” and back at the same time, spamming my history/logbook.
It doesn’t seem like there’s much acknowledgement of an issue?
2019-07-10 10:24:50 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 10.0.1.161 (),
2019-07-10 10:24:51 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 10.0.1.161
I just upgraded home-assistant to .98.0 (I’m on hass.io running on docker on a Pi3B+) and immediately all of my Hue devices are now experiencing these issues. I’ve got the same errors up the wazoo in the log now. It’s basically just a hue error log now. 
First thing I did was google for this issue, and found this thread with someone in 2018 upgrading and experiencing the same issue. Having read through this whole thread, I haven’t found any working solutions.
One does mention to change the hue.py timeout setting, but I’m not sure where to change this file as I’m on docker. There is a hue.py in my docker overlay folder but it’s a leaf of a folder called characteristics, so not sure it’s going to be relevant or ‘stick’.
Any other ideas here?
after having experienced this for almost 2 years now, had to conclude there’s no way to really solve it (from HA side), and we need to find a way to ‘deal’ with it.
Things I found that make Hue work as robust as can be:
try to make the instance as lean as possible, too much goings on frequently kick Hue out of connection. Notorious culprits in my settings are Rest sensors, and integrations/components that require (heavy) traffic at startup (eg Buienradar)
Every now and then adding an extra component immediately makes Hue suffer. I’ve come to see Hue more as a messenger of internal struggle than being a culprit itself.
Never has the Hue Custom component caused issues, nor have CC’s done so perse. The warning message we get using CC’s was added after a firm discussion about this… Not saying CC’s can’t interfere, I have eg always had issues with the custom cards updater (now deprecated), or the sensor authorized. Having a lot of template sensors can cause startup slowdown, which just might (can’t prove it) frustrate Hue initialization…
I have a 2nd ‘clean’ HA install, on which I test all new versions and other stuff. delete these after testing. Only keep Hue, Tradfri, Google cast on those (can’t switch off the endless discovery of those), and Darksky sensor, to create some sensors. It is rock solid. Hue never even blinks.
So, long story short, and what ever the cause may be, Hue signals internal traffic (would not say issues just yet…) and makes you need to review your setup carefully.
Yes, now and then I need 3 restarts for the lights to show up (after not having been initialized at startup at all), or they take 2 to 3 minutes to finally kick in. It’s a bummer.
And, unless a major revamp of the integration will be made possible if and when Hue dev’s finally decide to auto send changes instead of needing to be polled by HA, I fear we can do nothing else than ‘deal’ with it.
Will update soon to a Pi4 and hope the better specs relieve the HA instance of these sorrows…
update
just as a fyi: found another culprit for huge hue connection issues: the Airquality integration Opensensemap.
After having enabled that, constant errors in the logs about not being able to retrieve data for that component, while suffering the notorious Hue errors at the same time. Lag in the system, and lights showing unavailable. Taking it out again relieves the system at once, and lights are back in the frontend…
Is this problem occuring on all platforms ie raspberry pi 3 etc? So not even change from Pi 3 -> 4 could resolve this or changing to totally different architecture? I know that even Pi 3 does have enough power to run everything but still just a thought that came up to me