Names in Homekit keep resetting with v1.1.46

[dylexrocks]

I have just updated from v1.1.45 to v1.1.46 and noticed that some devices now have a different name than before. The name that I manually assigned in the iOS Home app has been changed to the name as it appears in the "name" property in the Hombridge configuration. If I try to change the name in the Home app, it is reset to the name from the configuration after a few seconds. The following device types are affected:

• Lamps (lightbulb)
• Motion detector (occupancySensor)
• Light sensor (lightSensor)

All other devices that I use, e.g. contact sensors (contactSensor) or outlets (switch, outlet) are not affected.

I have tested what happens if I downgrade the version back to v1.1.45. The behavior remains the same until I remove the affected device from the configuration and add it again. Only then can I rename it. If I try the same with v1.1.46, remove the device and add it again, the behavior does not change.

Could it possibly be related to this PR? https://github.com/arachnetech/homebridge-mqttthing/pull/649

If you would like me to provide more information, please let me know. I'm not very experienced with nodejs programming so I don't know what information would help specifically.

[arachnetech]

I suspect you're right. That's a pain. Thanks for letting me know.

[zazula]

Yes, that is what I meant by the note about receiving changes back from HomeKit. Let me look into that today...

[EjvindHald]

@zazula , @arachnetech I understand the good intentions behind this change, but to me it has the reverse effect. Every time I restart Homebridge all manual settings in the Home app are lost and reverted to the config.json values, which is not optiomal.

Example: I have ceiling lights and room termostats in all rooms. So in config.json I name them: termostat - room A ceiling light - room A

In the app I then move them to the relevant room and change the name so they are all called termostat or ceiling light in all rooms. They have the same intuitive name when used in the Home app, but initially I need to provide a different name for each to distinct.

Also, I do not understand why the name attribute in config.json was chosen for this. According to configuration.md the optional "caption" settings is exactly for this purpose, and should be used.

If you still would like to override the manual changes done in Home app, then I suggest to make an option to select or deselect this override.

Thanks for your support.

[arachnetech]

Thanks for reminding me about 'caption'. This is my fault for not reviewing the merge request more closely.

Let me look into this more closely. I suspect you're absolutely right...

[arachnetech]

I'm not actually convinced that setting caption does anything. I think it may be an option left over from the accessory that I originally based mqttthing on.

[EjvindHald]

You are conpletely right - it does not do anything.

My ideal setup would be:

If caption is populated, then use it. Otherwise use name.

Make a new optional true/false setting: OverrideHomekitName which would indicate if caption should override any changes in the Home app. Default should be false.

Again, thanks for your support.

[arachnetech]

Default behaviour change disabled in 1.1.47, but still accessible through new nameOverride configuration setting

[arachnetech]

I'll tidy up caption when I have more time. :-)

[EjvindHald]

I think that name is a unique identifier, while caption can have the same name for several accessories - e.g. ceiling light which would be used in many rooms.

But I am not entirely sure of the unique requirements.

[EjvindHald]

I'll tidy up caption when I have more time. :-)

Thanks 😃

Enablement of caption would be great as mentioned previously in this post.

[dylexrocks]

I also like the idea of using captions as names in HomeKit. Would make it possible to specify the name directly in the config without the need to rename everything manually in the home app.

I just updated to 1.1.47 and tried to rename my devices. However the behavior is still unchanged, all deceives rename themselves again after some seconds. For one of them I specifically set nameOverride to false, but it had no effect. Am I doing something wrong?

[chriz1984]

Same problem here. Updated to v1.1.47 and restarted multiple times. Names still changes back in Homekit after one second.

Edit: Setting "nameOverride": true on the specific device seems to work @dylexrocks

[chrispi68]

Same problem here. Updated to v1.1.47 and restarted multiple times. Names still changes back in Homekit after one second.

For me, too. The problem is not fixed in 1.1.47.

[chriz1984]

Same problem here. Updated to v1.1.47 and restarted multiple times. Names still changes back in Homekit after one second.

For me, too. The problem is not fixed in 1.1.47.

