All my hue lights randomly becoming unavailable

Is there any update on this? I started to have the same problem yesterday when couple of my Hue lights started becoming unavailable suddenly. Noticed this when one of my automations was not working even when HA showed that it triggered normally. And when investigating I noticed that everything works but some of the lights are becoming unavailable and then suddenly available again.

This started when I added device_tracker and couple of automations that use that.

@Mariusthvdb are you still suffering from this or did you solved it by changing the python script and/or binary_sensor ping?

According to the Github issue, someone did a reset on their Hub and it started working. I actually plan on doing this since there are so many useless scenes etc. created by 3rd party andoird and iOS apps but don’t know if that is going to help with this.

Edit: Sorry for tagging you Mariusthvb

no this still prevails, and reseting the hub wont work…
there are many many posts on this.
that being said, I have 2 instances and the one which has my mqtt broker on it (the hassio add-on) suffers most. I can not have any automation rely on lights state, because of that.
It apparently has to do with I/O going on. And we must see the issue as a signal of something else in the system taking processor time/goin wrong. thats what the HA founder told me.

If you add show_last_changed to the lights, you can exactly see for how long they have been seen by the system.
On my Mqtt system that mostly is about a few minutes, and if I am lucky, several 10’s of minutes up to an hour.
On my 2nd system, which I use to show in the app and use as a front-end, light are available most of the time. But reloading Lovelace heavy cards (weather custom cards etc) might again cause Unavailable.

So long answer short: its still there.

see below, showing the same lights/groups in my

mqtt system:

23

and main system:

35

Well this is too bad. It is actually kind of breaking thing and might move people away from Home Assistant in the end if it is not fixed.

I can investigate this on my side but most likely nothing new and useful will be found :frowning:

As a final thing to try take a look here

Since I boosted the wifi signal in my house the lights haven’t shown as unavailable once.

Thanks, I will take that into account. Most likely that has nothing to do with my lights going unavailable since I have a powerful WIFI AP that is only a WIFI AP so it has pretty strong signal everywhere in my house. But this is still a good point to look :+1:

well, not ‘final’ as in this solved it…

this has been discussed before, as has changing the zigbee channels. It might solve some issues in particular for some users,because of their specific home settings. It isnt a solution to the issue in itself though.

It has to do with I/O on your local system and the Hue needing to be polled regularly, as it is implemented now, rather than receiving pushed changed from the Hue side. (like eg the Tradfri system does)

To stress the importance of this issue, we could however all hop over on the Hue developers forum and support @balloob’s call for a push API on the HUE system: https://developers.meethue.com/forum/t/2018-and-2019-hue-api-and-sdk-features/5996/21

I am having this issue also. I don’t think it is related to interference by WiFi, wouldn’t that make the lights unavailable on all platforms? I have eero’s mesh wifi and you can’t select channel in the config so I can’t really test that. My hue lights work perfectly with Amazon Echo, They work perfectly with the App and they work perfectly with two Flic Button Hubs I have on my system. Only HA has them bouncing between unavailable and active. I have two lights which are the worst and I have them automated to turn on when I arrive home and when a zigbee button is pressed to toggle. One or the other fails almost all the time. It’s rare that both are online at the same time.
I am on 0.81.0 but see no reason to upgrade for this issue since people are reporting same problem with 0.86.3 which is the current version as of this post.

Yeah, there seem to be two common causes of “unavailable”, but often people get them confused.

One possible common cause, is wifi/channel/network related, this will affect all apps, controllers, etc

The issue that this thread is trying to resolve is why HA is marking some lights as unavailable even when they seem to be available to other systems.

I will say that there has been a lot of back and forth, and no resolution. For me and many others my lights go unavailable one or two at a time for a minute or so, throughout the day. But 95% of the time it does not affect me as I dont turn my lights off and on every 5 minutes, etc. For people who have the hub going off line, or all lgihts going offline for a long period of time, you are probably dealing with the 1st issue.

Mine are offline much more often. Checking right now. Two are offline

stairs_top and stairs_bottom are offline every morning which is when I use them. I no longer expect them to work at all.

A few seconds later now 4 are offline

I pretty much can’t control Hue with HA anymore.

few seconds later and different 4 offline now.

Few seconds later different set again (still 4 offline).

Basically 2-4 of my 12 Hue lights are offline at any given moment.
I can just watch this panel and they rotate around continuously. I never see them all online.

I cannot say for sure, but to me it does sound like a wifi/channel/HA/network issue. Most of my issues (and several others like me), are an occasional drop out of a bulb at a time. During a normal day, even in the middle of the night when nothing is going on, I’ll see a light or two go unavailable, and then back available in the next minute.

Are you running on a RPI? Do you have a lot going on? One of the comments above seemed to point to the HA server being too busy to verify connectivity to the hue entities

This is the one I suspect. I am running on RPI but I have nothing else running on this RPI. I have MQTT on it’s own PI, I have several other RPI’s about doing various choirs.

I just tried disabling the recorder, I do have mysql running on this RPI so maybe that is an issue. I will disable the mySQL server and see if that helps. I am using an external drive NOT SD card so performance is pretty good on this RPI which is a 3b+

On a side note I found that my recorder has never purged. Documentation says default is to keep 10 days worth and purge every day. I have found 505,858 events in the DB with a min created date of Sept 6 up until today. Can I just delete all the data in each table to manually purge?

I still say if it was WiFi interference my other methods of connection would be failing. Alexa is 100% never fails.

UPDATE: disabled mysql cpu at 3% max lights still bouncing offline/online in HA only.

I have had the bouncing happen with my Hue lights at times, just in HA and nowhere else. I have found that rebooting my Pi - not just restarting HA - often makes the problem go away. I’m using HassOS/Hass.io on a RPi 3B. Even though everything looks fine on the Pi in regards to cpu usage, memory usage, etc, rebooting the host makes a real difference.

HA on my Pi had been running great on the last release of 0.82 for quite some time. I don’t like to get too far behind, so this weekend I upgraded HA version by version to 0.85.1 and started seeing those Hue unavailable errors again. I rebooted the Pi and it’s been running beautifully ever since, no Hue errors at all. I’m sure this won’t solve everyone’s problems, but maybe it will help someone.

@ptdalen et all,

Please allow me to add to you analysis of 2 reasons. I think there are 3 :wink:

1- interference with other wireless topologies. Can’t say I’ve been hampered by that, but some are, and solutions have been suggested. Even Hue has that builtin their app, changing to another Zigbee channel could solve that, as does changing router channels.

2- Don’t forget Hue lights due really turn unavailable sometimes. I see that happening too, but, that is on an individual light basis, and doesn’t cause the Hue hub to go unavailable. In fact, it should show the lights unavailable, because they are.

3- The main issue.Tthis is the most unclear and most frustrating reason, and has been so for almost a year now… Still not solved.
It seems to boil down to I/O happening in your system, which causes the Hue Hub to go unavailable and hence show all lights unavailable. Why only the Hue integration suffers from that is beyond me or even the dev’s for that matter, because no answers are given when asked. Seems to also have to do with the fact HA needs to poll the Hue, versus components changes pushed.

Solution for now:
My Mqtt broker (which I had on my main system) is one of those I/O troublemakers, so I moved that to another RPi. Ive had my share of binary_sensors, deleted these, and that gave some relieve. Bluetooth is another known factor. If you only check the startup log, and see how long it takes for that component to setup, alarm bells should ring. Taken that out too. (Maybe better filed under 2… still seems a HA heavy I/O thing)

All in all, I now have 2 systems: a HA Mqtt ‘hub’, with bluetooth and some other administrative things, and my main system, that subscribes to the mqtt topics I need (my Mqtt broker receives many more topics, that are now not overflowing the main systems statemachine.

Only times when my main system is showing unavailable now, is when I do some system checking, or reloading/freshing Lovelace. Regular Ha seems steadier than ever.

I can now wake up and see my lights having a last_changed of over 6 hours :wink: While on the Mqtt system last_changed of over more than half an hour is a rarity.

As a side note: if individual lights show unavailable, try switching the group, and see the lights toggle… show the lights are reachable and HA incorrectly states they aren’t.

Hope this helps.
cheers.

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?