Core: Hue unable to reach bridge

Created on 10 May 2019  Â·  91Comments  Â·  Source: home-assistant/core

Home Assistant release with the issue:
0.92.2

Last working Home Assistant release (if known):
Unknown

Operating environment (Hass.io/Docker/Windows/etc.):
Running Docker on Synology Nas DS718+

Component/platform:
https://www.home-assistant.io/components/hue/

Description of problem:
Losing connection with the Hue bridge

Traceback (if applicable):
Short version below, full version

2019-05-07 03:02:19 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-07 04:29:58 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-07 05:00:25 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-07 21:29:02 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-08 03:02:31 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-08 03:15:34 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-08 03:28:57 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-08 03:58:03 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-08 04:19:29 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-08 04:49:40 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-09 03:02:32 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-09 03:20:41 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-09 03:39:03 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-09 04:12:09 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-09 05:08:20 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-09 16:38:05 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-09 20:38:51 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-10 03:02:01 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-10 03:12:54 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-10 03:16:13 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-10 04:01:27 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-10 04:29:25 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()
2019-05-10 05:03:02 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.5 ()
2019-05-10 05:28:03 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.178.5 ()

Additional information:
Hue bridge V2, firmware 1931140050.

Currently using:

  • 20x GU10 Ambiance White
  • 2x E27 Color
  • 1x E14 Ambiance White
  • 3x Niko FOU wall switches
  • 1x Hue Dimmer switch
hue

Most helpful comment

We have merged a fix that should limit the parallel requests that we make to Hue, which could fix this.

All 91 comments

Hey there @balloob, mind taking a look at this issue as its been labeled with a integration (hue) you are listed as a codeowner for? Thanks!

_This is a automatic comment generated by codeowners-mention to help ensure issues and pull requests are seen by the right people._

Had the same issue here, but with both of my hue hubs (emulated hue).

2019-05-30 17:43:07 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.87
2019-05-30 17:44:03 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.143

So the only recent change that I made was that I was prepping my config to use !secrets all over the place. I was super paranoid, so I also did the IPs of my devices, including my hue hubs.
After removing the !secrets entry for the IP addresses, I'm no longer seeing the error. Perhaps you have an extra space or something?

Any chance that around that time you were controlling the lights?

I get these all the time. Guaranteed one on every HA restart:

2019-05-31 09:53:41 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for alexa_media which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-05-31 09:53:42 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for sun which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-05-31 09:53:42 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for custom_updater which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-05-31 09:53:50 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.0.9

It's not related to use.
This morning, just before a restart, I had dozens in there. If there's something more useful I can contribute to this thread, please advise.
(Hassbian, 0.93.1)

Like with the app or Alexa? I don't believe so. Alexa mainly uses the emulated hue so that I can switch on/off groups and automations via HASS. I'm the only one in my family that uses the Hue app from time to time. I do have node-red set up and connected to emulated hue commands.
Saw this in my log this afternoon after I restarted my box and started up the docker for HA.

019-05-31 12:01:37 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.87
2019-05-31 12:01:48 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.143

Looks like the secrets wasn't the issue...
Weird thing is, I'm seeing the lights as connected and showing status. I was also able to turn off the lights just fine. So perhaps it had initial issues connecting and then recovered - its just not reporting it in the log. I think I'm probably not experiencing the same issue as @sjorsjes then. My apologies.

I've started having a lot of trouble with this on restarts as well. Not every restart, but every few restarts my Hue bridge won't connect and none of my lights will show up. I'm currently running 0.93.2 on Hassio on an RPi 3 to provide an additional data point on this issue.

I'm also having problem with hue. It takes several restarts for the lights to show up. Weird the enough, my hue motion sensor works flawless every time. Maybe these logs help:

2019-06-12 20:15:20 DEBUG (MainThread) [homeassistant.components.hue.light] Failed to fetch group: 
2019-06-12 20:15:20 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.178.26 ()
2019-06-12 20:15:20 DEBUG (MainThread) [homeassistant.components.hue.light] Finished group request in 4.173 seconds
2019-06-12 20:15:20 DEBUG (MainThread) [homeassistant.components.hue.light] Failed to fetch light: 
2019-06-12 20:15:20 DEBUG (MainThread) [homeassistant.components.hue.light] Finished light request in 4.181 seconds
2019-06-12 20:15:21 INFO (MainThread) [homeassistant.components.hue.sensor_base] Starting sensor polling loop with 5.0 second interval
2019-06-12 20:15:21 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.230 seconds
2019-06-12 20:15:21 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.178.26
2019-06-12 20:16:02 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 3.061 seconds
2019-06-12 20:16:08 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.136 seconds
2019-06-12 20:16:14 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.047 seconds
2019-06-12 20:16:20 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.073 seconds
2019-06-12 20:16:26 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.047 seconds
2019-06-12 20:16:32 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.064 seconds
2019-06-12 20:16:38 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.053 seconds
2019-06-12 20:16:44 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.053 seconds
2019-06-12 20:16:50 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.059 seconds
2019-06-12 20:16:56 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.040 seconds
2019-06-12 20:17:02 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.050 seconds
2019-06-12 20:17:08 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.035 seconds
2019-06-12 20:17:14 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.091 seconds

same problem here, after every restart....
Need to pair it again always after every restart.

I didn't have this issue at all until I enabled HTTPS on Home Assistant. When it was just HTTP everything was fine, but now that HTTPS is enabled this happens roughly 35% of the time after a reboot. I thought it was an issue with Discovery, but even with my configuration file pointing at the Hue I have it happen.

Here's a snippet of my log:

2019-06-15 19:41:27 INFO (MainThread) [homeassistant.components.light] Setting up light.hue
2019-06-15 19:41:27 INFO (MainThread) [homeassistant.components.notify] Setting up notify.mobile_app
2019-06-15 19:41:27 INFO (SyncWorker_4) [root] Making request to URL http://webservices.nextbus.com/service/publicJSONFeed?command=predictionsForMultiStops&stops=804%7C804090&a=lametro-rail
2019-06-15 19:41:27 INFO (SyncWorker_17) [homeassistant.loader] Loaded stream from homeassistant.components.stream
2019-06-15 19:41:27 INFO (SyncWorker_17) [homeassistant.loader] Loaded deconz from homeassistant.components.deconz
2019-06-15 19:41:31 WARNING (MainThread) [homeassistant.components.binary_sensor] Setup of platform ring is taking over 10 seconds.
2019-06-15 19:41:31 WARNING (MainThread) [homeassistant.components.sensor] Setup of platform ring is taking over 10 seconds.
2019-06-15 19:41:31 INFO (SyncWorker_10) [root] Making request to URL http://webservices.nextbus.com/service/publicJSONFeed?command=predictionsForMultiStops&stops=804%7C804181&a=lametro-rail
2019-06-15 19:41:31 INFO (MainThread) [homeassistant.setup] Setup of domain climate took 16.9 seconds.
2019-06-15 19:41:31 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.86.21 ()
2019-06-15 19:41:32 INFO (MainThread) [homeassistant.setup] Setting up stream
2019-06-15 19:41:32 INFO (MainThread) [homeassistant.setup] Setup of domain stream took 0.0 seconds.
2019-06-15 19:41:32 WARNING (MainThread) [homeassistant.components.sensor] Setup of platform yr is taking over 10 seconds.
2019-06-15 19:41:32 INFO (MainThread) [homeassistant.setup] Setup of domain default_config took 5.6 seconds.
2019-06-15 19:41:32 WARNING (MainThread) [homeassistant.components.sensor] Setup of platform plex_recently_added is taking over 10 seconds.
2019-06-15 19:41:33 INFO (MainThread) [homeassistant.setup] Setup of domain binary_sensor took 20.4 seconds.
2019-06-15 19:41:33 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.hue
2019-06-15 19:41:33 INFO (MainThread) [homeassistant.setup] Setup of domain device_tracker took 13.2 seconds.
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.setup] Setup of domain sensor took 17.1 seconds.
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.hue
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.hue.sensor_base] Starting sensor polling loop with 5.0 second interval
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.googlehome
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.googlehome
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.googlehome
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.breaking_changes
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.hacs
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.setup] Setting up camera
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.camera] Setting up camera.ring
2019-06-15 19:41:38 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.86.21

Note that even though it says it was able to reconnect to the bridge, I still see "entity unavailable" next to all Hue lights on the frontend.

This looks suspiciously like this one:
https://github.com/home-assistant/home-assistant/issues/16689

updated today to 94.3 and this is at the end of the startup in the log:

2019-06-18 23:33:39 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /discovery request
2019-06-18 23:33:39 ERROR (MainThread) [homeassistant.components.hassio.discovery] Can't read discover info: 
2019-06-18 23:33:42 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.1.212 ()

filed an issue about the hassio discovery failure a looong time ago, never received a response. Hue bridge keeps bothering us unfortunately, though it seems to behave much better and doesn't display the unavailabe lights as it did before

I'm seeing this constantly after every restart now. (0.95.4) This makes the hue integration completely unusable :(

Agreed. I just transitioned all of my hue lights over to zha due to the errors and removed the hue integration.

Hi, I have since 0.95.x the issue:
Error connecting to the Hue bridge at xxx.xxx.xxx.xx
Appears several times a day increasing.

I've experienced these constantly since starting with HA 7-mo ago.
Here is my log for the past 16hrs.

2019-07-01 16:31:21 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-01 17:44:02 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-01 18:55:08 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-01 19:10:15 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-01 22:50:16 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-01 23:13:17 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-01 23:36:36 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-02 04:59:33 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-02 07:12:15 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-02 07:13:14 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-02 09:31:28 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-02 11:46:58 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-03 01:31:08 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-03 04:32:06 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-03 05:13:14 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 ()
2019-07-03 05:18:56 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-03 08:10:54 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)

Any troubleshooting suggestions would be gladly accepted! Tnx

This is unfortunately something I'm continuing to see -- I may see it at restart, but I definitely see it over the course of the week. Hue hub is v2 and is plugged into a 16-Port Ubuquiti PoE switch.

