[openthread_border_router] Migrate OpenThread settings when switching between beta/stable

[puddly]

I noticed that the binary format has not actually changed for OpenThread itself: no new fields have been added, just the internal version has bumped from 4 to 5. We theoretically can just tweak this value to keep OpenThread from regenerating Thread network information.

Note that the active dataset isn't changed in the current addon state, just the Thread network information. This will result in devices rerouting a little since your border router effectively disconnects and another fresh one re-connects.

[puddly]

I've tested this a few times without any ill effects. Compared to Thread 1.3, Thread 1.4 proactively finds a child device within 15s of startup. It still takes about 60s for the Matter server to actually start communicating with devices though.

[agners]

I've tested this a few times without any ill effects. Compared to Thread 1.3, Thread 1.4 proactively finds a child device within 15s of startup.

Was there any difference in speed with/without this change (with new extaddr?)

It still takes about 60s for the Matter server to actually start communicating with devices though.

This is a bit the beauty and the ugly of Matter/Thread: The network layer is completely separately. Largely, Matter doesn't know or care about how the Thread network underneath it reconnects/reestablish. So as long as the network addresses are still the same, a device can loose its Thread network intermittently, it will still be able to inform the Matter server about new events (motion or whatnot) instantly (given the network is available at the time of the event).

The Matter server only starts to look for the device if it does not get the subscription device check-in within the specified max interval (afaik, we use 60s for wall powered devices and 600s for batter operated devices). Similar on a device reboot: The controller (Matter client) needs to connect to the device (Matter server) and reestablish the subscription. However, in theory, the device has still all relevant information.

If the Thread border router was the designated SRP, devices should also reestablish the service registration. This causes a mDNS service announcement on the network, to which a Matter server might react.

That said, some devices persist the subscription, and pro-actively ping the controller after reboot to inform it of its new state. In this case the Matter subscription is immediately reestablished (I know that at least Nanoleaf bulbs do that).

I noticed that the binary format has not actually changed for OpenThread itself: no new fields have been added, just the internal version has bumped from 4 to 5.

Maybe this is a bit far fetched, but maybe the version has been bumped to force a extaddr change, to force some regeneration/recalculations in the Thread mesh 🤔 .

Anyhow, I guess if we don't see any ill effects, why not.