Support dynamic homebridge accessories about homebridge-hue HOT 22 CLOSED

If there were, I’d post them here.

from homebridge-hue.

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.

from homebridge-hue.

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.

from homebridge-hue.

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.

from homebridge-hue.

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

from homebridge-hue.

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.

from homebridge-hue.

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.

from homebridge-hue.

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.

from homebridge-hue.

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?

from homebridge-hue.

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.

from homebridge-hue.

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.

from homebridge-hue.

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

from homebridge-hue.

News?

from homebridge-hue.

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.

from homebridge-hue.

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)

from homebridge-hue.

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.

from homebridge-hue.

from homebridge-hue.

Hi,

are there any news on this?

from homebridge-hue.

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.

from homebridge-hue.

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!

from homebridge-hue.

That sounds great 👍

from homebridge-hue.

Closing this in favour of #1070.

from homebridge-hue.