Anecdotally this seems to happen only when HA is polling (though I have no data to prove that - I'm going to set up some monitoring in the next week or so and remove the integration in HA and see how I fare).

Master-Bedroom-07Jul2019

Shouldn't be a real surprise but of course all those "unavailables" in the logbook correspond to when I can't contact the bridge...

2019-07-07 03:59:24 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.2.248 (Error requesting data from 192.168.2.248: Cannot connect to host 192.168.2.248:80 ssl:None [Connection refused])
2019-07-07 04:00:23 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 192.168.2.248
2019-07-07 04:34:02 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.2.248 (Error requesting data from 192.168.2.248: [Errno 104] Connection reset by peer)
2019-07-07 04:34:59 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 05:17:37 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 (Error requesting data from 192.168.2.248: Cannot connect to host 192.168.2.248:80 ssl:None [Connection refused])
2019-07-07 05:18:34 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 06:04:30 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.2.248 ()
2019-07-07 06:05:23 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 07:00:11 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 (Error requesting data from 192.168.2.248: Cannot connect to host 192.168.2.248:80 ssl:None [Connection refused])
2019-07-07 07:01:09 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 192.168.2.248
2019-07-07 07:56:33 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 (Error requesting data from 192.168.2.248: Cannot connect to host 192.168.2.248:80 ssl:None [Connection refused])
2019-07-07 07:57:30 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 192.168.2.248
2019-07-07 08:26:53 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 ()
2019-07-07 08:27:45 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 09:26:01 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 ()
2019-07-07 09:26:52 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 09:57:08 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 ()
2019-07-07 09:58:02 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 10:45:30 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.2.248 (Error requesting data from 192.168.2.248: Cannot connect to host 192.168.2.248:80 ssl:None [Connection refused])
2019-07-07 10:46:28 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 10:50:33 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.2.248 ()
2019-07-07 10:51:02 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.2.248
2019-07-07 10:51:32 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.2.248 ()
2019-07-07 10:51:38 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 192.168.2.248

I'm having trouble with this since 0.95.x. The message [homeassistant.components.hue.light] Unable to reach bridge continues to rise every time I restart Home Assistant. Strangely the Hue component works fine when I enable the logger component in the Home Assistant configuration (without any parameters for the logger component).

Hue bridge V2, BSB002 1932126170. Bridge is on the same local subnet. Home Assistant 0.95.4.

2019-07-15 12:30:10 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 10.0.0.53 (Error requesting data from 10.0.0.53: [Errno 104] Connection reset by peer)
2019-07-15 12:30:10 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 10.0.0.53
2019-07-15 12:38:12 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 10.0.0.53 (Error requesting data from 10.0.0.53: [Errno 104] Connection reset by peer)
2019-07-15 12:38:12 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 10.0.0.53
2019-07-15 12:42:13 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 10.0.0.53 (Error requesting data from 10.0.0.53: [Errno 104] Connection reset by peer)
2019-07-15 12:42:13 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 10.0.0.53
2019-07-15 12:46:13 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 10.0.0.53 (Invalid content type: text/html)
2019-07-15 12:46:13 INFO (MainThread) [homeassistant.components.hue.light] Reconnected to bridge 10.0.0.53

After re-adding the hue component through the default home assistant integration (completely removed hue component configuration and integration first) my hue setup works as intended. No more error messages of home assistant being unable to reach the bridge (for two days now). I'm on home assistant 0.95.4.

After re-adding the hue component through the default home assistant integration (completely removed hue component configuration and integration first) my hue setup works as intended. No more error messages of home assistant being unable to reach the bridge (for two days now). I'm on home assistant 0.95.4.

Is the steps like this?

  1. Home Assistant > Configuration > Integrations > Philips Hue Bridge > Delete (paper bin icon)
  2. Restart Home Assistant
  3. Setup Philips Hue again from Home Assistant integratione page

Is the steps like this?

  1. Home Assistant > Configuration > Integrations > Philips Hue Bridge > Delete (paper bin icon)
  2. Restart Home Assistant
  3. Setup Philips Hue again from Home Assistant integratione page

Yes, these are the steps I went through. I did have a small section on hue in my configuration.yaml which I used prior to the introduction of the hue integration. I removed this part of the configuration at step 1:

hue:
  bridges:
    - host: ***

I’ve updated to 0.96.2 and followed the steps @marcvanderhaar described.
So far it has been running for 24+ hours without any hue errors. I did got a single ‘hue took longer then expected’ but that didn’t gave any problems.

I also performed these steps and have seen a significant reduction during the past 20 hours:

System started: 2019-07-20 15:43:17

2019-07-20 17:45:26 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-20 17:52:16 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 ()
2019-07-20 21:55:22 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-20 22:16:15 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-20 23:52:05 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-21 00:13:58 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-21 01:26:35 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-21 01:28:46 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-21 09:01:17 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: None)
2019-07-21 10:18:47 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)
2019-07-21 11:19:32 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 192.168.0.9 (Error requesting data from 192.168.0.9: [Errno 104] Connection reset by peer)

The last week the issues seems to (temporary?) dissapeared. I have since updated to 0.96.3 and upgraded bridge to 1933087030. Not sure what fixed it. I have not reconfigured according to the above steps or anything similiar.

I have the same hue version but keep still 0.95.4. Had no errors since a couple of days as I remember

I'm running 95.4, I did as recommended. I removed my hue, removed entries in my configuation.yaml. I am still getting fairly regular unavailable for my hue lights. I even changed the channel a few times. Usually happens a few times and hour on one or two lights at a time.

Agreed. I just transitioned all of my hue lights over to zha due to the errors and removed the hue integration.

I'm having many issues after restarts where the hue Lights are unavailable. The tap switches and motion sensors rarely have that issue.

How has ZHA worked for you so far? I'm in the process of building zigbee2mqtt.

I ended up moving my 13 bulbs and strips and two hue remotes over to my ZHA controller, I removed the hue intergration and have turned off my hue hub. I removed the Hue integration from my Amazon Echo as well, and added the ZHA lights into my alexa config. Renamed all the lights to the same name as they were before, so I did not have to update any automations, scripts, etc.

It's only been a few days, but no "unavailbles", Now I just want to keep an eye on the lights to make sure they continue to turn on/off when they should. So far it's been 100% successful

had a few changes in the setup lately that might have led to the current, stable(!) situation.

Most notable one might very well be the commenting out of the asuswrt: integration. Though my second system was much stabler than the one constantly losing connection,(and that too used Asuswrt:) it seems to have made a difference for the reliability of the HUE integration.

I do still see the

2019-08-07 15:23:45 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.212

during startup, and every once in a while during regular operation, but the lights remain in the frontend, and my constant 'unavailable' lights are a thing of the past.

I still use the regular Hue integration, including the new sensors, and still use the custom component.

only thing bugging me, not always, but still, on a regular base, is that upon restart the lights aren't seen. This seems to coincide with active config of other components, like the breaking_changes or platform: authenticated. Not a 100% match, but when I load these, Hue has issues at startup. They probably poll the processor one system in a way, causing (timing) issues for the Hue integration to properly initialize?

All in all I hope this progress is here to stay, and hope the other log errors can be solved in the future somehow.

Interesting. I do use the asuswrt intergration as well. I'm going to keep on zha for now so I can determine if it is stable as it seems, and also I want to see what I lose. I almost never used the hue apps, but there were a couple that I used once in a while to show off the colored lights, that wont work without the hub/hue. I'll have to see if I can do similiar colorloop, etc with HA

maybe a silly question, but since the unavailable errors are directly related to the hub not being seen, wouldn't it be rather unexpected to keep seeing the errors after deleting the integration and the hub?
I probably don't understand what you've done exactly, but the challenge to me seems to eradicate the errors with the hub and integration in place ;-)

