Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UUID base using Zigbee ID #2

Closed
ebaauw opened this issue Oct 23, 2016 · 1 comment
Closed

UUID base using Zigbee ID #2

ebaauw opened this issue Oct 23, 2016 · 1 comment

Comments

@ebaauw
Copy link
Owner

ebaauw commented Oct 23, 2016

Internally, homekit identifies services by UUID. The homebridge-hue plug-in bases this UUID on the bridge id and the resource URI (e.g. /sensors/1), not on the resource name (e.g. Daylight). This way, homebridge-hue can deal with duplicate names between lights, groups, sensors, schedules. In addition, Homekit will still recognise the service after the resource name has changed on the Hue bridge, remembering which Homekit room, scenes, schedules, and rules it belonged to. However, when a Hue bridge resource is deleted and then re-created, resulting in a different URI, Homekit will not recognise the new service, and you need to re-add the new service to any Homekit rooms, scenes, schedules, and rules.
As Zigbee Lights and sensors already have a unique ID (something like a Zigbee MAC address?), this could be used as UUID base, using the current bridge id and URI scheme only for non-Zigbee resources like groups, CLIP sensors, and schedules. As this will break existing homekit configurations, we might need a config parameter to keep the current scheme.

ebaauw pushed a commit that referenced this issue Oct 28, 2016
@ebaauw
Copy link
Owner Author

ebaauw commented Oct 28, 2016

Changed in 0.0.8. No config parameter, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant