Sync HomeKit service names with Hue bridge/deCONZ gateway

[ebaauw]

With the introduction of the ConfiguredName characteristic (in iOS13/14?), it's now possible to update the name of a HomeKit service over HAP, and to be notified over HAP, when a HomeKit user changes the service name. See Discord #plugin-development channel.

Beta v0.11.78-1 implements this for services linked to /lights resources (confirmed to work for Lightbulb services). Still to do:

• Implement this for services linked to /sensors resources;
• Figure out how this can work for an accessory with Stateless Programmable Switch services (maybe use the ServiceLabel service?);
• Implement this for services linked to /schedules and /rules resources;
• Implement for the service linked to the Hue bridge/deCONZ gateway.

There doesn't seem to be a way to update the accessory name over HAP, not to be updated of HomeKit changes to the accessory name. Using the AccessoryInformation service doesn't seem to do this.

[jdberry]

I left this note on discord, but I'll expand and repeat it here for better tracking:

I've got a couple issues related to the new name synching between HomeKit and deCONZ.

1. After starting up 0.11.78-1 for the first time, it appears my Hue lights that I had re-named in HomeKit suddenly were renamed to their names under deCONZ. That's not what I expected to happen... in other words, the initial mismatch was decided in favor of the name in deCONZ.
2. Additionally, I realize that I've come to somewhat rely on having two different names... I tend to make the deCONZ name more descriptive of the device and location ("Hue Color Kitchen North" or something), while making the homekit name simpler and easer to use in Siri, and sensitive to other meta information that HomeKit already knows but isn't apparent in deCONZ ("North Light", omitting the type and the room information, which is implicit). I'm not sure it's the perfect approach, but it's worked well for me so far. (I haven't looked to see if there's a switch that allows me to disable the synching?)

Looking at my smoke detector naming in deCONZ, I see similar issues with naming. It's useful in deCONZ to name them such that the name includes the fact that it's a smoke detector, and it's location. So "Smoke 2nd Floor NE" is a name that's useful in deCONZ, while "Smoke Detector" is perhaps a better name in HomeKit, where, again, the room is implicit.

At best, I think you should include options for whether such synching should occur for /lights, /sensors/, at all, or perhaps independently?

[ebaauw]

As I replied on Discord:

1. I need to double-check, but I'm not sure if I can actually query the HomeKit service name on startup. Anyways I should no longer be an issue after the new names have been sync'ed between HomeKit and deCONZ.
2. I haven't yet considered making this an optional feature, but probably could do so. This would be a single config.json setting for all syncing, not per resource type, let alone per individual resource.

[ebaauw]

In v0.12.2.

[twentyNoise]

2. I haven't yet considered making this an optional feature, but probably could do so. This would be a single config.json setting for all syncing, not per resource type, let alone per individual resource.

I'd also love to have the ability to disable the Configured Name syncing. I have the Philips Motion accessories listed in HomeKit along with the Homebridge-hue accessories because I use the Philips Motion accessories to 'detect' the motion as I find that the homebridge-hue accessories have a lag in motion detection. So I name the homebridge-hue accessories with a 'HB' in the name so that I know what to choose in creating or modifying the automations.

I also keep the accessories in the Hue App named with the "room" named included, but I take the room name 'out' of the HomeKit accessories.

Anyhow, I'd be interested in this as well.

Thanks!

[Nastras]

Hello @ebaauw
is it now possible to disable the synchronization for the names? I have the same problems as described above by the synchronization.

[ebaauw]

This feature has been removed, see #861.