@ptdalen Out of curiosity, what hardware are you running HA on? I've considered moving my Hue bulbs off the bridge and to ZHA as well, but I'm running on an RPi 3 and am a little concerned about whether the performance will be up to par.

I am running on an older PC with a HUSBZB-1 USB controller. The reason I thought there was a chance that I might see unavailable is because I was never 100% sure what was really going on with the hue bulbs. I never had an error about the hub being unavailable, but I did have a bulb or two go unavailable every few minutes to every few hours. I agree that it was very, very likely that HA was not able to get the info it needed from the hue hub, but the proof that all is good will be that the lights turn on and off 100% of the time when they should. Whenever the bulbs showed unavailable to me, if I went into the HA app, and clicked on the bulb they would usually "wake up" right away.

I've tried via HomeAssistant GUI and the config YAML. My Hue always falls offline with home assistant. HA and Hue have a static IP. I'm using hasio with rasp pi 3. This seems to start happening after I upgraded. I don't know the exact version I was using before the upgrade but it was like 4-5 version behind and Hue was working just fine. Please fix this is super frustrating.

This might be related to the zigbee communication of the hue. I have had hue lights for 2 years before even hearing of home assistant and having lights go unavailable is a nearly daily occurrence. The controller runs over Ethernet or Wi-Fi with response times in the ms to us range. But then it hops light to light in an ad-hoc fashion that generally gives a latency of a few S. But not always.

I’ve had lights mere meters from the Phillips hub go unavailable. And in truth it generally seems like certain lights are worse than others. I’ve RMAed lights with Phillips in the past for this. But I think it maybe has more to do with the fixtures sometimes (recessed are especially prone).

Perhaps updating the code to be more fault tolerant - allowing it to silently retry in the background. I do also wonder if the hue hub (which we are dependent on for sending the -proprietary- zigbee signal) is responsible for setting them unavailable a bit too lazily)

This might be related to the zigbee communication of the hue. I have had hue lights for 2 years _before_ even hearing of home assistant and having lights go unavailable is a nearly daily occurrence. The controller runs over Ethernet or Wi-Fi with response times in the ms to us range. But then it hops light to light in an ad-hoc fashion that generally gives a latency of a few S. But not always.

I’ve had lights mere meters from the Phillips hub go unavailable. And in truth it generally seems like certain lights are worse than others. I’ve RMAed lights with Phillips in the past for this. But I think it maybe has more to do with the fixtures sometimes (recessed are especially prone).

Perhaps updating the code to be more fault tolerant - allowing it to silently retry in the background. I do also wonder if the hue hub (which we are dependent on for sending the -proprietary- zigbee signal) is responsible for setting them unavailable a bit too lazily)

I'm surprised to hear this I have been using Philips hue separate from HomeAssistant for a year and have never had it drop lights. When it drops in HA I can go into Hue and the lights are still connected and working fine. If I go into HA and drop hue integration and re-add then everything works again. The lights only become unavailable after a reboot of HA. Seems like HA is unable to relink the hue or something.

+1.

I've also noticed that my Hue lights are not working.
My Hue bridge is generating the following error at each restart: Unable to reach bridge 172.16.xx.xx
The integration page shows that the Hue bridge (FW 1933144020) is connected but all devices are marked as unavailable.

I tried @marcvanderhaar's procedure unsuccessfully.

Encountering this _a lot_ lately too, it has been failing like 95% of the time over the past week or two. Not sure whether it was a change in 0.98 or just a coincidence. This is the behavior I am seeing:

  • When restarting, the Hue lights do not come back, but my Hue motion sensors connected to the same exact Hue bridge always work fine (I only have one Hue bridge btw and it's the 2nd Gen one).
  • The debug log for Hue says "Reconnected to bridge" even though the lights never become available. (Although perhaps that log item is referring to the Hue motion sensors).
  • Enabling or disabling discovery for Hue does not seem to make any difference.
  • Hue lights are still controllable everywhere _except_ Home Assistant. Inside the official Hue app, in Apple HomeKit app / Siri, Google Home, and Alexa.
  • This _only_ occurs on initial startup for me, it is very stable otherwise. The times where it does successfully connect on startup, it remains stable with no disconnects or anything. It's just that it has trouble making that initial connection, and then seems to either fail or perhaps not even try to reconnect.

Logs:

2019-08-29 20:02:17 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.154
2019-08-29 20:04:06 INFO (MainThread) [homeassistant.components.hue.sensor_base] Starting sensor polling loop with 5.0 second interval
2019-08-29 20:04:13 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Failed to fetch sensor: 
2019-08-29 20:04:13 ERROR (MainThread) [homeassistant.components.hue.sensor_base] Unable to reach bridge 192.168.1.154 ()
2019-08-29 20:04:13 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 7.231 seconds
2019-08-29 20:04:13 DEBUG (MainThread) [homeassistant.components.hue.light] Failed to fetch group: 
2019-08-29 20:04:13 DEBUG (MainThread) [homeassistant.components.hue.light] Finished group request in 7.174 seconds
2019-08-29 20:04:13 DEBUG (MainThread) [homeassistant.components.hue.light] Failed to fetch light: 
2019-08-29 20:04:13 DEBUG (MainThread) [homeassistant.components.hue.light] Finished light request in 7.254 seconds
2019-08-29 20:04:28 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Failed to fetch sensor: 
2019-08-29 20:04:28 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 5.084 seconds
2019-08-29 20:04:37 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 2.973 seconds
2019-08-29 20:04:37 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 192.168.1.154
2019-08-29 20:04:45 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.671 seconds
2019-08-29 20:04:51 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.104 seconds
2019-08-29 20:04:58 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 1.718 seconds
2019-08-29 20:05:04 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.423 seconds
2019-08-29 20:05:10 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.107 seconds
2019-08-29 20:05:16 DEBUG (MainThread) [homeassistant.components.hue.sensor_base] Finished sensor request in 0.032 seconds

Like some others here, I am using an RPI 3B+ and both that and my Hue bridge have a static IP.

I have over 1,000 entities in my HA setup so I understand that restarts are probably taxing for the hardware and that might be why it fails / times out on the initial Hue connection. But I suspect it could maybe be more aggressive about trying to reconnect.

Just upgraded to .98 and immediately started having exact same issues. I'm on docker on RPI 3B+. Never had a problem before upgrade.

This might be related to the zigbee communication of the hue. I have had hue lights for 2 years _before_ even hearing of home assistant and having lights go unavailable is a nearly daily occurrence. The controller runs over Ethernet or Wi-Fi with response times in the ms to us range. But then it hops light to light in an ad-hoc fashion that generally gives a latency of a few S. But not always.

I’ve had lights mere meters from the Phillips hub go unavailable. And in truth it generally seems like certain lights are worse than others. I’ve RMAed lights with Phillips in the past for this. But I think it maybe has more to do with the fixtures sometimes (recessed are especially prone).

Perhaps updating the code to be more fault tolerant - allowing it to silently retry in the background. I do also wonder if the hue hub (which we are dependent on for sending the -proprietary- zigbee signal) is responsible for setting them unavailable a bit too lazily)

While I do not think interference is the root cause of this issue's topic, I wanted to shed some light on what you said. A few years ago I had a lot of issues with Philips Hue bulbs dropping (independent of Home Assistant), and simply misaligning my WiFi and Zigbee channels did the trick. After that, everything worked flawlessly 100% of the time. Again: I do not think that this is related to the main issue described by OP and many others here.

Check your WiFi and Zigbee channels against the chart here and see if they overlap at all: https://support.metageek.com/hc/en-us/articles/203845040-ZigBee-and-WiFi-Coexistence

And for what it's worth, I am having the "Unable to reach bridge" error show up every restart as well:

2019-08-30 10:50:38 INFO (MainThread) [homeassistant.setup] Setting up hue
2019-08-30 10:50:38 INFO (MainThread) [homeassistant.setup] Setup of domain hue took 0.0 seconds.
2019-08-30 10:50:50 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 172.16.0.102
2019-08-30 10:50:50 WARNING (MainThread) [homeassistant.config_entries] Config entry for hue not ready yet. Retrying in 5 seconds.
2019-08-30 10:50:50 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=hue>
2019-08-30 10:51:27 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=hue, service=hue_activate_scene>
2019-08-30 10:51:27 INFO (MainThread) [homeassistant.components.light] Setting up light.hue
2019-08-30 10:51:27 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.hue
2019-08-30 10:51:27 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.hue
2019-08-30 10:51:28 INFO (MainThread) [homeassistant.components.hue.sensor_base] Starting sensor polling loop with 5.0 second interval
2019-08-30 10:51:37 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 172.16.0.102 ()
2019-08-30 10:51:41 WARNING (MainThread) [homeassistant.components.light] Setup of platform hue is taking over 10 seconds.
2019-08-30 10:51:41 WARNING (MainThread) [homeassistant.components.sensor] Setup of platform hue is taking over 10 seconds.
2019-08-30 10:52:00 INFO (MainThread) [homeassistant.components.hue.sensor_base] Reconnected to bridge 172.16.0.102

System Health

... | ...
-- | --
arch | armv7l
dev | false
docker | true
hassio | true
os_name | Linux
python_version | 3.7.4
timezone | America/Chicago
version | 0.98.0
virtualenv | false

I have the same issue. I've traced it down to having this entry in my configuration.yaml:

hue:
  bridges:
    - host: 192.168.1.10
      allow_unreachable: true    <--   I want to use THIS

If I remove the entry (hue: and everything below it) the unable to connect to bridge error goes away, but then I'll get the annoying unavailable bulbs at random times. allow_unreachable: true fixes this for me, and most times I can still control the bulb that was otherwise saying unavailable.

This is a fairly recent problem as older versions of HA had no problem with the configuration.yaml entry.

I've suffered this issue on and off over probably the past year. I was stuck on 0.96 for some time and had no issues, in the past week I have upgraded to 0.98 and am starting to suffer again with HA sometimes failing to connect to the hub on startup. Simply restart HA again normally solves the issue. If i will get issues again with lights going unavailable I guess I will have to wait and see.

I seem to be getting it too - removing the integration and adding it back doesn't seem to fix the problem. Its looking like sometimes my hue lights are not showing up at all. Following this thread in the hope some solution is found.

I have had this error in my log every day but only 5-10 of them. Now I see more than 100 in a day and it has started making things fail.

Something went worse in recent Home Assistant updates. I have rebooted by router, the Hue Bridge, I have replaced the Ethernet cable, moved to another switch port etc.

My Hue bridge has a hardcoded fixed IP address so it is not DHCP related. Both the bridge and the HA machine (a NUC) are using cabled Ethernet to the same switch. Ping time is 0.3 ms between them

I then tried to start a ping in a command line window. And at the same time watching the HA log. And I do not get any timeouts on the ping while I get the errors in the HA log. So it is not basic networking. It is HA that does not get a reply from the bridge.

Maybe we are too aggresive at polling the bridge or something times out too fast?

Or is it a recent update to the Hue itself that has made is unreliable and not at all the fault of HA? I just wonder.

Something almost like API Request Flood Detection kicking in on the Hue
side?

I agree though. These last updates have not been good for me. I actually
had everything go offline and have just resolved to starting over with a
brand new server and see if these problems remain after a fresh build.

On Sat, Sep 7, 2019 at 2:09 PM Kenneth Lavrsen notifications@github.com
wrote:

I have had this error in my log every day but only 5-10 of them. Now I see
more than 100 in a day and it has started making things fail.

Something went worse in recent Home Assistant updates. I have rebooted by
router, the Hue Bridge, I have replaced the Ethernet cable, moved to
another switch port etc.

My Hue bridge has a hardcoded fixed IP address so it is not DHCP related.
Both the bridge and the HA machine (a NUC) are using cabled Ethernet to the
same switch. Ping time is 0.3 ms between them

I then tried to start a ping in a command line window. And at the same
time watching the HA log. And I do not get any timeouts on the ping while I
get the errors in the HA log. So it is not basic networking. It is HA that
does not get a reply from the bridge.

Maybe we are too aggresive at polling the bridge or something times out
too fast?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/23796?email_source=notifications&email_token=AEL4SXZ2KW475BJMA7IVB5TQIQJ7BA5CNFSM4HMBH6EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FCI6A#issuecomment-529147000,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEL4SX73A4PBMFTC466OUFLQIQJ7BANCNFSM4HMBH6EA
.

I have an update.
My particular problem has nothing to do with home assistant (out of reach every 10 minutes). The problems with Philips Hue being non responsive continued also with HA stopped and Hue reset.
I first concluded that my Hue hub was broken and removed all the lights and started putting lights on a new Hue hub that I bought. And that did not work well either. Then I found a device that was overloading my network with broadcast messages. While most things worked fine with that the Philips Hue hub did not.
At the end I decided that since I had removed all 35 lights anyway I might as way bite the bullet and move all to my already coexisting deconz as it has a much better API that does not need to be heavility polled.

So watch out with the conclusions. Some of you - not all of you - with Philips Hue connectivity issues may want to debug the network first as it seems it may be the Hue hub in some cases.

0.98.5
Have this issue 5 to 10 times a day
Error connecting to the Hue bridge at x.x.x.x
No hue entry in configuration so far but I would like to enter 'allow_unreachable: true' as I have some osram bulbs staying unavailable the whole time

We all have to watch out for randomness. You do something and you observe random behaviour and can easily conclude a false causality.
It would be good to experiment more with the "allow_unreachable" on and off to make sure it is not just the reset of HA that changes the behaviour and verify that you can change between true and false and see the problem come and go with a 100% verified causality

When HA cannot reach the Philips Hue hub at TCP/IP network level then it is either because HA does something wrong or because the Philips Hue box is busy/buggy and does not reply.

The "allow_unreachable" setting is not related to the link between HA and Hue. It is related to the link between Hue and the Zigbee devices. When you set 'allow_unreachable: true' you allow tell HA to ignore that Philips Hue hub reports lights unreachable and send rest messages to the Hue to tell lights to turn on and off anyway. This is very much needed because as you correctly say - Philips Hue almost always say that Osram devices are unreachable. But it works 99.9% of the time anyway.
Even in the official Philips apps you see the Osram devices unreachable and still you can turn them on and off and dimm them.
I really doubt the "allow_unreachable" has much to do with the ability to reach the bridge.
It could be that HA polls more often when items are unreachable so in theory it could have an effect.

But I can say that I have always run my old hue with "allow_unreachable: true" and I still had the 2-10 error messages logged - but without any negative effect - things still worked in practical life

It was when I had a network issue where some box started sending many broadcast messages I got visible problems but that has nothing to do with Home Assistant. It is interesting though to note that a Philips Hue hub can become unstable because of broadcast packages. Maybe the original defect reported here is a problem in the Philips Hue box and it may not be the HA software that causes the problem.

Sadly I still do not know what caused my problem. It went away and has not come back and I now no longer have a Philips Hue hub (changed to 100% Deconz) so I cannot contribute with any debugging.

0.98.5
Have issue 5-10 times a day
About 50% of the time I restart Home Assistant I have to "Delete" integration to HUE as it fails to connect and "re-pair" (Add Hue Hub on Integrations page). This doesn't seem to hurt anything and it keeps the entity names but its super annoying and started in the last 2-3 months (I upgrade to the .1 release every cycle)

I did log into my meethue account to see if there was any info there and I was surprised to see over 80 "pairings" both cloud and "local" to the hub. This dates back 3 years. The portal lets you deactivate them and even tells you the last time they were used. I will report back if this changes any of the behavior.

I really doubt the "allow_unreachable" has much to do with the ability to reach the bridge.

In theory I agree, but I also noticed a difference when allow_unreachable and allow_hue_groups were configured. I can't explain it though.

Like I mentioned earlier I have to leave the Hue entry completely OUT of configuration.yaml or HA won't connect to my bridge. What I used to use (and would like to still use)

hue:
  bridges:
    - host: 192.168.1.10
      allow_unreachable: true 

If there's another way to use allow_unreachable without the entry I'd love to hear it.

is there a way to configure hue in the configuration.yaml file?
i have tested it as written in the documentation with:
hue:
bridges:
- host: DEVICE_IP_ADDRESS

but nothing happens.
i dont´t want to use the discovery option.

is your indentation correct?
See the examples posted earlier

yes,
i have installed hass.io with docker on a raspberry.
if i use the discovery mode everything works fine, but i will manage all over the config files.
i have created a phue.conf file with the username from hue api.

my files:

hue:
  bridges:
    - host: <ip from hue bridge>
      allow_unreachable: true
      filename: phue.conf
{
    "<ip from hue bridge>": {
        "username": "<hue api username>"
    }
}

This too, is driving me crazy, The Hue bridge keeps going unreachable on 0.100.1 running in HTTPS

I have not setup Hue bridge in my config, but I also got the following errors

Exception occurred: 12:30 PM /usr/local/lib/python3.7/site-packages/zeroconf.py (WARNING) Unknown error connecting with Hue bridge at 192.168.1.17 11:07 AM components/hue/bridge.py (ERROR) Unknown error connecting with Hue bridge at 172.30.32.1 11:07 AM components/hue/bridge.py (ERROR) Unknown error connecting with Hue bridge at 172.17.0.1 11:07 AM components/hue/bridge.py (ERROR) Setup of hacs is taking over 10 seconds. 11:07 AM __main__.py (WARNING)

HA system version 100.3
Hardware: Pi 3B

I wonder whether this is a known issue.

Another data point: I had consistent errors for several months and when I moved off my Pi onto a more substantial server the problem went away. Perhaps not enough resources at HA boot time?

