Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Bridge UUID based on persistent data #396

Open
Shaquu opened this issue Apr 27, 2021 · 2 comments
Open

[Feature Request]: Bridge UUID based on persistent data #396

Shaquu opened this issue Apr 27, 2021 · 2 comments
Assignees
Labels
enhancement 👍 New feature or request

Comments

@Shaquu
Copy link
Member

Shaquu commented Apr 27, 2021

According to Hap docs some fields should be persistent through the life of an Accessory (or Bridge).
It is why it was also planned to use those fields' id creation:
image

Looks like this is not implemented for Bridge.
Implementation must be backward compatible.

self.bridgeUsername = macify(self.id)
const hostUUID = uuid.generate(self.id)
const hostTypeName =
self.hostType == HostType.BRIDGE ? 'Bridge' : 'Standalone Accessory'
log.debug(`Creating ${hostTypeName} with UUID ${hostUUID}`)
if (self.hostType == HostType.BRIDGE) {
self.host = new Bridge(self.name, hostUUID)
} else {
self.host = new Accessory(self.name, hostUUID)
}

@kevinkub
Copy link
Contributor

I finally understand what you mean. As I do not see any possibility to check wether a node has just been added or if it was in the flow already, how about introducing a flag in the config like useHapConformIdentifier that defaults to true and is invisible in the user interface? That way, the property should be true for any new nodes that were added after an update of nrchkb and null for the legacy ones. As an alternative the version number at the time of a nodes creation could be added, but I wonder if that makes the code less readable and if there is really a second use case for a property like that.

@Shaquu
Copy link
Member Author

Shaquu commented Apr 27, 2021

It is second case in the last time :)
And more cases are coming as big features will land soon. Breaking compatibility is not an option until it is related to general stability.

So I believe adding version field (which we already have available in UI side :) ) is a good idea. This field could be either hidden or read only for user knowledge.

@crxporter crxporter added the enhancement 👍 New feature or request label Oct 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 👍 New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants