Feedback/Bug: Matter Server Topology Graph :: History Retention Causes Network Role and Status Confusion

I’ve been testing the new Matter Server topology graph/visualizer, and while the visual updates are a fantastic addition, I am running into some stability/performance issues alongside significant confusion regarding how historical node data is managed.

Currently, the visualizer seems to aggressively retain historical states (roles, connections, and node tags) for offline or changed devices instead of reflecting the real-time state of the mesh. This data persistence makes it highly difficult to diagnose the actual network topology.

Here are the three main consistency issues I’ve observed:

  1. When I power down the device currently acting as the Thread Leader, the underlying network performs exactly as expected: a new Leader is elected, and the old node goes offline. However, in the visualizer, the turned-off node turns red (offline) but still retains its "Leader" badge. This makes it incredibly confusing to determine which node is the actual, active Leader of the network.

  2. When powering off a parent Router, its Child End Devices successfully find a new parent node in reality (verified via the node logs). The firmware and network handle this perfectly. However, the visualizer does not update this connection. The child nodes still point to the old, offline parent in the UI, failing to reflect the active parenting topology.

  3. Because offline nodes hold onto their last known historical connections, the graph is cluttered with "ghost" links. This makes it very difficult to map out the active routing paths or trust the displayed RSSI and LQI metrics, as stale data corrupts the current real-time view.

The visualizer appears to mix historical discovery data with live runtime data without clear separation. When a node changes state or drops offline, its historical role, tags, and connections persist, leading to a misleading representation of the network.

One solution is to re-interwiew the nodes in the list view.

I don't know if, or how often this is done automatically, but doing it manually helps to correct the topology view.

1 Like

Thanks for the suggestion! but here’s the issue: since the offline device is completely down/unsubscribed, it can’t respond to a reload or re-interview anyway.

The active routers update fine through the network, but the offline node just holds onto its cached historical data in the UI with no way to clear it out manually. That’s what is causing the confusion.