Still getting this frequently throughout the day. My HA instance is a VM on an i5 cpu with 2 cores and 2 gb ram. It’s annoying as when the hub goes unavailable several node red flows trigger and turn things off

Mine is running Hass.io on an i7 via Docker, I don't think it's a resources problem. I don't have any problems if I comment out the Hue lines in configuration.yaml. (but then I lose allow_unreachable)

Same storey - sometimes on launch .100 is failing to connect to hue hub. Been happening for the past few versions now.

I get this all the time throughout the day as well - I'm on 0.100.3. It seems like the hue bridge becomes unresponsive for what seems like a minute.

Unable to reach bridge 192.168.1.128 (Error requesting data from 192.168.1.128: None)
10:47 AM components/hue/sensor_base.py (ERROR) - message first occured at October 25, 2019, 9:51 PM and shows up 4992 times

I don't know exactly which component is the problem. There definitely seems like something wrong with the bridge - I have Hue Sync running on my PC and it constantly loses connection as well, so it seems like the actual bridge is crashing and rebooting or something. I don't know if it's something with how HA interacts with it that causes this.

Yes, I've not convinced its an HA issue, but it does cause a bunch of my node-red flows to fire when they shouldn't. We need a configurable timeout I think.

I bit the bullet and did a factory reset of my hue bridge, and I no longer get this issue. In addition to the factory reset, I didn't re-add the last light I had recently added (a gledopto LED controller) since I started suspecting maybe it was causing some problem. I had read this thread (https://huetips.com/forums/topic/hues-bridge-v2-keeps-disconnecting-from-network-solved/) that indicated it's possible a bulb or other "bad" actor could cause this to happen. I might try adding it back in later to see if it's a true problem.

So, if people are desperate it might be worth factory resetting and adding bulbs back in slowly and see how the hue bridge holds up (at least for my case, where it was happening all the time).

I bit the bullet and did a factory reset of my hue bridge, and I no longer get this issue. In addition to the factory reset, I didn't re-add the last light I had recently added (a gledopto LED controller) since I started suspecting maybe it was causing some problem. I had read this thread (https://huetips.com/forums/topic/hues-bridge-v2-keeps-disconnecting-from-network-solved/) that indicated it's possible a bulb or other "bad" actor could cause this to happen. I might try adding it back in later to see if it's a true problem.

So, if people are desperate it might be worth factory resetting and adding bulbs back in slowly and see how the hue bridge holds up (at least for my case, where it was happening all the time).

A bit extreme for me, would take me ages to re-do all of my various integrations and set up entertainment areas again. Im using Hue and Innr bulbs. Its annoying we cant get logs from Hue to see what is going on

Running on Home Assistant 0.101.3 and also facing this problem. My Hue bridge has a reserved IP, from my routers DHCP server. My configuration.yaml doesn't have any hue related stuff in it. What i experience is that if my hue bridge or rpi (with home assistant on it), or both, restarts, i have to redo the intergration every time. Its annoying, but since its everytime I'm getting used to it. What is the biggest problem with this is that i use Home Assistant for automation between my other smart devices and hue, and this makes it completely unusable. I've also noticed that my motion sensor, is the only thing that works when this happens, but no lights at all. So some communication seems to be working with the bridge even though it says its not working.

I have the exact same issue since upgrading to 0.101.3 today. I also used a reserved IP address on my router for the Hue bridge. Every time I do a reset I have to delete the integration and add again by pushing the Hub button.

I installed hassio from scratch, new 0.101.3 image on SD and reinstalled. Once I integrated the Hue bridge it worked fine, resets and reboots, the integration remained. did get an error in the log around scenes but seemed to work fine. However, once I imported my yaml files, configuration automations, sensors, switches, the problem re-appeared.

hue:
bridges:
- host: 192.168.1.56
allow_unreachable: true

Seems to have done the trick

Interesting, they must have quietly fixed something because I can use allow_unreachable again. For awhile I couldn't reach the hub unless I commented out all 4 lines.

I have this problem too, and it seems to have appeared on a recent upgrade of Home Assistant. Don't think to have seen it on 0.100 for example.
Now it's present in 0.102.

hue:
bridges:

  • host: 192.168.1.56
    allow_unreachable: true

I think something changed, too. I tried some time ago and nothing happened even if I put this on configuration.yaml. But now, in the 102 version of HA, it works! When I reboot or update HA, i find all my lights ok! Thanks

I have tried everything here and only the integration method seems to work (does nothing when in my configuration.yaml). But I get the same issue when I reboot it shows as "entity unavailable". To fix I have to go to the integration section, delete and re-add then all works again. Weird! Running 0.102.3 on RPi3. Feeling sad as just about to add to my Hue collection big time and need HA to work correctly with this! Hoping a fix can be found!

We have merged a fix that should limit the parallel requests that we make to Hue, which could fix this.

@balloob upon HA restart it can connect to the Hue bridge successfully let's say more often, but the issue hasn't fixed in 0.103. I am still having 'Unable to reach bridge' errors many times when restarting Home Assistant and consequently no entities show up . Often several Home Assistant restarts are necessary to make it connect to the bridge. Just like it was before, but with a bit better results regarding successful restarts.

Anyone else having the same issue on 0.103?

@balloob upon HA restart it can connect to the Hue bridge successfully let's say more often, but the issue hasn't fixed in 0.103. I am still having 'Unable to reach bridge' errors many times when restarting Home Assistant and consequently no entities show up . Often several Home Assistant restarts are necessary to make it connect to the bridge. Just like it was before, but with a bit better results regarding successful restarts.

Anyone else having the same issue on 0.103?

Yep, I still have the same issue! Do a reboot and can't find the entities. However, if I delete and re-add via the integrations it works until the next reboot. I must admit that on some reboots it appears to work sometimes (I know I rebooted twice over the weekend, the first time it was ok 2nd time back to the same thing). I am on 0.103 on RPi3+ in Docker

