Allow Hierarchical Endpoint structures#192
Conversation
|
PS: The PR also introduce that the "devicesList" in the descriptor needs to be able to be an array because e.g. when adding Bridged Devices an endpoint needs to have multiple device types |
…oint is added @mfucci I'm sure you have typing comments ;-)
|
@mfucci PR updated to latest main branch with your fabric changes |
|
@mfucci PR updated baed on your comments/questions and questions also answered the DEVICE -> DEVICES I would do in my followup PR because else gets too messy locally :-) |
|
PS: after #193 bridge pairing with my local version based on this PR is also working on ios |
|
@mfucci Please maybe also have alook at Apollon77#1 ... this is then the "followup" to use the new structure ... it got a bit strange with now branch on branch because I still work on my fork :-( And because Branch chains are cool I also added Apollon77#2 as even next step which adds a "bridged device executable" (working iOS and Google, not Amazon) |
In preparateion to implement Agrregator and Bridged Devcies the Endpoiint structure needs to be more hierarchical to easiely allow structures like shown in Core Specs pg 476 (and following).
All data, and especially the partsList is "bubbled" fropmbottom to top as requitred by the specs.
The next step after the PR ws merged is a second PR that adjusts InteractionServer to use it instead of the current flat logic.
The tests show already how it would "look like" later then basically and cover the "current" simply endpoint case as well as some more complex ones taken from the Bridged Nodes examples.
In this case I also found two "bugs" (OptionalWriteableAttribute - already made also PR to matter.js, and naming for the BridgedDevice cluster).
I also verified that with this code (assuing InteractionServer changes from next step done alteady too) still works for the current simple endpoint usecase on Alexa