-
|
ANSWER: Add endpoints to an aggregator first, then start the server. Never remove & re-add endpoints while running. Apple considers these as removed/new endpoints. I'm having trouble maintaining my Endpoints, which are attached to an AggregatorEndpoint, in the same room in Apple Home. They get re-added to the default room. Similarly, in Google Home, the message that a new device has been added. I keep using the same IDs everywhere. Am I missing something? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 14 replies
-
|
With the info above I can imagine two reasons: Matter.js maintains the structure and endpoint assignment by the "id" you set on the endpoints, so basically this matter.js "internal string based id". In fact you also see the endpoint number in the log. When endpoint numbers increase with every start then likely you somehow mix up. the Ids. 2.) You bring up the node before all existing endpoints are added. So if it happens that you start the node and add endpoints afterwards then the ecosystems see the bridge without the endpoints, so they remove them on their side, then you add them ad so they get readded, but for the ecosystems they are new then. Basically provide a debug level log from matter,js from two starts in a row wit a small shutdown and pause where exactly that effect happened and I can have a look and maybe guess more. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, as always! ^.^ It seems that #2, starting the server after adding the endpoints, has indeed solved the issue. I would have never figured this out on my own. Thank you so much! |
Beta Was this translation helpful? Give feedback.
-
|
On another note; I often cannot change the Matter.js-paired devices' room in the Apple Home app. It errors with So I wonder if there's something missing in my or Matter.js' implementation to respond to such an event maybe? I would find it strange, because managing rooms shouldn't be part of Matter, but who knows... |
Beta Was this translation helpful? Give feedback.
-
|
Room assignments are not supported really in matter at all, so these things are all HomeKit internally ... And I also never really had other reports of such issues. You can validate by having matter.js log running when seeing such an error to see if there is any interaction on matter level. I would assume it's not |
Beta Was this translation helpful? Give feedback.
-
|
Our users have pinpointed when it happens here: athombv/com.athom.matter-bridge#11 (comment) This executes the following code while the server was already running: // uninit
await deviceEndpoint.delete();
// re-init
deviceEndpoint = new Endpoint(BridgedNodeEndpoint, {
id: device.id,
bridgedDeviceBasicInformation: {
nodeLabel: ellipseString(device.name),
vendorName: ellipseString(driver?.ownerName ?? 'Unknown'),
productName: ellipseString(driver?.name ?? 'Unknown'),
serialNumber: ellipseString(device.id.replaceAll('-', '')), // Max length is 32, so if we remove the dashes from the UUIDv4, it fits!
},
});
await this.aggregatorEndpoint.add(deviceEndpoint);Then Apple Home probably thinks it's a new device, regardless of the What would you recommend, @Apollon77 , to re-initiate a device without calling these methods? Maybe remove and re-init all OnOff etc. endpoints from the 'deviceEndpoint' Endpoint? |
Beta Was this translation helpful? Give feedback.
-
|
This will not work. If a device goes offline you should keep it in the structure but mark it as unreachable in the BRidgedNodeBasicInformationCluster Formally "changing its capabilities" is not supported by Matter as of today! Formally this must not happen and in fact there are no guarantees what an ecosystem will do or not. And thats also the reason why we do not have a way to "replace" endpoint or such as of now.
|
Beta Was this translation helpful? Give feedback.
-
|
Alright, thanks, I see how that can work as a workaround. But... restarting my app will initialize the same device with the same Endpoint ID but with new capabilities, and so far I've seen Apple Home pick it up just fine. So I think it would still be useful to support removing endpoints while running, event hough Matter's spec doesn't say anything about it? |
Beta Was this translation helpful? Give feedback.
-
|
I clearly understand your point. Now we come. bit in "working around things" area... Yes I know that you can actually do that (and we needed to add special logic to accept this to ignore data from the past in storage and such stuff), but it is still completely undefined what happens in which ecosystem, and there are some more then just apple :-) it is also a difference for many controllers when data come in after a "complete reconnect and so a new subscription gets all data fresh" vs "during runtime partial changes happen that also end as "partial subscription updates". So I have no idea if Apple would also handle this that good (and also honestly never tried it). Our goal is also to provide a solution that can be certified against the Matter specifications at any timepoint, so it is also a question to ensure that "just because it might work somehow but formally breaks specs" thing not happen unplanned and can break certifications or make issues with ecosystems. So the usual mixture of "giving freedom to developers", "protecting all parties from too strange stuff","protect users from strange user experiences", "staying close to the standard"... We have the topic on our list to revisit when the ConfigurationVersion joins the game because then there are official ways on what is allowed to change how and also how ecosystems should react to this. Then the whole topic becomes a bit more "defined" and "allowed" and also ecosystems need to expect these things to happen. Then we need to see how we do all that anyway. |
Beta Was this translation helpful? Give feedback.
-
|
I completely understand you and I would've probably said the same! Alright, I'll work with this. For now my problem of devices losing their room in Apple Home seems to be solved by just never removing the endpoint and re-adding it in the same session. Thank you for all your time! <3 |
Beta Was this translation helpful? Give feedback.
-
|
Sure, always! And as said we will release 0.16 likely tomorrow (if I not find more edge cases to fix). |
Beta Was this translation helpful? Give feedback.
-
|
I cannot seem to figure out how to remove an @Apollon77, maybe you know how? |
Beta Was this translation helpful? Give feedback.
-
|
Easy enough, thanks! Is there a difference between close() and delete()? And now I have to keep my own reference of endpoints. Can I get/loop endpoints on a node? |
Beta Was this translation helpful? Give feedback.
-
|
Hm, actually, when registering a new endpoint with the same ID after calling |
Beta Was this translation helpful? Give feedback.
-
I think we fixed that error in 0.16, but not sure. I guess you use 0.15 right? maybe try latest nightly. If still an issue there please report as issue. We are also very short before the 0.16 release, so current nightly is very close to release version. |
Beta Was this translation helpful? Give feedback.
-
|
I'm getting the same error with 0.16.0-alpha.0-20260106-e9e9ba80c. |
Beta Was this translation helpful? Give feedback.
-
|
Then please open an issue with reproduction details |
Beta Was this translation helpful? Give feedback.
With the info above I can imagine two reasons:
1.) "Endpoint IDs" get somehow mixed up
What exactly you mean with "the same IDs everywhere?
Matter.js maintains the structure and endpoint assignment by the "id" you set on the endpoints, so basically this matter.js "internal string based id". In fact you also see the endpoint number in the log. When endpoint numbers increase with every start then likely you somehow mix up. the Ids.
2.) You bring up the node before all existing endpoints are added. So if it happens that you start the node and add endpoints afterwards then the ecosystems see the bridge without the endpoints, so they remove them on their side, then you add them ad so they get …