I only have hue lights. A combination of color bulbs, white bulbs and strips
I did want to report that I still got a unavailable warning after changing the value to 30. I’ll see if the amount of warnings are less though
I still see unavailable even after setting to 30.
fwiw, Ive updated to 0.81.2 on Hassos system, and things have gotten much worse. Stripped down the full system, but still the Hue got disconnected and lights stopped showing completely: see my followup on the GitHub: https://github.com/home-assistant/home-assistant/issues/16689#issuecomment-435296969
Right now, I’ve reenabled all and only stopped the builtin Mosquitto broker (which is very important i the setup, so no permanent solution), and the lights stay in the frontend much longer. Had a hiccup alright but the lights remain connected for now.
So, if you all have MQTT in the setup, please see what happens if you disable it for testing purposes.
I was having the same problem!
It started to happen after I installed MotionEye add-on, which is quite processor hungry.
When I turn off the add-on things go back to normally working.
Hope it will help solving the issue!
I ran Trådfri, Lightify and Hue bulbs on the Hue hub and lots (all windows and doors, motion sensors etc) on the Xiaomi hub. When I ran into the “unavailale” issue I tried changing ZigBee channel on the Hue hub, but what worked for me was replacing the two different ZigBee hubs (Hue and Xiaomi) with a Conbee running deCONZ. No unavailable-issues since.
I just installed Hass.io today and I have the same problem. Here are the steps to reproduce my Hue problem.
- Open Hue android app.
- All lights show available.
- Open hassio.local in a tab on a different device
- Wait
- Hue android app shows more and more lights becoming unavailable.
All my lights are connected through the Philips Hue hub. Could aggressive polling by Hass.io be the cause?
@Mariusthvdb I’m running Hassio 0.81.6 on a Raspberry Pi 3B and I’m having similar troubles with Hue lights randomly going unreachable, errors of “Updating hue light took longer than the scheduled update interval 0:00:05”, and 'Unable to reach bridge". I’m trying to troubleshoot. I found another post of yours that showed me how to do the REST sensors to show if lights are available or not, so thanks for that! I’d love to know how you made the three sensors shown under “Philips Hue Hub” in this post. I’ve made one using my router as a device tracker, and I am about to do one with ping, but how did you do the other one? Thanks in advance for any help!
Device_tracker Ping and binary_sensor Ping
1 Like
Thank you very much!
…so after my Hue lights were often showing as unavailable I also started seeing quite a few of my TP-Link smart plugs as unavailable in HA too.
It seemed that over time more and more of them were showing as unavailable until I had the same problem with most of them (I have quite a few of them).
The ones that started showing as unavailable first were downstairs, and quite a distance from our router upstairs. So I found out an old router and set that up downstairs to boost/extend the wifi.
Since I did that (about 1½ weeks ago) none of the Hue lights or TP-Link smart plugs have shown as unavailable in HA.
So I’m wondering if anyone here could have a problem with their wifi signal being a little weak, and if it was worth them testing to see if boosting their wifi signal would help?
I am also seeing unavailable at the moment for some lights.
The light come and go.
I think it is an issue with HA, running 0.86.3 at the moment.
I can control the light without any problems from the hue app and also no problem with the control from Domoticz so i guess it is something in HA
anyone ever get something done? as mine is happening several times an hour now. sometimes every minute…
Hello, how did you do this please? as my lights are in a mess now… unavailable every few seconds…
you can go to the add-on section in Hassio menu and stop the add-on.
Ive developed on this, and use a second Rpi now which runs the Mqtt add-on (and sees the lights go unavailable all the time) but have the second Pi for my main system, and subscribe to the topics from the Mqtt Pi I need
thanks… ah I don’t use hassio and run mqtt on my main nuc but in a docker… I might stop it for a few hours and see what happens
Something has changed and I don’t think I did it. I’ve been logging my Hue and TP-Link unavailability for a few weeks. Consistently some Hues would go unavailable ~5 times a day and all the switches ~250 times a day - PITA. But in the last 24 hours - nothing - rock solid. The only change I’m aware of is the Node-Red add-on auto-updated to 1.2.6. Actually I might have updated the firmware on my Raspberry Pi too.
I’ve been able to calm down the unavailable of the lights quite well, until I recently added the custom-mini-graph-card to my setup, and added a few very simple graphs.
Apparently reading the history takes so much out of the processors power/resources it practically halts the system, and voila, shows the lights as unavailable. posted about that here, for reference have a look.
I have never been able to really use history or logbook for that matter, and this proves again that is a truly unreliable service in HA.
so, if you experience lights going unavailable please check if you have services using history of entities?
1 Like
Interesting data point. I do use history and logbook, but only for things that change with automations or manually, such as lights, switches, locks, open close, motion sensors, etc. No Sensors like temp, times, etc. I’m also running on an older I3 computer with a SSD drive. I still have unavailable from time to time. Sometimes several lights an hour, and other times one light in 4-5 hours. But still definitely several times a day. I may try for a while not documenting any logbook or history (i rarely use them anyway), and see if that improves my hue experience
So I deleted my whole mysql database and I still have unavailable, but every few hours and not every few minutes now… thanks, good pointer… will look at this more tomorrow
please think with me here.
In my previous discussions with the HA founder I was pointed to components doing heavy I/O, causing stress to the system. They would be the cause for the Hue system going unavailable, and hence my separation of the Mqtt setup on a dedicated Pi.
Secondly, heavy frontend manipulations would be cause for further trouble. Since I use a lot of custom-ui templating I’ve been testing that, but couldn’t really point out a significant improvement. Still, using custom-ui with its javascript is all in browser, while using regular jinja templating is done in the server side, and would be better for performance.
Now my suspicion: slowly setting up my Lovelace interface, I am experiencing system slowdowns and yes, Hue unavailable errors more and more. Could it be that Lovelace is heavier in the frontend then one would want? My fans are going crazy now and then when my weather page is loaded, using 3 custom cards (with and without Lit) and some builtin weather cards, alongside history-graph.
All of these take their toll apparently, and, is doesn’t really seem to matter if they are in 1 view, or spread over more views…
would be interested in what you think, and experience on that matter.
thx!