How to determine the correct ACL entries

[A-vesalius]

Version

matter-server/0.5.13 (matter.js/0.17.0-alpha.0-20260402-bd064abc8)

Node.js Version

Latest

Operating System

Home Assistant OS

Issue Description

Have orphaned ACL on a node, left there from a bug in the original Python Matter server binding feature that did not delete the ACL when deleting the binding (#1198). The nodes ACL storage is now full and is out of write space for new ACL with no way to delete those orphaned. Matterjs server now better handles reporting of this error (#179), but I am left with no way to delete them.

The orphaned ACL can be seen below with the help of Matter Binding helper:

Steps to Reproduce

Request in addition the improved error reporting added #179 and the delete mechanism of #474 to have a mechanism to delete ACL without an associated/paired target node or even the ability to delete/replace a working binding from the node without storage space and its target node at the user discretion.

If a user attempts to set up a binding and either of the nodes return an ACL storage full error then Maybe the users could be presented with the option to replace one of the existing working or orphaned binding/ACL present on the full node (shown as a selectable list to the user).

Server Logs

Let me know what logs can help.

Device Information

No response

Additional Context

No response

Pre-submission Checklist

• I am running an Alpha/Beta version of the Matter.js server
• I have included the complete server logs (not truncated)
• I have checked existing issues to avoid duplicates

[Apollon77]

but this UI there is not from the matter server itself, or? I could imagine we can build a "verify bindings" feature but need to think about that. or we do "reset binding" to clear it and so you could re-add it?

[A-vesalius]

Correct the UI pictured is from ha-matter-binding-helper. Currently that is the easiest way for me to find these orphaned ACL.

A process to verify ACL/Bindings would be great. Later as part of a larger undertaking, use that verify process maybe have a Bindings Dashboard View that would list all the current established Bindings, with some visual indication of the nodes using them. Those with orphaned ACL (the node referenced in an ACL is either no longer present or does not have correct 2 way setup) would be highlighted some way as broken/not working and a user could delete that ACL/binding from the dashboard view. Users could also delete working binding from there or setup new ones, as matterjs server, would be able to discern which nodes have a bindings cluster and which do not.

[jvmahon]

It seems there is a need for some kind of a maintenance / startup "check and confirm bindings" type function that checks each node to see if it is configured as being bound to something else, checks if that "something else" still exists and is bound correctly, and deletes the bindings if there is not a correct connection still existing.

[A-vesalius]

It seems there is a need for some kind of a maintenance / startup "check and confirm bindings" type function that checks each node to see if it is configured as being bound to something else, checks if that "something else" still exists and is bound correctly, and deletes the bindings if there is not a correct connection still existing.

Yes, something that runs in the background similar to update checks. Runs at some predefined interval after startup is finalized and then like every 12 hrs to 24 hrs thereafter. Would then prefer the user is alerted in some way and can decide to delete, fix/replace, or skip/ignore, much like an OTA firmware update.

[Apollon77]

Yes and no ... Ideally, and this is planned but I did not had time yet, the matter server has internal management of groups, bindins and also scenes and expose this as convenient functions. No one should be needed to manually handle ACLs and "connected entries" and all this here shows that it is better to not expose that. So the goal is to have this all being handled conveniently by the server and then the server cares that all is right and noone else.

[A-vesalius]

Yes and no ... Ideally, and this is planned but I did not had time yet, the matter server has internal management of groups, bindins and also scenes and expose this as convenient functions. No one should be needed to manually handle ACLs and "connected entries" and all this here shows that it is better to not expose that. So the goal is to have this all being handled conveniently by the server and then the server cares that all is right and noone else.

What happens when a node is removed while a binding is in place, for whatever reason, device unexpectedly fails or breaks for instance ... What happened to the orphaned ACL then?

[olavt]

I haven't looked into this in detail, but I would be a bit skeptical to put too much logic into matterjs-server, I think logic like cleaning up should belong to a layer on top of matterjs-server. I guess in many cases matterjs-server would not have the required knowledge to know when to clean and when not to. matterjs-server should as much as possible mirror the underlying Matter protocol behavior.

[Apollon77]

In the near future it will have all this knowledge, but not now ...

For now I plan to add a "ACL management view" into the dashboard that shows what it seems and maybe adds a questionmark when an ACL makes no sense or such ... lets see if that works