Homebridge-hue: Hue-Bridge Restars every 5min when added to Homebridge-Hue

Created on 21 Dec 2018  路  9Comments  路  Source: ebaauw/homebridge-hue

Issue


My Hue-Bridge runs normally when not added to Homebridge. As soon as I add it to Hb-Hue with Username and Password it Crashes every 5min. It totally disconnects and shuts down the ethernet port then restarts.

Steps I have done so far:
Reset Bridge 2.0
Try a new Bridge 2.1
Reinstall Homebridge-Hue

Log Messages

Hue] Philips hue: bridge request 122: get /config
[12/21/2018, 7:54:39 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
[12/21/2018, 7:54:44 PM] [Hue] Philips hue: bridge request 123: get /config
[12/21/2018, 7:54:44 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
[12/21/2018, 7:54:49 PM] [Hue] Philips hue: bridge request 124: get /config
[12/21/2018, 7:54:49 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
[12/21/2018, 7:54:54 PM] [Hue] Philips hue: bridge request 125: get /config
[12/21/2018, 7:54:54 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
[12/21/2018, 7:54:59 PM] [Hue] Philips hue: bridge request 126: get /config
[12/21/2018, 7:54:59 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
[12/21/2018, 7:55:04 PM] [Hue] Philips hue: bridge request 127: get /config
[12/21/2018, 7:55:04 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
[12/21/2018, 7:55:07 PM] [Hue] Philips hue: bridge request 128: get /config
[12/21/2018, 7:55:07 PM] [Hue] Philips hue: bridge communication error ECONNREFUSED on 10.***.***.8
[12/21/2018, 7:55:09 PM] [Hue] Philips hue: bridge request 129: get /config
[12/21/2018, 7:55:09 PM] [Hue] Philips hue: bridge communication error ECONNREFUSED on 10.***.***.8

MY SWITCH 

2   2018-12-21 20:35:20 Link    level_3     
port 11, changed state to up.

3   2018-12-21 20:35:19 Link    level_3     
port 11, changed state to down.

4   2018-12-21 20:35:00 Link    level_3     
port 11, changed state to up.

5   2018-12-21 20:34:58 Link    level_3     
port 11, changed state to down.

6   2018-12-21 20:34:58 Link    level_3     
port 11, changed state to up.

7   2018-12-21 20:34:56 Link    level_3     
port 11, changed state to down.

8   2018-12-21 20:34:54 Link    level_3     
port 11, changed state to up.

9   2018-12-21 20:34:52 Link    level_3     
port 11, changed state to down.

10  2018-12-21 20:34:51 Link    level_3     
port 11, changed state to up.

11  2018-12-21 20:34:48 Link    level_3     
port 11, changed state to down.

12  2018-12-21 20:29:35 Link    level_3     
port 11, changed state to up.

13  2018-12-21 20:29:34 Link    level_3     
port 11, changed state to down.

14  2018-12-21 20:29:15 Link    level_3     
port 11, changed state to up.

15  2018-12-21 20:29:11 Link    level_3     
port 11, changed state to down.

16  2018-12-21 20:29:09 Link    level_3     
port 11, changed state to up.

17  2018-12-21 20:29:07 Link    level_3     
port 11, changed state to down.

18  2018-12-21 20:29:06 Link    level_3     
port 11, changed state to up.

Debug Files

question

Most helpful comment

@th3cube did you ever figure out what the cause of this was? I have exactly the same problem and I鈥檓 stuck for a solution.
Thanks too @ebaauw you do great work.

All 9 comments

This is new for me. Homebridge-hue does regular API calls to the Hue bridge, that shouldn鈥檛 be able to cause it to crash. Some long shots:

  • Are you sure the bridge reboots? Is the Daylight sensor updated? Could you check that /sensors/1/state/lastupdated is updated after each crash?
  • Did you use the new power adapter with the new bridge? I did have a broken power cord on my first gen1 Hue bridge;
  • Did you try a different switch (port) and network cable?
  • What devices do you have connected to the Hue bridge? On the Hue developer forum there was talk about OSRAM lights causing the bridge to crash after their firmware was updated without first deleting the resources from the Hue bridge;
  • What heartrate setting do you use in config.json? Do you have other Hue clients running? Does it still crash after five minutes when you set heartrate to 30?
  • What happens if you query the bridge manually, e.g. running
    while true ; do ph get /config ; sleep 2 ; done

Thx for your Help!

  • Are you sure the bridge reboots? Is the Daylight sensor updated? Could you check that /sensors/1/state/lastupdated is updated after each crash?
    "state": {
        "daylight": true,
        "lastupdated": "2018-12-22T13:40:37"

after errors

    "state": {
        "daylight": true,
        "lastupdated": "2018-12-22T13:40:37"

Nothing changes but Lights on the Bridge for Ethernet and Internet connection go off and on




  • Did you use the new power adapter with the new bridge? I did have a broken power cord on my first gen1 Hue bridge;

Yes



  • Did you try a different switch (port) and network cable?

I switched from Port 16 to 11 also tried my other switch and reduced it to 10mbits, after nothing helped I decided to buy a new bridge, as I was convinced that is must be a hardware failure.



  • What devices do you have connected to the Hue bridge? On the Hue developer forum there was talk about OSRAM lights causing the bridge to crash after their firmware was updated without first deleting the resources from the Hue bridge;

I have one Ikea Light and one Osram Power Plug. I haven't added the Osram Plug back jet after I switched the Bridge. When i switched the Bridge i only added my original Philips Lights and the one Ikea Light

In total I have 8 Philips Hue Lights some LC001 and LC007 one Iris 2 Sensors



  • What heartrate setting do you use in config.json? Do you have other Hue clients running? Does it still crash after five minutes when you set heartrate to 30?

Here is my Config.json:

            "platform": "Hue",
            "name": "Hue",
            "host": "10.10.10.8",
            "users": {
                "XXXXXXXXXX": "XXXXXXXXXXXXXXXXXXXX"
            },
            "sensors": true,
            "excludeSensorTypes": [
                "CLIP",
                "Geofence",
                "Daylight"
            ],
            "lowBattery": 25,
            "lights": true,
            "nativeHomeKitLights": true,
            "nativeHomeKitSensors": false,
            "groups": false,
            "group0": false,
            "rooms": false,
            "schedules": false,
            "rules": false,
            "resource": false,
            "heartrate": 5,
            "waitTimeUpdate": 20,
            "timeout": 5,
            "parallelRequests": 10,
            "waitTimeResend": 300

I also tried with these settings:

            "heartrate": 15,
            "waitTimeUpdate": 150,
            "timeout": 25,
            "parallelRequests": 5,
            "waitTimeResend": 1000

after that there is still a five min. interval of reboots/crashes but with fewer log entries.

10:52:38 PM][39m [36m[Hue][39m [1m[31mPhilips hue: bridge request 19: get /config[39m[22m
10:52:38 PM][39m [36m[Hue][39m [1m[31mPhilips hue: bridge communication error ECONNREFUSED on 10.***.***.8[39m[22m
10:53:11 PM][39m [36m[Hue][39m [1m[31mPhilips hue: bridge request 21: get /config[39m[22m
10:53:11 PM][39m [36m[Hue][39m [1m[31mPhilips hue: bridge communication error EHOSTUNREACH on 10.***.***.8[39m[22m
10:53:11 PM][39m [36m[Hue][39m [1m[31mPhilips hue: bridge request 20: get /config[39m[22m
10:53:11 PM][39m [36m[Hue][39m [1m[31mPhilips hue: bridge communication error EHOSTUNREACH on 10.***.***.8[39m[22m


 [10:59:04 PM] [39m [Hue] Philips hue: bridge request 90: get /config
 10:59:04 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8
 10:59:19 PM] [Hue] Philips hue: bridge request 91: get /config
 10:59:19 PM] [Hue] Philips hue: bridge communication error ETIMEDOUT on 10.***.***.8






  • What happens if you query the bridge manually, e.g. running
    while true ; do ph get /config ; sleep 2 ; done

How do i query the bridge manually?

One of the first things the bridge does after starting, is update the Daylight sensor. If /sensors/1/state/lastupdated isn't updated, the bridge hasn't rebooted. I agree, this smells like a hardware failure, but having two bridges with the same failure would be very unlikely. More likely a software failure, but I wouldn't kwow what's causing it. Did you migrate the settings from the old bridge to the new bridge, or did you setup the new bridge from scratch, pairing each light individually?

How do i query the bridge manually?

Where do you run homebridge? If on a Raspberry Pi or other Linux-like system, use the while true command from a terminal window (shell).

I also tried with these settings [...] after that there is still a five min. interval of reboots/crashes but with fewer log entries.

So it's not a buffer filling or something. It might be something else doing something on your network every 5 minutes. Do you now how to sniff the network traffic? Could also be an issue with your network setup: are you sure there's no loop between your switches, routers and wireless access points? What happens when you disconnect your network from the Internet? What happens if you attach both bridges to the network (and only use homebridge-hue with one of them). Do they crash at the same time? What else did you install with homebridge-hue? Are you running other plugins?

Did you migrate the settings from the old bridge to the new bridge, or did you setup the new bridge from scratch, pairing each light individually?

I did it from scratch, had to add the Lights one by one with their serial Numnber



So it's not a buffer filling or something. It might be something else doing something on your network every 5 minutes. Do you now how to sniff the network traffic? Could also be an issue with your network setup: are you sure there's no loop between your switches, routers and wireless access points? What happens when you disconnect your network from the Internet? What happens if you attach both bridges to the network (and only use homebridge-hue with one of them). Do they crash at the same time? What else did you install with homebridge-hue? Are you running other plugins?

Im sure its not a Loop, my switch are capable of spanning tree and would detect a loop.
But im also sure now that its not caused by Homebridge-hue. I did some more Tests ans when i disable the plugin in config.json my switch still reports disconnects from the port 11.

4   2018-12-22 17:49:47 Link    level_3
port 11, changed state to up.
5   2018-12-22 17:49:45 Link    level_3
port 11, changed state to down.
6   2018-12-22 17:49:45 Link    level_3     
port 11, changed state to up.
7   2018-12-22 17:49:43 Link    level_3     
port 11, changed state to down.
8   2018-12-22 17:49:42 Link    level_3     
port 11, changed state to up.

But when i shut down Homebridge Completely the errors disappear, So as you mentioned, it must be caused by another homebridge-plugin.
This will be hard to track because I have so many plugins running :/
I am very curious which plugin can trigger such a behavior on the bridge




Thank you for your Help! Im sorry for wasting your time. After switching the Bridge I was very surprised that the bridge still reboots and thought i misconfigured something in the Hue-Plugin but thats not the case

I am very curious which plugin can trigger such a behavior on the bridge

As am I. My best guess would be that one of the plugins causes a broadcast or multicast storm (UPnP or Bonjour?). I hope you'll be able to figure it out.

@th3cube did you ever figure out what the cause of this was? I have exactly the same problem and I鈥檓 stuck for a solution.
Thanks too @ebaauw you do great work.

I also encounter this issue but in an even more strange scenario:
I have two homebridge-instances: one on an RPi and another one on a Synology-NAS inside a docker-container (oznu/homebridge). As soon as I start the dockerized version (again it's homebridge, not homebridge-hue) my hue-bridge starts rebooting every 6 minutes. I do not have any hue-packages installed, only "homebridge-camera-ffmpeg": "^0.1.12" and "homebridge-dummy": "^0.2.0".

Solved it: it was caused by the dockerized homebridge-container. In network-mode "host" the contained avahi-daemon caused mDNS-conflicts. I moved the container to a separate macvlan-network. Now everything works again.

@th3cube @rbhr Any luck solving this one? I am having the same problem as well, but the solution from @hkuehl didn't do the trick. I am using a Synology NAS.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Krocko picture Krocko  路  12Comments

jostrasser picture jostrasser  路  3Comments

th3cube picture th3cube  路  10Comments

zeromancer1972 picture zeromancer1972  路  7Comments

leoneleone picture leoneleone  路  9Comments