isBridged & uniqueIdentifiersForBridgedAccessories not set for bridged matter accessories and the respective bridge device

before these updates both were set as expected.

SO, I have a few different questions here:

• Have you filed a bug on this and, if so, what is the bug number? If you haven't, please file one and post the bug number back here.

• Is this an accessory you create/manufacture or a 3rd party accessory? Similarly, are seeing this on one particular accessory or multiple accessories?

• What's the specific accessory(s)involved? If you'd prefer to keep that information private, that's fine but please include it in the bug I asked about.

Next, commenting on a few details:

since macOS 15.5 and iOS 18.5 bridged matter devices have isBridged set to false and the respective bridge device has an empty uniqueIdentifiersForBridgedAccessories list.

Just to clarify, what do you mean by "bridged matter devices"? The standard usage is that a bridge acts as the go between between matter (or HAP) and some other protocol as, for example, a ZigBee to matter bridge, so I'm not sure how you mean "bridged matter accessory".

Note that what's actually happening here:

the respective bridge device has an empty uniqueIdentifiersForBridgedAccessories list.

...is that, under the hood, there is in fact ONLY one accessory that HomeKit/Matter actually interact with, which is "the bridge". The other "accessories" HomeKit presents do NOT actually exists, they're actually "invented" by taking the various endpoints the bridge declares and presenting those endpoint as new "accessories" within the API.

That's also how this can could happen:

i also noticed that the bridged matter devices include all endpoints for all bridged devices. not only the ones for themselves.

If "something" (in the accessory or in HomeKit) was wrong with how the bridge presentation was interpreted, then what your seeing is exactly what I'd expect to happen. Putting that another way, a "matter accessory" is basically a collection of endpoints, while a "matter bridge" is just a matter accessory plus some other configuration information the describes how those endpoints should be presented as separate accessories.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

kevin,

thank you for the quick response. I have not yet filed a bug but will do so.

I'm sorry if my description was not complete enough. I will try again:

the problem hast two parts:

1. isBridged & uniqueIdentifiersForBridgedAccessories not set
2. all endpoints appearing on all devices

both are released accessing devices primarily through the HomeKit api and then accessing addition information by matterNodeID from there.

Just to clarify, what do you mean by "bridged matter devices"? The standard usage is that a bridge acts as the go between between matter (or HAP) and some other protocol as, for example, a ZigBee to matter bridge, so I'm not sure how you mean "bridged matter accessory".

what I mean is the following

• matter bridge: device that exposes other devices that not necessarily use matter to the mater eco system.
• bridged matter device: device that is exposed via a matter bridge to the mater eco system but itself using some other protocol.

Note that what's actually happening here:

the respective bridge device has an empty uniqueIdentifiersForBridgedAccessories list.

...is that, under the hood, there is in fact ONLY one accessory that HomeKit/Matter actually interact with, which is "the bridge". The other "accessories" HomeKit presents do NOT actually exists, they're actually "invented" by taking the various endpoints the bridge declares and presenting those endpoint as new "accessories" within the API.

that is not what I have seen and not what I'm expecting. each HomeKit device has its own unique matterNodeID. regardless of it being the bridge or a bridged device.

...is that, under the hood, there is in fact ONLY one accessory that HomeKit/Matter actually interact with, which is "the bridge". The other "accessories" HomeKit presents do NOT actually exists, they're actually "invented" by taking the various endpoints the bridge declares and presenting those endpoint as new "accessories" within the API.

they might be 'invented' but that is not how they are exposed by the HomeKit api. they appear as 'normal' accessories that are controllable.

for 1.:

I'm seeing this on accessories from matterbridge (https://github.com/Luligu/matterbridge).

i have just now also added a bosch smart home bridge via matter to HomeKit and there the problem is absent. so maybe there is something else causing the problems with matterbridge.

i will recheck a few things and come back to this.

for 2.:

when adding a matter bridge via HomeKit the devices that are visible with the HomeKit api are: a bridge device and 0-n bridged devices. all of them having a matterNodeID that allows drilling deeper into the matter side of things.

the matter bridge will have endpoints for itself and via the aggregator device type and additional endpoints for the bridged devices using 0x0039 bridged device basic information clusters.

the bridged devices in HomeKit also have a matterNodeID and drilling deeper there will result in exactly the same endpoints that you get for the bridge device.

a bridge device with a contact sensor and a thermostat will have endpoints for itself, the list of bridged devices (contact sensor and thermostat) and for each bridged device (contact sensor a thermostat).

the contact sensor will have exactly the same. it will include the endpoints for the bridge and for the thermostat. the thermostat will have the endpoints for the bridge and the contact sensor.

I think the bridge should have all endpoints and the bridged devices should have only the endpoints for themselves not for the bridge and everything else.

they might be 'invented' but that is not how they are exposed by the HomeKit api.

Yes. What I described is how HomeKit works internally and why you're seeing what you're seeing.

In any case based on this:

I'm seeing this on accessories from matterbridge(https://github.com/Luligu/matterbridge).

This is an uncertified matter implementation.

i have just now also added a bosch smart home bridge via matter to HomeKit and there the problem is absent.

This is certified accessory.

Adding some context, part of what the certification process involves is validating the accessory configuration as well as functional behavior. That validation process is what helps ensure compatibility between accessories and controllers- accessories are required to match the expected configuration and controllers are expected to work correctly with accessories that match the specification. More to the point, the configurations the certification process validates are the configurations controllers are designed and tested with.

so maybe there is something else causing the problems with matterbridge.

The risk with uncertified accessories is that they aren't necessarily in full compliance with the matter specification. That could be accidental (because some detail was overlooked) or intentional (because they couldn't implement the behavior they wanted while still being in full compliance). Either way, if the configuration is not in full compliance, the behavior of the controller (in this case, HomeKit) is not well defined.

thank you for the quick response. I have not yet filed a bug but will do so.

Thank you and please post the bug number back here when you do. At this point I suspect the issue is with matterbridge but it's still worth us validating this from our side as well.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware