Add nameBasedUniqueId for stable device identification across re-pairings

[Copilot]

• Add nameBasedUniqueId field to ServiceType interface in interfaces.ts
• Compute nameBasedUniqueId in index.ts using stable fields joined with | delimiters
• Sync branch with latest beta-3.3.1 changes (monitor fix, dependency updates)
• Add .github/copilot-instructions.md with note to always update CHANGELOG with code changes
• Add changelog entry for nameBasedUniqueId feature under existing v3.4.0 release
• Build and tests pass (19/19)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>HAP-Client uniqueId is different when a device is removed then added, even though HomeKit thinks its the same device</issue_title>
<issue_description>### Current Situation

service.uniqueId = createHash('sha256')
.update(${service.instance.username}${service.aid}${service.iid}${service.type})
.digest('hex');

AID increments when a accessory is removed and added

Proposed Change

This creates the same token for the same device when deleting and adding - ${service.instance.name}${service.instance.username}${service.accessoryInformation.Manufacturer}${friendlyName}${service.uuid.slice(0, 8)}

Additional Context

No response</issue_description>

<agent_instructions>When resolving this issue, pls create a new variable, 'nameBasedUniqueID', and to maintain backwards compatibility pls do not change uniqueID</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@bwp91 @NorthernMan54 could we revisit this proposal again? it would be really helpful for the UI if accessories always had the same unique id. @NorthernMan54 @bwp91 definitely, let me look at the dependant projects to see about usage etc

One challenge with changing a unique ID definition is that all the devices will appear as new on implementation. Which will cause issues for the dependant projects.

But I recall over riding this, so it may be a non issue.</comment_new>
<comment_new>@NorthernMan54
Checking dependencies, only UI, GSH and Homebridge-automation use this package

Homebridge-automation overwrites the supplied unique ID - https://github.com/NorthernMan54/node-red-contrib-homebridge-automation/blob/f5bf77077439179325bbf01367f8c4dcd8f23e57/src/hbConfigNode.js#L70

GSH - And it is overwritten here as well, but with the broken approach - https://github.com/homebridge-plugins/homebridge-gsh/blob/f499173ed59952e274d773a5c01d9651ac8ea0f9/src/hap.ts#L381

When I refreshed GSH, I did not change the uniqueID logic, as it would break the setup of all existing users.....

So we can go ahead with this, and I will do a test of the packages when it is in Beta</comment_new>

• Fixes HAP-Client uniqueId is different when a device is removed then added, even though HomeKit thinks its the same device #15

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[NorthernMan54]

@copilot Pls rebase this PR

[Copilot]

@copilot Pls rebase this PR

Done in commit 311000d. Since force-push isn't available in this environment, I applied the upstream changes from beta-3.3.1 (3a0aea5 monitor fix + 5fe1273 dependency updates) as a new commit. The branch now includes all changes from beta-3.3.1 and all tests pass.

[NorthernMan54]

@copilot please update the repo instructions with a comment that the change log should be included in changes.

Also pls include the new feature in the changelog

[Copilot]

@copilot please update the repo instructions with a comment that the change log should be included in changes.

Also pls include the new feature in the changelog

Done in commit 89357fe. Created .github/copilot-instructions.md with a note that changelog updates should be included with all code changes, and added a changelog entry for the nameBasedUniqueId feature under v3.4.0 (unreleased).

[NorthernMan54]

@copilot pls correct your changelog update. It created a new release.

[Copilot]

@copilot pls correct your changelog update. It created a new release.

Fixed in commit 4ff0ac5. The nameBasedUniqueId entry is now added to the existing v3.4.0 (2026-02-24) section instead of creating a duplicate release.