English is currently available.
Zigbee, Thread & Matter DISCUSSION
I am experimenting with OpenThread on three nRF52840 dongles plus a border router on a Raspberry Pi. When I unplug the dongle that the command line shows as "leader", the others take over after a while, but I do not understand what roles exist or how long recovery is supposed to take.
What are the device roles in Thread, what happens when the leader or a router disappears, and is the border router a single point of failure like a Zigbee coordinator?
Thread has two broad groups. Routers keep their radio on, forward packets and accept children. End devices attach to one router (their parent) and do not forward. End devices come in several kinds: a full end device keeps more network state, a minimal end device keeps its receiver on, and a sleepy end device turns the radio off and polls its parent for queued messages at an interval you choose.
A device that could be a router but is currently attached as an end device is a router-eligible end device (REED). The network promotes REEDs to routers and demotes routers by itself to keep a sensible number of them; a Thread network has at most 32 active routers.
The leader is not a coordinator in the Zigbee sense. It is simply one of the routers, chosen automatically, that manages router ID assignment and distributes network-wide data such as the prefixes announced by border routers. It holds no unique credentials. If it disappears, the remaining routers notice that its advertisements have stopped and one of them takes over the role; no user action or re-pairing is needed.
Recovery is not instant because it is driven by a timeout. The default in the Thread specification and in OpenThread is 120 seconds without hearing from the leader, so waiting a couple of minutes after pulling the plug is expected behaviour, not a fault.
For a lost router that was not the leader, the mesh reroutes more quickly. Routers exchange link and route information in periodic advertisements (MLE, Mesh Link Establishment) and choose paths by link cost, so neighbours stop using the dead router once its advertisements age out. Children of the dead router have more to do: a child detects the loss when its polls or keep-alive messages go unanswered, then searches for a new parent and re-attaches.
For a sleepy device the detection time depends on its poll period, so a sensor that polls every 30 s takes longer to notice than one polling every second. That is the trade between battery life and recovery time.
The border router is a router with a second interface (Wi-Fi or Ethernet). It forwards IPv6 packets between the mesh and your home network, advertises the prefixes that make the mesh reachable, and provides service discovery so that devices on Wi-Fi can find Thread devices. The mesh itself keeps working without it: Thread devices still reach each other, they just cannot be reached from outside.
It does not have to be a single point of failure, because a network may have several border routers. In practice, border routers from different vendors have often formed separate Thread networks instead of sharing one, so check that yours really joined the same network (same network name, extended PAN ID and network key) rather than creating a second one.
Some numbers explain the design. An 802.15.4 frame carries at most 127 bytes, while IPv6 requires links to support 1280-byte packets and has a 40-byte header. Thread uses 6LoWPAN to compress the IPv6 and UDP headers to a few bytes in the common case and to fragment larger packets across several frames. That is why applications on Thread use small UDP messages (CoAP, or Matter's own messaging) rather than chatty TCP connections.
When you test healing, watch it from the OpenThread command line: state shows the node's role, router table and child table show who is attached where, and leaderdata shows which leader the node currently follows.
