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.

[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: johannrichard/homebridge-dingz#5 (comment)

[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 ***@***.***>, 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.

[Nastras]

Hello Erik,

since i read in the latest update that you are starting to prepare homebridge-hue for the transition to dynamic platform i wanted to ask when the time comes if i need to disconnect the homebridge instance from hk for this or will it be an easy transition?

Thanks!

[ebaauw]

I think I'll be able to provide an upgrade while keeping the HomeKit configuration intact, with help from oznu for the needed support by Homebridge.

[Nastras]

That sounds great 👍

[ebaauw]

Closing this in favour of #1070.