Cannot add a bridged Accessory with the same UUID as another bridged Accessory: undefined

Describe the bug Difficult to reproduce, I have it currently. I noticed it first in node-red-contrib-homekit-bridged, but after debugging for a while, it seems that although NRCHKB is only calling AccessoryUtils.getOrCreate once, the loop inside HAP-NodeJS to add it internally to the accessories in the bridge is looping twice and seems to have an index of “NaN” already in the fresh bridge with an empty array of accessories, which is causing it to “match” a non-existent UUID in the bridge and complain about an undefined UUID (when the UUID is defined in the accessory).

This seemed to “appear” in an installation I had been running successfully for a long time, then (all of a sudden, no changes, yeah- I know) and I was getting “no response” on all devices in homekit, so I removed the bridge from home.app but now cannot re-add the bridge, it doesn’t appear in the home.app at all.

a lot of debug leading to this issue being raised is documented in NRCHKB Issue 359

To Reproduce Seems to be only on my server, someone else running the same flow (as per test flow) seems to not get the issue.

Desktop (please complete the following information):

• OS: Rpi
• Node version: v14.15.4
• NPM version: 6.14.10
• NodeRed version: v1.2.7
• NRCHKB Plugin Version: 1.2.0
• NRCHKB uses HAP-NodeJS Version: 0.7.8

Additional context running debug

DEBUG=NRCHKB*,HAP-NodeJS*,Accessory,HAPServer,EventedHTTPServer node-red

I get a lot of these first in the debug output:

  NRCHKB:HAPServiceNode Starting Parent Service Pool 1 +6ms
  NRCHKB:AccessoryUtils Looking for accessory with service subtype '172f1edd-389b-4c45-96d4-47e37a130118'... +0ms
  NRCHKB:AccessoryUtils ... didn't find it. Adding new accessory with name 'Pool 1' and UUID '1316cdc7-e142-4a55-9a93-fea8fce35aa5' +0ms
  NRCHKB:HAPServiceNode Starting Parent Service Pool 2 +6ms
  NRCHKB:AccessoryUtils Looking for accessory with service subtype 'fd02bca6-d5c5-4777-9d45-73cea71e4b6d'... +0ms
  NRCHKB:AccessoryUtils ... didn't find it. Adding new accessory with name 'Pool 2' and UUID '4a78594b-60fa-470d-a192-cb14e75910e6' +1ms

Then a lot of these:

(node:30289) UnhandledPromiseRejectionWarning: Error: Cannot add a bridged Accessory with the same UUID as another bridged Accessory: undefined
    at Bridge.Accessory._this.addBridgedAccessory (/home/pi/.node-red/node_modules/hap-nodejs/dist/lib/Accessory.js:286:27)
    at Bridge.Accessory._this.addBridgedAccessories (/home/pi/.node-red/node_modules/hap-nodejs/dist/lib/Accessory.js:311:23)
    at Object.getOrCreate (/home/pi/.node-red/node_modules/node-red-contrib-homekit-bridged/build/lib/utils/AccessoryUtils.js:80:20)
    at configure (/home/pi/.node-red/node_modules/node-red-contrib-homekit-bridged/build/lib/HAPServiceNode.js:118:40)
    at preInit.init (/home/pi/.node-red/node_modules/node-red-contrib-homekit-bridged/build/lib/HAPServiceNode.js:38:13)
    at /home/pi/.node-red/node_modules/node-red-contrib-homekit-bridged/build/lib/HAPServiceNode.js:28:18
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:30289) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 21)

Note the UUID is shown as undefined - this is not correct, it is most certainly defined.

For more detail on the existing debugging leading to this conclusion, please refer to NRCHKB Issue 359

I think some config is “stuck” somewhere that I cannot seem to find, that pre-fills an “empty” new bridge accessory array with a “NaN” index. I think it’s worth debugging this to first resolve it and then work out how it could have happened, to ensure it doesn’t happen for anyone else.

[otaku]

Changes were applied to beta branch. I went ahead and did a few more non-breaking refactors. PR opened #879

[macinspak]

Thanks for the offer to help @Shaquu I’ve added you as a maintainer on my fork. I committed the changes to master before thinking, sorry, so we may need to just branch it and re-apply, then get it tested and working and submit the pull request.

I made a bunch of changes throughout to places I thought the issue could occur, pretty much any object key iterator was changed. It simplified code due to the iterator forEach pulling the value not the index, but it may not be working fine with npm test as it may be not detecting the object class properly.

Also, in some cases where it is looping through to find the match, then deleting it (for example), I switched them to .find logic with the same conditions in the filter.

I believe they should have the same intended post conditions for the searches and the return values on no match, but we just need to check each I guess for sanity and then make sure it’s compiling. If you can let me know how to build it to insert into my node-red instance, then I can test heavily.

The basic changes I made to prove the fix in my instance work to pair to homekit and take instructions, but the final state is stuck (not updating), but the changes in the repo included other sections, so once I test it I can see if it works for my use cases at least.

Thanks again for the help.