However, the current implementation is a bit suboptimal, in that it always reports everything, regardless whether any of the attributes reported by the subscription are actually changed.
I also believe that the existing ChangeNotifier idea, which is somewhat implemented throughout the code (but unfinished), might not have a future, as I don't see it helping in anyway to solve the problem:
When we get a write or invoke command from a remote peer, we are anyway notified via the AsyncHandler callbacks.
When we are modifying the data ourselves, we actually know we are doing this, so we don't need an eager notification from the cluster calling back into us, when the cluster dataver is changed
I think something more fruitful would be if the notification is traversing all clusters it reports on, and trying to detect (possibly by comparing against a preserved set of datavers, or a simpler -hash-based derivation of multiple datavers) if there are changes or not.
Since the merge of https://github.com/project-chip/rs-matter/pull/147 , we now do have subscriptions and we do report on these.
However, the current implementation is a bit suboptimal, in that it always reports everything, regardless whether any of the attributes reported by the subscription are actually changed.
I also believe that the existing
ChangeNotifieridea, which is somewhat implemented throughout the code (but unfinished), might not have a future, as I don't see it helping in anyway to solve the problem:writeorinvokecommand from a remote peer, we are anyway notified via theAsyncHandlercallbacks.I think something more fruitful would be if the notification is traversing all clusters it reports on, and trying to detect (possibly by comparing against a preserved set of datavers, or a simpler -hash-based derivation of multiple datavers) if there are changes or not.