Try setting "nameOverride": true on the device, this worked for me

[arachnetech]

That's odd - I only set the characteristic if nameOverride is populated (and not empty):

                // name override
                if( config.nameOverride ) {
                    service.setCharacteristic( Characteristic.ConfiguredName, config.nameOverride );
                }

Perhaps this ConfiguredName characteristic is cached somewhere within Homekit/Homebridge? Do you still see the problem if you create a new accessory and then rename it?

[chrispi68]

Try setting "nameOverride": true on the device, this worked for me

Thanks, this helped! The issue with the names cost me 2 days of my life ;-)

[dylexrocks]

I can confirm that setting nameOverride to true for an accessory makes it keep the name I manually set via the Home app. Thanks for the hint @chriz1984.

But now I am even more confused. My understanding was, that setting the nameOverride property to true would make the plugin report the name I set in the homebridge config file and thereby prevent manual changes via the home app. In order to allow manual changes I would have to set it to false. Did I get that the wrong way round?

When creating a new accessory without specifying nameOverride with this version, it behaves like in <= 1.1.45 and I can rename it in the Home app and it stays that way.

Anyone has an idea?

[arachnetech]

The pull request that caused this issue always set the ConfiguredName characteristic to the name in the configuration. This was, I believe, a mistake. I reverted this and instead added a new nameOverride configuration option. If (and only if) nameOverride is set to something other than 0, false or an empty string, then it gets set as the ConfiguredName. In other words:

1. nameOverride is expected to be set to a string - not to true or false
2. When it's not set, ConfiguredName isn't touched

However, from what you're saying it seems that because version 1.1.46 set ConfiguredName, this is still preventing manual renaming of accessories.

Setting it to true is passing true will set the ConfiguredName characteristic to true, which is probably an invalid value. Perhaps this is undoing the issue caused by 1.1.46. It would be interesting to know whether removing nameOverride (after setting it to true) causes the issue to reoccur - or whether it's then fixed permanently.

I should try to reproduce all of this myself - I just haven't had time. (Unfortunately my development Homebridge is currently not showing up in the Home app, which makes debugging or testing anything rather a pain.)

[chrispi68]

Setting it to true is passing true will set the ConfiguredName characteristic to true, which is probably an invalid value.

First, I set "nameOverride": "true" which caused every accessory to show the name "true". Without the Quotes, it solved the problem: "nameOverride": true

[dylexrocks]

1. nameOverride is expected to be set to a string - not to true or false
2. When it's not set, ConfiguredName isn't touched

Thanks for the clarification. Now I understand how it should be used.

Setting it to true is passing true will set the ConfiguredName characteristic to true, which is probably an invalid value. Perhaps this is undoing the issue caused by 1.1.46. It would be interesting to know whether removing nameOverride (after setting it to true) causes the issue to reoccur - or whether it's then fixed permanently.

I just tried that out, but once I removed nameOverride from the accessory I was again unable to rename it from the Home app. So I assume for accessories that were present in 1.1.46 this option is needed if you want to rename it and do not want to temporarily remove the device and re-add it again after.

I also tried setting nameOverride to a string and could see my device using the string as its name in the Home app. I'm very fond of that option tbh, because I can already specify the name in the config now, instead of having to rename everything in the Home app. So far so good, but now comes the part I still don't understand. I was expecting that the renaming behavior would be the same as it was in 1.1.46, once I specify a valid value for nameOverride. Meaning that I thought I would not be able to rename a device in the Home app that has a specified nameOverride in the config. However this is possible. I tried that on another accessory that was already there in 1.1.46 and did not have the nameOverride option yet, so it could not be renamed. I set the nameOverride to "Stehlampe" and after a restart I could see the name in the Home app. But I could also rename it via the Home app and it synced across all my devices. After a restart the name was changed back to "Stehlampe" though. So all in all a bit weird.

But the current nameOverride approach works for me without having to remove all devices and add them again which would also require to set up all scenes and automations again. Which is the most important thing. Thank you very much for your fast support. :)