All my hue lights randomly becoming unavailable

again, the ping results won’t help here. Still, to compare:

~ $ ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=63 time=0.622 ms
64 bytes from seq=1 ttl=63 time=0.531 ms
64 bytes from seq=2 ttl=63 time=0.560 ms
64 bytes from seq=3 ttl=63 time=0.497 ms
64 bytes from seq=4 ttl=63 time=0.418 ms
64 bytes from seq=5 ttl=63 time=0.510 ms
64 bytes from seq=6 ttl=63 time=0.478 ms
64 bytes from seq=7 ttl=63 time=0.508 ms
64 bytes from seq=8 ttl=63 time=0.454 ms
64 bytes from seq=9 ttl=63 time=0.710 ms
64 bytes from seq=10 ttl=63 time=0.526 ms
64 bytes from seq=11 ttl=63 time=0.536 ms
64 bytes from seq=12 ttl=63 time=0.506 ms
64 bytes from seq=13 ttl=63 time=0.481 ms
64 bytes from seq=14 ttl=63 time=0.456 ms
64 bytes from seq=15 ttl=63 time=0.454 ms

and this is what’s registered on the Hub:

Add the hue debug setting and check for +5 seconds events. If not, all is well, but these are the moments all Hue go unavailable.

I mean, you know how it goes - You add little things here and there and then one random day your wife shouts from another room “Alexa won’t turn the Family Room lights off!”

Good starting list - Thank you! I was just going through one of my old RPi2 configuration.yaml files and found that I had a bunch of things excluded from recorder and logbook, so I’ll start there and then expand to what you’ve shared if the problem doesn’t go away.

You may have misunderstood my suggestion. Use ping to check connectivity when the devices are reported to be unavailable.

Pinging when they are all available is not likely to reveal much unless response times are unusually long even under normal circumstances (unlikely). I only posted my results for comparative “normal” conditions. As mentioned, I’ve never experienced the unavailable situation so I can’t provide ping times for that condition.

Anyway, if you say it’s a glitch with the integration then so be it.

@roddie, check this How to reduce your database size and extend the life of your SD card by @tom_l for detailed info on settings for recorder, logbook and history (which I forgot all about…)

Thanks, @Mariusthvdb! This is excellent. I went through an exercise like this when I was still on my RPi2, but I didn’t bother when I rebuilt on an RPi3 or migrated to the Mini PC.

That said, I’m thinking it might be related to the Integration itself because that’s really the only thing that I can think of that changed between stable and my wife yelling at me. I’ve removed the integration and gone back to the manual entry in my YAML file.

I’ll keep working at it and let everyone know what I come up with

So, an update - I removed the Hue integration and went back to the manual YAML method:

    - host: 10.x.x.202

For whatever reason, HA didn’t see the hub/lights at all anymore - IIRC, I had to manually trigger a discovery when I had it configured this way before, but I was short on time, so I didn’t bother trying to troubleshoot for very long.

I added the Hue integration back while leaving the YAML in-tact, and I’ve had only a fraction of the “unavailable” messages in my Logbook since, and only with one bulb. Prior to this, I was getting them a lot more often with all of my bulbs.

It could just be a coincidence, and I’ll keep monitoring, but so far, so good.

I do have exactly the same issues since the last update. All 1-2 minutes hue lights go to off/unavailable in the log. No changes on the config - it worked for years before. Any real fix/solution? Sounds like try and error approach so far?

I see in the log file:
Timeout fetching sensor data
Logger: homeassistant.components.hue.sensor_base
Source: helpers/
Integration: Philips Hue (documentation, issues)
First occurred: July 17, 2020, 11:21:47 AM (46 occurrences)
Last logged: 7:07:23 AM


Timeout fetching light data
Timeout fetching group data

Log Details (ERROR)

Logger: homeassistant.components.hue.light
Source: helpers/
Integration: Philips Hue (documentation, issues)
First occurred: July 16, 2020, 9:03:50 PM (99 occurrences)
Last logged: 7:25:14 AM

My log file is showing three different errors in fact. I wonder if all of them are coming from different issues that people may be having here:

  • Request failed 3 times, giving up (x114),
  • Timeout fetching group data (x38),
  • Timeout fetching sensor data (x19).

I have made sure that my bridge has a fixed IP. Zigbee is operating on channel 11 and WiFi, I think, on Channel 6, so there should be no interference(?). Other than running a little low on ideas.

I may have made some progress with my issue. I have been pinging continuously every 2s my pi based HA server from another pi. Both are connected to the same stock Virgin router. Every other minute, I can see host becoming unreachable:

Mon 10 Aug 08:22:58 BST 2020: 64 bytes from icmp_seq=405 ttl=64 time=0.475 ms
Mon 10 Aug 08:23:00 BST 2020: 64 bytes from icmp_seq=406 ttl=64 time=0.624 ms
Mon 10 Aug 08:23:13 BST 2020: From icmp_seq=411 Destination Host Unreachable
Mon 10 Aug 08:23:13 BST 2020: From icmp_seq=412 Destination Host Unreachable
Mon 10 Aug 08:23:17 BST 2020: From icmp_seq=413 Destination Host Unreachable
Mon 10 Aug 08:23:17 BST 2020: From icmp_seq=414 Destination Host Unreachable
Mon 10 Aug 08:23:22 BST 2020: From icmp_seq=415 Destination Host Unreachable
Mon 10 Aug 08:23:22 BST 2020: From icmp_seq=416 Destination Host Unreachable
Mon 10 Aug 08:23:25 BST 2020: 64 bytes from icmp_seq=417 ttl=64 time=2079 ms
Mon 10 Aug 08:23:25 BST 2020: 64 bytes from icmp_seq=418 ttl=64 time=0.648 ms

and when I refresh the logbook in HA these are clearly correlated with my bridge going down. So this is looking now like a network connectivity on the server side.

I am trying to evaluate whether this is happening because of the router or because of my Pi4.

This is an old thread, but I’m wondering if anyone has found any resolution to this. I am encountering this issue now. It might be totally unrelated, but it seems to have started when I started hitting the bridge pretty hard with Halloween automations that quickly and repeatedly change 4 different lights to different colors. Maybe the bridge is just “getting tired” and not working as well as it did previously?

I’m still having the issue here - I thought I’d resolved it by configuring Hue support directly in configuration.yaml, but it’s still misbehaving.