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: isBridged & uniqueIdentifiersForBridgedAccessories not set 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.

@LaserPuzL check the matter specification for the exact format that is required. invokeCommand expects a struct. this has to be represented with NSMutableArray and NSDictionary three or four levels deep. as a api user i would say this was not the best choice for the interface. @DTS Engineer i'm not sure i unterstand why enabling subscriptions would result problems with the load on the accessory. i would even argue that subscirbing to events through homekit would result in less load on the device and the radio side as everything is tunneld through one instance and hast to be send only once from the accessory. and of course it is much more efficient than polling everything again and again. it would be great if this could be reconsidered. especially as the subscription to events basically the only way an app can support devices and features not (yet fully) supported by the platform. my use case is an app (which has just been released in a first version) that allows browsing all homekit (and matter) internals of all devices in a 'home' and allowing power users to see and tweak what is there. not only what the home app exposes. creating a ecosystem might be a hurdle to high even for these users. also a separate ecosystem would not allow seeing what exactly is in the 'normal' home. anyway: your replys are much appreciated. and i hope there is a possibility to broaden the availability of features that are exposed with the homekit bridge. one more thing: i have noticed that reading all attributes for all clusters and all endpoints in scenarios where devices are bridged as described in the matter core specification 'Bridge for non-Matter devices' all devices will get return the full set of all endpoints for all devices. not only for the bridge device and then only a subset for the individual brididged devices. i think it would be better and more efficient to only return the endpoints related to each specific device respectively. should this intended or should this be reported?

sorry for the long silence... there were some other things i had to do. @LaserPuzL: what got me on the right track is the comment at the very beginning from the Matter.MTRBaseDevice file. you can get there by using 'Jump to Definition' from the context menu on a related matter keyword in your source. it explains how to exactly decode the readAttribute response. this is the only place i have found that explains the encoding at all. i think some of the other code examples i found work more or less by accident only. just exactly reverse this using the correct datatypes described and it just works for invokeCommand. now i will continue to try to get subscribe working :).

thank you again. very much appreciated. i will check and report back / file reports.

thank you for checking this out. actually this is my bug report also :) in the meantime i have implemented my own version. so i can continue while waiting for an official fix. could you please also have a look here: https://developer.apple.com/forums/thread/757458?answerId=810679022#810679022 i can‘t get subscription to events working. this is the last puzzle piece and stumbling block for my project now that i can read all attributes and write commands with and without parameters for homekit initialized matter devices. or would it be better to open a new post instead of reusing the old one?

found the correct encoding for parameters. so invokeCommand now works for me also. so the only one still missing is subscription to events. and the missing data for attribute 0xFFFA

i did another fix to the commanfFields to get on/off/toggle to work. basically every command without data fields. but i can not figure out how to encode a parameter... besides the encoding only the subscription seems to be still open for me.

the invokeCommand error from above might have been a problrm with the commanfFields. now that i changed this a little i get absolutely no reaction. no error, no data. like subscribe. so again the question: is anything besides reading the attributes supposed to work when using the homekit provided data?

does anyone know what is supposed to be working for an MTRBaseDevice initialised from homekit? i did some more test... i can use readAttributes and read everything from the device. good. except: i never get data for attribute 0xFFFA which should be the EventList. does this indicate that the MTRBaseDevice initialised from HomeKit is not capable of generating events? all other global attributes 0xFFF8-0xFFFD except 0xFFFA return the expected data. also: when i try to use invokeCommand to initiate an identify or off command. this also does not work and results in Error Domain=MTRErrorDomain Code=4 "An argument is invalid." UserInfo={NSLocalizedDescription=An argument is invalid.}. does this indicate that the MTRBaseDevice initialised from HomeKit is readonly? on the other hand using an MTRBaseClusterOnOff initialised from the same MTRBaseDevice allows me to use toggle without any problems. so it seems not to be readonly...

sorry. yes. i was talking about MTRAttributeNameForID. but with swift. from the documentation here: https://developer.apple.com/documentation/matter/mtrattributenameforid(::) if i read the documentation correctly your example should read MTRAttributeNameForID(MTRClusterIDType.basicInformationID, MTRAttributeIDType.clusterApplicationBasicAttributeVendorNameID which gives <Unknown clusterID 40> for me. and i have the same behaviour for every MTRClusterIDType and MTRAttributeIDType initialised from raw values. on the other hand MTRClusterNameForID with a MTRClusterIDType initialised the same way gives a reasonable result.

i'm running into the same problem. none of the subscribe methods work. the primary one mentioned above gives error 48, the other ones never confirm subscription or give any other results. during my trials yesterday i might have seen a single subscription confirmation from one of them but unfortunately i can't reproduce the circumstances. also there i never got a change reported.

a use case for this would be a context menu for an image that allows the user to change this icon by choosing from a list of sf symbol images. or something like an emoji picker i have found the current limitations for catalyst swiftui context menus are a problem more than once.

yes. the same here. homekit using catalyst and compiled on ventura currently does not work on any ventura version, using made for ipad works fine. catalyst version compiled on mac os 12 also works on ventura.