Homebridge-hue: Support dynamic homebridge accessories

[ebaauw]

Currently homebridge-hue uses static homebridge accessories, configured at start-up time.

With dynamic homebridge accessories, homebridge-hue could dynamically add or remove accessories as they are added to or removed from the Hue bridge, without restarting homebridge. Not sure if that's really a big win (how often do you buy new hue lights, switches, or sensors), but it could be handy for CLIP sensors and schedules.

However, the ability to store an accessory context might be useful to store the bridge username in the bridge accessory (once we support that) without the need to update manually config.json. Also, this would allow for config switches for lights, groups, sensors, schedules in the bridge accessory.

[ebaauw]

Note to self: also change mapping of reachable from Status Fault to accessory reachable state. This is supported by the iOS 10 Home app and how the square Philips Hue bridge exposes reachable.

[dylanslewis]

Another nice to have here, if supporting dynamic accessories, would be to have a dynamic heartrate value. This way you could have a fast polling time when you know the house will be busy, and low polling time when it is empty.

[ebaauw]

Indeed, @dylanslewis . You could even switch the polling off altogether and only query the bridge when HomeKit apps actually request the value of the corresponding characteristic. Not sure what that would do to HomeKit triggers, though.

Also, I could implement some of the configuration parameters in config.json in HomeKit switches instead and change what resources homebridge-hue exposes on the fly.

[ebaauw]

Actually, I don't need dynamic platform accessories for a dynamic heartrate. Opened separate issue #39 for this.

[ebaauw]

Looks like I finally found a compelling reason to start working on this: on startup, deCONZ shows no /lights resources, even thought it has stored lights discovered in previous sessions in its database. It only restores the resource, after the light has been re-discovered in this session.

With dynamic platform accessories, homebridge-hue would expose all previously discovered accessories immediately on startup, but mark them as unreachable (in HomeKit context). When the resource becomes available, homebridge-hue would re-attach the accessory to the resource, and mark it as reachable. This would also solve any startup timing problems, where homebridge would start before homebridge-hue had created all accessories, causing HomeKit to delete the not yet exposed accessories.

This will be by far the biggest change to homebridge-hue. I need to refactor a large part of the code. I'll create a new v1.0 branch for these changes.

[jaal2001]

As I'm currently adding various types of products to my deCONZ setup (i.e. plugs), it would be great if I just have to add them to deCONZ and homebridge(-hue) presents them automatically to me in Homekit. That would it make even possible to add a device by someone, who does not know anything about linux but is able to add a device via the webservice.

[thewhit]

Thanks for your work on this @ebaauw. Amazing.

Homekit is still dropping my settings after homebridge-hue or deconz restart. Is this still expected after upgrading to v0.8?

[ebaauw]

What settings are you talking about?

No settings should be lost at all when restarting deCONZ while homebridge keeps running.
When restarting homebridge, you lose the settings in homebridge-hue: notably heartrate (if changed from homekit) and the duration for the Hue motion sensor when connected to a Hue bridge.
When (re)starting homebridge too soon after (re)starting deCONZ, you might use HomeKit assignments for lights, see #246.

[thewhit]

I was losing light groupings in homekit (I think) because I didn't understand how to assign lights. Thanks for referencing #246 where all of this is very clearly explained. I think this will solve the lost groups after a pi reboot. Thank you @ebaauw for the quick reply and your work on this.

[thewhit]

Hi @ebaauw,

I've been using homebridge-hue for a few months to control lights through deconz. I added a few Hue ambiance lights with a Hue Bridge and now I'm trying to get the settings in the Home app to stick.

I have a Hue Bridge v2 exposed through deconz and homebridge-hue to homekit. The Hue lights don't show up in the lightlist (ph lightlist -v) and are thus getting lost from the Home app. Is there any way to expose Hue Bridge lights this way, or am I doing something wrong?

from the config:

    {
      "platform": "Hue",
      "users": {
        "xxx": "xxx",
        "xxx": "xxx"
      },
      "nativeHomeKitLights": false,
      "nativeHomeKitSensors": false,
      "lights": true
    }

Thanks

[netRunner0]

News?

[ebaauw]

News?

I just converted homebridge-zp to use dynamic platform accessories. Three plugins down, three to go. I'll be saving the best (homebridge-hue) for last: it has most users and I really want to iron out any design issues in homebridge-lib before refactoring homebridge-hue.

[simonnelli]

It seems that the lack of support for dynamic accessories of homebridge-hue interferes with other homebridge plugins that support dynamic accessories. See: https://github.com/johannrichard/homebridge-dingz/issues/5#issuecomment-630986733

[ebaauw]

This has nothing to do with other plugins supporting dynamic accessories. It’s how Homebridge used to work before dynamic platform accessories (Homebridge Hue is over 5 years old). Static platform plugins need to inform Homebridge what accessories they want to expose, before Homebridge starts the HAP server. Homebridge Hue needs to (re-) connect to all Hue bridges mentioned under hosts in config.json, and, for new bridges, request an api key, requiring the user to press the link button, before it can pass the accessories back to HomeKit. During this time, homebridge runs, but the HAP server hasn’t started, and Homebridge cannot be reached by HomeKit.

When a bridge is unreachable, by design, Homebridge Hue waits for it to become reachable, delaying Homebridge startup. If Homebridge Hue wouldn’t do this, Homebridge would start without exposing the accessories, and HomeKit would delete them. On the next restart, the accessories would be exposed again, but HomeKit would see them as new accessories, having lost any associations to room, groups, scenes, and automations.

[simonnelli]

Thank you for the clarification, I’ll pass the info on so maybe we get to the bottom of the issue.
On 19 May 2020, 23:31 +0200, Erik Baauw [e-mail], wrote:

This has nothing to do with other plugins supporting dynamic accessories. It’s how Homebridge used to work before dynamic platform accessories (Homebridge Hue is over 5 years old). Static platform plugins need to inform Homebridge what accessories they want to expose, before Homebridge starts the HAP server. Homebridge Hue needs to (re-) connect to all Hue bridges mentioned under hosts in config.json, and, for new bridges, request an api key, requiring the user to press the link button, before it can pass the accessories back to HomeKit. During this time, homebridge runs, but the HAP server hasn’t started, and Homebridge cannot be reached by HomeKit.
When a bridge is unreachable, by design, Homebridge Hue waits for it to become reachable, delaying Homebridge startup. If Homebridge Hue wouldn’t do this, Homebridge would start without exposing the accessories, and HomeKit would delete them. On the next restart, the accessories would be exposed again, but HomeKit would see them as new accessories, having lost any associations to room, groups, scenes, and automations.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Tyraenor]

Hi,

are there any news on this?

[ebaauw]

If there were, I’d post them here.

[ebaauw]

Did a big refactor in v0.12.13 of the supporting classes (to handle the very different behaviour of the latest Hue bridge firmware), but the platform plugin itself is still on the TODO list.