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!
I am with you regarding Lovelace… it is VERY client CPU heavy. My laptop fan goes into over drive even on my home page which so far has 2 photo/trackers and a static camera all in test.
Like I have said previously… I am running on a celron intel nuc, so not an rpi… I have a spare i5 PC but don’t want to use it as it costs a lot more to tun than a nuc!
Lovelace should have nothing to do with it. If so then the unavailables would only show up during times of user interaction. My graph is littered with the unavailable message at times when a) no one is home and b) no one is awake and c) no one is using the front end.
1 Like
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.
1 Like
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+…
1 Like