I had this problem and it completely disappeared after switching to Conbee+Deconz…
I am not sure that this was the cause for me but I have had no random issues with Hue lights becoming momentarily unavailable since ensuring none of my Pis are using both the inbuilt WiFi and Bluetooth.
There seems to be a known issue discussed and sort of acknowledged by the RPF here…https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=140471
It is not only an issue for the Hass server but on any pi connected to the 2.4GHz AP. Why it might be the cause when ZigBee is 5GHz I do not know.
Just throwing it out there for some people to test.
Interesting, I found recently that even though my hassbian rpi was wired it had decided to use wifi to connect to my network. After a reboot it went back to wired. I am thinking I should disable the wifi or remove the config so it can’t use my wifi anymore.
I am pretty sure zigbee is 2.4ghz (not 5GHz) which is why channel changes are suggested when not playing nice with your router.
My mistake, Thanks
I did also have lights that are integrated thru Hue being unavailable frequently some time ago. When looking in the Hue app there were no issues with the lights.
My solution was to remove Hue from the Hassio integrations, reboot and then add it again. After that all have been working fine for a couple of weeks now.
I added this to my configuration a few days ago
hue:
bridges:
- host: 192.168.x.x
allow_unreachable: true
allow_hue_groups: false
Since then I have not see a single unavailable light. Does that mean the problem is gone? Not sure, but at least I dont see unavailable messages in my logs every few hours, for random lights. My lights seem responsive, and seem to be working as expected.
no, fear this really has no true related consequence unfortunately, tried that in one of the first attempts in regular Hue setup changes to mitigate the issue, retried just now, and lights keep ‘flapping’… might be correlated though ;-), or simply coincidence.
do you see the
2019-03-05 17:51:03 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.212
2019-03-05 17:51:03 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.212. Retrying in 4 seconds
error in your logs, or have they gone too?
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