Better handling of error 7 from Hue bridge (overly long names)

[jonatan1979]

When trying to change the name of a Hue motion sensor to something longer than 32 characters in Home.app or Eve.app, I get this:

[12/18/2020, 4:45:09 PM] [Hue] oldsensorname: homekit name changed from oldsensorname to 123456789012345678901234567890123
[12/18/2020, 4:45:09 PM] [Hue] bridgename: bridge request 7484: PUT /sensors/5 {"name":"123456789012345678901234567890123"}
[12/18/2020, 4:45:09 PM] [Hue] bridgename: bridge request 7484: error 7 invalid value,  123456789012345678901234567890123, for parameter, name

There seems to be a 32-character limit for Hue motion sensor names (and possibly names of other types of Hue things?). It would be nice if this was caught and the user notified why this won't work (if possible). As it is now, homebridge-hue seems to try up to three times to do the same name change like above, and no feedback that the change has failed is given in the client app, in fact it at first looks like that name has changed before later being reverted to the old name. The delay involved makes for some confusion for the user. Not sure if it's possibly to notify the client app about this, but at the very least homebridge-hue shouldn't have to try such a futile name change attempt multiple times, if it can detect that this will never work...

(It also seems accented characters such as åäö counts as two characters for these names, making the maximum length even shorter when those are used.)

[ebaauw]

There seems to be a 32-character limit for Hue motion sensor names (and possibly names of other types of Hue things?)

Indeed.

As it is now, homebridge-hue seems to try up to three times to do the same name change like above

The retries are by HomeKit, actually. Homebridge Hue resets the HomeKit name when it next polls the bridge, as the name on the bridge hasn't updated. Then HomeKit retries changing the name.

no feedback that the change has failed is given in the client app, in fact it at first looks like that name has changed before later being reverted to the old name.

Looks like Homebridge Hue didn't propagate the error back to HomeKit, so I changed that. Still seeing the retries, thought. Looks like you need to change and or refresh the screen (pull down), before HomeKit shows the old name. It doesn't quite work the same as other characteristics.

I'll trim leading/trailing spaces from the name and cut it to 32 characters in Homebridge Hue, but HomeKit's behaviour is still somewhat counterintuitive. I'm almost regretting trying to sync the names. It seemed cool in theory, but it's a bit disappointing in practice.

[Marfre888]

@ebaauw In addition to this.. would it be possible if Homebridge Hue didn’t overwrite the Homekit names to the default of the accessory.

Presently the Hue bridge doesn’t do this unless you ask it to and I don’t believe this plugin used to do it either before 0.12.0.

Only reason is the character limit is annoying, and for easily identifying, I like to keep my accessories structured as ‘{room name}{accessory name}’ which is rarely enough characters.

[ebaauw]

Syncing the names seemed like a cool idea, but it proves to be way more trouble than it's worth. I think I'll remove that functionality altogether.

However, HomeKit seems to keep some residual state, even after the accessory no longer exposes the Configured Name characteristic, causing the names no longer to be updatable from HomeKit, see ebaauw/homebridge-zp#155. Removing and re-exposing the accessories solves this, but that means you'll have to redo your HomeKit configuration (rooms, groups, scenes, automations). I'm not sure if I'll be able to find a workaround for this.

[Marfre888]

Syncing the names seemed like a cool idea, but it proves to be way more trouble than it's worth. I think I'll remove that functionality altogether.

However, HomeKit seems to keep some residual state, even after the accessory no longer exposes the Configured Name characteristic, causing the names no longer to be updatable from HomeKit, see ebaauw/homebridge-zp#155. Removing and re-exposing the accessories solves this, but that means you'll have to redo your HomeKit configuration (rooms, groups, scenes, automations). I'm not sure if I'll be able to find a workaround for this.

Weird I don't believe I've ever come across this issue in homebridge hue, that said I'm not changing the names of my lights on a regular basis.

With the Hue app they have a toggle that updates the names in Homekit to what Hue app has, but it doesn't force changes unless that toggle is pressed. Could that be a solution?

From my end I would prefer it if Homebrdige Hue didn't force name changes because it makes some automations chaotic if you can't add a room name to an accessory, but I've found ways to work around it myself. So I'm not too fussed, but maybe my OCD can find peace

[ebaauw]

Weird I don't believe I've ever come across this issue in homebridge hue

No, because it’s still exposing Configured Name.

With the Hue app they have a toggle that updates the names in Homekit to what Hue app has, but it doesn't force changes unless that toggle is pressed. Could that be a solution?

No, the Hue app works very differently. It is a proper HomeKit app, using the HomeKit API. Homebridge, like the Hue bridge, is a HomeKit accessory, using the HomeKit Accessory Protocol (HAP). As such, it has no visibility on the HomeKit configuration, incl. rooms, groups, scenes, automations, and, until recently, accessory and service names. With the introduction of TV accessories, Apple added the Configured Name characteristic. I read that it would also work for other services, so I’m (ab)using that to set the service names from Homebridge Hue and to get an event when the name is changed from HomeKit. As I said, it doesn’t work out that well.

[ebaauw]

v0.12.13 has removed Configured Name.

[ebaauw]

v0.12.18 introduces configuredName config.json setting to expose a dummy Configured Name characteristic on each service corresponding to a /lights or /sensors resources, so the service name can be updated from HomeKit.