Accessories with identical names

[dxdc]

It seems that I have several "identically named" devices - for example, 2 Nest Thermostats, which each have a Fan control.

This results in the following behavior:

Unfortunately, it seems I can't individually select them either. No matter which option I choose, it reverts to the first menu item. In my case, they have identical option value=... NestFan0000004 as well... so maybe it's some kind of naming convention with the unique identifier. It's unfortunate that the Nest plugin uses identical names, but wondering if there's some other solution here?

EDIT I can control one of them, but it would be nice to be able to control both :)

[dxdc]

Digging into this some more, it seems like just a problem with the Nest plugin. I'm not sure you want to do anything about it, but I fixed it here:

https://github.com/chrisjshull/homebridge-nest/pull/168/commits/5f1153d8b0cb3570a7ad3afc9733f71b25336d3d

It might be nice to have some detection for duplicates in these kinds of cases.

[dxdc]

@NorthernMan54

I realized this issue goes a bit deeper.

There are 3 references where uniqueId are used in the code. The problem is that if an accessory has the same MAC/IP address, manufacturer, and name, it will result in duplicate uniqueId and will cause unexpected behavior with the inability to control these elements.

HbAccessories.js:      context.uniqueId = context.homebridge + context.id + context.manufacturer + context.name + context.service + context.characteristic;
Service.js:      uniqueId: context.homebridge + this.id + context.manufacturer + context.name + this.type,
register.js:      context.uniqueId = context.homebridge + context.id + context.manufacturer + context.name + context.service + context.characteristic;

My suggestion is to replace name with aid, as follows. Or, aid could just be appended also, but perhaps skipping name and just using aid allows for more flexibility since a user can change the name with no impact to their nodes. Probably there would need to be some migration code for older flows (and/or support for either format) so as not to disrupt existing flows.

HbAccessories.js:      context.uniqueId = context.homebridge + context.id + context.manufacturer + context.aid + context.service + context.characteristic;
Service.js:      uniqueId: context.homebridge + this.id + context.manufacturer + context.aid + this.type,
register.js:      context.uniqueId = context.homebridge + context.id + context.manufacturer + context.aid + context.service + context.characteristic;

I'm not as familiar with how aid's are generated, but if this is a viable solution it seems it could help a lot. I have an ongoing discussion with the maintainer of homebridge-nest trying to rectify the issue that way, but I think this solution could be helpful also.

(One other idea would be to show linked nodes with the parent name also.. e.g. Parent_name.Linked_name so as to eliminate confusion that way)

[NorthernMan54]

In regards to using AID and IID as part of the unique identifier, I had been using that with my homebridge-alexa skill as part of its unique ID, and found that it was causing similar issues as the AID and IID where changing when the homebridge configuration was changed. So about a year ago, I switched over to the current pattern of not using AID with the Alexa plugin and this one. I was getting complaints on a regular basis from people saying that duplicate devices were being created etc.

If you could send over an accessory dump from the problematic devices, I can run it thru the accessory parser and see if any other tweaks are available, like parent name etc.

[NorthernMan54]

Details on creating an accessory dump are here

https://github.com/NorthernMan54/homebridge-alexa#homebridge-accessory-dump

[dxdc]

Thanks @NorthernMan54 :

Here is a dump from the problematic devices, two Nest thermostats.

The accessories in question are two sub-characteristics of the parent Nest thermostat, both Fans (although Eco Mode has the same issue).

• Serial Number could be useful from the parent, although this isn't guaranteed in all cases
• Name could be useful from the parent in the event of sub-characteristics

Seems AID/IID are probably the best bet provided that they don't change if accessories are added/deleted, but if that is a faulty assumption then it's not helpful either. AID/IID are not exactly user-friendly to change/track in the event of a problem. I suppose a user could manually find/replace IP address or MAC address in their flows much easier than those numbers.

What do you think about the following then?

1. Add Parent Name and Parent Serial to UniqueId (could even make this a config parameter)

Add legacy parsing to "upgrade" flows that do not contain those uniqueIds

2. Change display name in device picker to also show parent name in the event of a duplicate item only. E.g., in the above case:

Fan - Fan (Master Bedroom Thermostat)

3. In the event of a truly duplicate UniqueId, raise an exception in the DEBUG window when a user views the device picker

[NorthernMan54]

I’m going to add a “Hack” for Nest for this

In the Service.js toList function, I’m going to add some logic, if manufacture is Nest and if it’s the Fan or ECO Mode, have the name include the Parents name. So the name would end up being the full thermostat name + Fan or ECO Mode

Give me about a day, it will also include logging during discovery of duplicates

On Feb 23, 2020, at 10:03 AM, dxdc [email protected] wrote:

Thanks @NorthernMan54 https://github.com/NorthernMan54 :

Here is a dump https://pastebin.com/dl/NHEaHdfD from the problematic devices, two Nest thermostats.

The accessories in question are two sub-characteristics of the parent Nest thermostat, both Fans (although Eco Mode has the same issue).

Serial Number could be useful from the parent, although this isn't guaranteed in all cases Name could be useful from the parent in the event of sub-characteristics Seems AID/IID are probably the best bet provided that they don't change if accessories are added/deleted, but if that is a faulty assumption then it's not helpful either. AID/IID are not exactly user-friendly to change/track in the event of a problem. I suppose a user could manually find/replace IP address or MAC address in their flows much easier than those numbers.

What do you think about the following then?

Add Parent Name and Parent Serial to UniqueId (could even make this a config parameter) Add legacy parsing to "upgrade" flows that do not contain those uniqueIds

Change display name in device picker to also show parent name in the event of a duplicate item only. E.g., in the above case: Fan - Fan (Master Bedroom Thermostat)

In the event of a truly duplicate UniqueId, raise an exception in the DEBUG window when a user views the device picker — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NorthernMan54/node-red-contrib-homebridge-automation/issues/30?email_source=notifications&email_token=AEXEFGHKWKKZVL647OEJHEDREKF4RA5CNFSM4JGPWN2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMV55BQ#issuecomment-590077574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXEFGFNSWSNU4SXFPFVR53REKF4RANCNFSM4JGPWN2A.

[dxdc]

Awesome.. thanks!

[NorthernMan54]

Try updating and try again. The name for Fan and Eco Mode will now contain the Parent accessory

[dxdc]

@NorthernMan54 Thanks! Appears to work just fine.

One minor point - the node name itself doesn't have Fan as part of it, it just shows the Parent name. Any way to have it show Dining Room Thermostat - Fan instead?

[NorthernMan54]

30 second change, update and try again

On Feb 23, 2020, at 4:13 PM, dxdc [email protected] wrote:

@NorthernMan54 https://github.com/NorthernMan54 Thanks! Appears to work just fine.

One minor point - the node name itself doesn't have Fan as part of it, it just shows the Parent name. Any way to have it show Dining Room Thermostat - Fan instead?

https://user-images.githubusercontent.com/7200365/75120172-113f7d00-564f-11ea-858b-c9d48a28dade.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NorthernMan54/node-red-contrib-homebridge-automation/issues/30?email_source=notifications&email_token=AEXEFGEBGGAWCTU2GK64SITRELRJJA5CNFSM4JGPWN2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWHQHA#issuecomment-590116892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXEFGEFP42KIUZ3EWMUVUDRELRJJANCNFSM4JGPWN2A.

[dxdc]

Works great! The node name did not auto-update, but once I double-clicked each node and then just pressed 'OK' again, it works perfectly.

[plantoschka]

I have the exact same issue with the Yeelighter Plugin and two Ceiling Lights.

I've already tried to change the name in HomeBridge but this apparently does not effect the name in NodeRed.

Can somebody help me? I want to control both devices.

[NorthernMan54]

@plantoschka This is a known issue with the Yeelighter plugin

https://github.com/cellcortex/homebridge-yeelighter/issues/31

[NorthernMan54]

@plantoschka Please update your yeelight plugin, change the name in the home app and this should be resolved. It may take a restart of node-red after changing the name for it to take effect.

[plantoschka]

I've now switched to homebridge-yeelight-wifi because it works more reliable for me but got the same problem. Individual lights appear with a different name but I would like to use the Moonlight Mode of each light and they all have the same name and therefore are not selectable.

I've seen there is a similar issue alread there: https://github.com/vieira/homebridge-yeelight-wifi/issues/66

[dxdc]

@plantoschka I'm not familiar with that plugin, but it looks like you can customize the names of your individual devices in the config? Might be worth experimenting with.

Either that, or you'll have to add such a feature to the plugin and/or rename the actual place that the plugin is pulling the names from.

      "defaultValue": {
        "aed78s": {
          "name": "Kitchen",
          "blacklist": ["set_hsv"]
        }
      }

[plantoschka]

@dxdc I've alread tried that. This did not work. Also when I rename it in Homekit or Homebridge the name does not change in Node-Red.

[dxdc]

@plantoschka it's your hb cache then, most likely. check your cachedAccessories file in homebridge. You may have to clear those stored names out. Node-red is just reading the names from homebridge. Changing them in Apple's Home app has no effect on any of this.

If you have jq installed, you can try something like this to see what's in there:

cat ~/.homebridge/accessories/cachedAccessories | jq

[plantoschka]

@dxdc Deleting the cache worked for the actual lights but not for the switch inside the light. These switches are still all named "Moonlight Mode".

[dxdc]

The problem looks like it might be here:

https://github.com/vieira/homebridge-yeelight-wifi/blob/5011aee3c870941d9c577c083a60127b2874de86/bulbs/moonlight.js#L16

I would contact the author of homebridge-yeelight-wifi and see about appending the accessory name there.

[NorthernMan54]

@plantoschka @dxdc This plugin needs the same tweak that was application homebridge-yeelight

ie To enable editing of the name in the home app, the 'Configured Name' characteristic in the device needs to be exposed. Similar to this

https://github.com/NorthernMan54/homebridge-tasmota/blob/00abb3acb5a3b023c34aa2341acc5492891f5d6f/src/platform.ts#L342

[genotrance]

I have the same issue with Shelly 2.5 switches. Both channels show up with the same name as the overall switch and there's no way to get status from or control both channels.

Edit: the Homebridge Shelly plugin is able to rename accessories as mentioned in this issue. Steps:

• Update homebridge config as documented in that issue for each device
• Stop homebridge, delete the accessories cache and start it back up
• Restart node-red to pick up the name changes
• Update all nodes that referred to the old names and deploy