Yep, I still have the same issue! Do a reboot and can't find the entities. However, if I delete and re-add via the integrations it works until the next reboot. I must admit that on some reboots it appears to work sometimes (I know I rebooted twice over the weekend, the first time it was ok 2nd time back to the same thing). I am on 0.103 on RPi3+ in Docker

I experience exactly the same behavior. 0.103, RPi3+, Hassio

I recently added a hue bridge and see this issue with 0.103, RPi3+, Hassio

I'm not familiar with the code but taking a look at components/hue/light.py I think I see what might be wrong: If the 4 second timeout triggers the exception in async_update_items() the first time it runs, then will it ever run again? I think probably not since current.items will be empty so there is nothing to call async_schedule_update_ha_state() on and with no registered lights on this bridge yet no polling will happen either. Maybe there is some other way that async_update_items() will run again, but if not I think it would explain what we're seeing.

I confirmed that simply bumping that timeout to 10 seconds worked around the issue for me in my environment. Doesn't seem like that would be the most legit fix, but maybe that suggests a proper fix to someone more familiar with the async model here and can give folks a workaround in the mean time.

I can confirm that code change suggested by @walnerz worked for me as well. Since yesterday I don't see connectivity issue to Hue bridge anymore and I restarted HA several times. My config looks like this:

hue:
  bridges:
    - host: !secret hue_host
      allow_unreachable: true
      allow_hue_groups: false

Sounds great. Hopefully someone could fix it. On Hassio there is no access to the components folder so unfortunately I can't test it.

Here's a trick I use to get into the Components folder on HASSIO:

image

@Scope666 I downloaded and installed hassio using the SD card image from HA's website. Can portainer be installed as an addon? Otherwise I don't think I could get it.

You could try just loading hue later, since these really long delays seem to only occur early in the start sequence. Probably doing the same thing that is suggested to make homekit load after z-wave would work. (detailed near the bottom of this page https://www.home-assistant.io/integrations/homekit/)

@A320Peter It can. It's listed under Community add-ons:

image

You could try just loading hue later, since these really long delays seem to only occur early in the start sequence. Probably doing the same thing that is suggested to make homekit load after z-wave would work. (detailed near the bottom of this page https://www.home-assistant.io/integrations/homekit/)

Someone should correct me if I'm wrong but I don't think that's possible. HomeKit component has a feature to disable autostart and a service to start it any time. The Hue component doesn't have that.

Here's a trick I use to get into the Components folder on HASSIO:

Okay... I found it, installed it and the console just works like a charm. I have been looking for something similar for a year. Finally I have full access to the file system on native Hass.io install. Amazing. I owe you a beer.

Here's a trick I use to get into the Components folder on HASSIO:

Okay... I found it, installed it and the console just works like a charm. I have been looking for something similar for a year. Finally I have full access to the file system on native Hass.io install. Amazing. I owe you a beer.

Awesome, that makes me happy. Portainer is the BOMB for managing anything Docker related. One of the things it's great for is watching the Home Assistant log during boot up or just normal operation.

I'm still constantly getting this error in the logs. I have 2 bridges and lately my lights can take between 2-5s to turn on/off or change brightness. it used to be instantaneous. Every now and then they might work instantly and the next time take a few secs.

I also see the following constantly repeating in the logs taking between 0.02s and 3s to poll an update from the brighes.

2020-01-24 01:17:33 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 0.076 seconds
2020-01-24 01:17:33 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 0.084 seconds
2020-01-24 01:17:41 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 2.798 seconds
2020-01-24 01:17:41 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 2.798 seconds
2020-01-24 01:17:41 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 2.853 seconds
2020-01-24 01:17:41 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 2.862 seconds
2020-01-24 01:17:48 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 2.904 seconds
2020-01-24 01:17:48 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 2.905 seconds
2020-01-24 01:17:48 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 2.942 seconds
2020-01-24 01:17:48 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 2.948 seconds
2020-01-24 01:17:52 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 0.089 seconds
2020-01-24 01:17:52 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 0.091 seconds
2020-01-24 01:17:52 DEBUG (MainThread) [custom_components.hue.light] Finished group request in 0.113 seconds
2020-01-24 01:17:52 DEBUG (MainThread) [custom_components.hue.light] Finished light request in 0.122 seconds

My guess is it's something to do with a recent fix to limit parallel requests to the bridge and this delays the light turn on/off action but I might be wrong.

I recently added a hue bridge and see this issue with 0.103, RPi3+, Hassio

I'm not familiar with the code but taking a look at components/hue/light.py I think I see what might be wrong: If the 4 second timeout triggers the exception in async_update_items() the first time it runs, then will it ever run again? I think probably not since current.items will be empty so there is nothing to call async_schedule_update_ha_state() on and with no registered lights on this bridge yet no polling will happen either. Maybe there is some other way that async_update_items() will run again, but if not I think it would explain what we're seeing.

I confirmed that simply bumping that timeout to 10 seconds worked around the issue for me in my environment. Doesn't seem like that would be the most legit fix, but maybe that suggests a proper fix to someone more familiar with the async model here and can give folks a workaround in the mean time.

I can also confirm it works to fix the issue

I recently added a hue bridge and see this issue with 0.103, RPi3+, Hassio
I'm not familiar with the code but taking a look at components/hue/light.py I think I see what might be wrong: If the 4 second timeout triggers the exception in async_update_items() the first time it runs, then will it ever run again? I think probably not since current.items will be empty so there is nothing to call async_schedule_update_ha_state() on and with no registered lights on this bridge yet no polling will happen either. Maybe there is some other way that async_update_items() will run again, but if not I think it would explain what we're seeing.
I confirmed that simply bumping that timeout to 10 seconds worked around the issue for me in my environment. Doesn't seem like that would be the most legit fix, but maybe that suggests a proper fix to someone more familiar with the async model here and can give folks a workaround in the mean time.

I can also confirm it works to fix the issue

This workaround also fixed it for me.

I will get a fix in for 105 that should be able to recover from initial failed connections.

Was this page helpful?
0 / 5 - 0 ratings