You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: