Wiping out Home app settings

[deanlyoung]

I've noticed a few times now that when I restart my RPi, it wipes out all of the settings in the Home app. For example, all devices get reset back to "Default Room", scenes are deleted, automations are disabled, groupings of devices are ungrouped, and names of devices have been reset (e.g. Philips Hue Motion Sensor/Ambient List/Temperature).

I am running Homebridge on a Raspberry Pi 2 B+ and I have the 1st Generation Hue Hub. This is my config file:

{
    "bridge": {
        "name": "Homebridge",
        "username": "<<REDACTED>>",
        "port": <<REDACTED>>,
        "pin": "<<REDACTED>>"
    },

    "description": "Description - not very helpful...",

    "platforms": [
        {
            "platform": "Hue",
            "name": "Hue",
            "host": "<<REDACTED>>",
            "users": {
                "<<REDACTED>>": "<<REDACTED>>"
            },
            "heartrate": 5,
            "timeout": 5,
            "lights": true,
            "alllights": true,
            "groups": false,
            "sensors": true,
            "schedules": false,
            "rules": false
        }
    ],

    "accessories": [
        {
            "accessory": "WUNDERGROUND",
            "name": "Weather Conditions",
            "device": "Raspberry Pi",
            "key": "<<REDACTED>>",
            "city": "<<REDACTED>>"
        },
        {
            "accessory": "people",
            "name": "People",
            "people": [
                {"name": "<<REDACTED>>", "target": "<<REDACTED>>"},
                {"name": "<<REDACTED>>", "target": "<<REDACTED>>"}
            ],
            "threshold": 15
        },
        {
            "accessory": "HttpTemphum",
            "name": "Living Room Conditions",
            "url": "<<REDACTED>>",
            "sendimmediately": "",
            "http_method": "GET"
        }
    ]
}

[ebaauw]

Hi @deanlyoung,

Yeah, this is extremely annoying, especially when you have many lamps and sensors connected to your hue bridge. The current implementation of homebridge-hue loads all accessories at startup. When it cannot find or fails to communicate with the hue bridge, it starts nonetheless, but exposes no accessories to homekit. Homekit then thinks these accessories are no longer present and deletes them from it's database. Consequently, when you restart homebridge (and homebridge-hue), homekit thinks the accessories are brand new.

The structural solution to this is to change homebridge-hue to support homebridge 2.0's dynamic accessory model, see issue #4. Homebridge would then persist the accessories in the .homebridge directory, so homebridge-hue could still expose the "old" accessories, even when the connection to the bridge is (temporarily) lost. It will take me some time to make this change, though.

I would appreciate your ideas on some other more or less related thoughts, neither of which is implemented quickly, unfortunataly:

• Homebridge-hue could propagate name changes in homekit back to the hue bridge, so at least the names would be remembered. Edit: this can only work for service names (Siri names), which are stored in a characteristic. Accessory names are maintained in the homekit database, not in a characteristic. The homekit database can only be accessed by iOS apps, not by accessories like homebridge.
• Homebridge-hue could support the Room groups on the hue bridge to assign lights to a room (as does the bridge v2 homekit implementation). Again, homebridge-hue could propagate homekit changes of room assignments back to the bridge. Edit: would need an iOS app for this.
• Homebridge-hue could use resourcelinks on the hue bridge to remember room assignments of sensors. Edit: would need an iOS app for this.

[deanlyoung]

Hey @ebaauw, those suggestions sound right. I'm afraid I don't know too much about the inner workings of the Hue bridge, but all the more reason to read up on it. I wonder though if something could be learned (or brought over) from @nfarina's philipshue repository? I was using that one before switching, in order to gain access to sensors, and it at least had the perception of being a little more stable.

[ebaauw]

Hi Dean, @deanlyoung

I looked at that plug-in, before deciding to create on my own. Like you, I wanted homekit support for the hue sensors. For that, I needed a different design of the plug-in. Last I looked, homebridge-philipshue only queries the hue bridge and updates homekit when a homekit app actually requests the homekit characteristic values. Homebridge-hue instead polls the bridge every heartbeat seconds to detect changes without any homekit app being active. This is needed to trigger homekit rules when hue sensor values change. Also, I like the homekit apps to mirror the bridge state without having to refresh the app manually. Another difference: homebridge-philipshue collects all homekit characteristic changes for a light in a single hue bridge request. [Edit: no it doesn't, see issue #15]. The way I setup homebridge-hue, each individual characteristic change is pushed to the bridge immediately and independently. I want to change that eventually, but I'm currently focussing on the dynamic accessories. Consequently, homebridge-hue is more resource intensive on the system it runs on, on the network and on the hue bridge.

[deanlyoung]

Gotcha! Makes sense. It explains a little more for the other issue (https://github.com/ebaauw/homebridge-hue/issues/15) I opened as well.

I wonder if there would be any benefit from separating the sensor component and the light control component and expose them separately to the Home app as two platforms? Although, maybe it would still be pinging the Hue bridge just as frequently...

[ebaauw]

No, it wouldn't, the problem lies with the hue bridge (gen 1). See my response to issue #15.

[ebaauw]

I'll close this issue. The timeouts are tracked through issue #15, and the solution of the wiping of the homekit settings is with issue #4, the homebridge v2.0 dynamic accessory model.