Salut @Cloom, merci pour ton retour ! Je me permets de nuancer, parce qu'il y a deux ou trois subtilités Thread qui piègent tout le monde (moi le premier).
« Pourquoi utiliser le SLZB si ça marche avec les autres ? »
Parce que dépendre des border routers Google/Apple, c'est dépendre de leur synchro de credentials via le cloud, de réseaux qu'on ne peut pas inspecter, et surtout d'un comportement qu'on ne maîtrise pas. Le cas classique : un Nest qui, après une coupure, régénère tout seul son réseau Thread (NEST-PAN-xxxx → Google-xxxx). Le jour où ça arrive, tous les appareils commissionnés dessus se retrouvent orphelins. Un OTBR qu'on possède (le SLZB), on voit sa topologie, on choisit le canal, on garde les clés, on ne dépend de personne. C'est ça l'intérêt, au-delà du simple « ça marche ».
« J'ai mis mon SLZB dans le même réseau que le Nest, donc si j'en débranche un ça marche quand même »
Sur le principe c'est faisable : deux border routers peuvent vivre sur le même réseau Thread, à condition de partager exactement le même Active Operational Dataset (même network key, même PAN ID, même canal). Mais deux gros bémols :
-
Le test que tu décris ne prouve pas la redondance. Si tes appareils ont été commissionnés via le Nest (le cas le plus courant), ils sont sur NEST-PAN et ne passent jamais par le SLZB — donc débrancher le SLZB « et ça marche encore », c'est normal : il ne portait rien. Et débrancher le Nest « et ça marche encore » ne prouve la redondance que si (a) tu as confirmé que tes appareils sont bien sur UN seul réseau partagé par les deux BR, et (b) tu as attendu plusieurs minutes la reconvergence Thread — pas juste un test instantané, parce que les routes et les contrôleurs Matter gardent des caches qui font croire que ça tient alors que ça va lâcher.
-
Même si ça marche aujourd'hui, ancrer ta redondance sur le réseau du Nest est fragile : le jour où Google régénère son réseau, ton SLZB reste bloqué sur l'ancien dataset (mort) et la redondance disparaît en silence — tu ne le verras que quand quelque chose cassera. Et accessoirement, mélanger des BR de marques différentes sur le même réseau est un cas connu d'instabilité Matter dans HA.
L'approche propre, en général; La vraie redondance qu'on maîtrise, c'est deux border routers qu'on possède (par ex. deux OTBR) partageant le même dataset, et commissionner les appareils sur CE réseau. Le Nest devient alors jetable : il peut tomber, redémarrer ou régénérer son réseau, aucun impact. C'est l'inverse de s'appuyer sur lui pour la moitié de sa redondance. (Sous HAOS, faire tourner un 2e OTBR demande de passer par un add-on local, mais c'est un autre sujet.)
Pour vérifier que ta redondance est réelle (au lieu de te fier au « ça marche quand même ») : compare le PAN ID / le dataset que voit chaque appareil, confirme que tes deux BR ont bien le même Active Operational Dataset, puis débranche-en un, attends 5 bonnes minutes, et vérifie que les appareils restent joignables ET pilotables depuis HA. Fais-le dans les deux sens.
De mon côté, j'ai justement réglé mon souci en débranchant les autres OTBR pour forcer tout sur le SLZB — donc je suis vraiment curieux de savoir comment tu as fait rejoindre le NEST-PAN à ton SLZB MR1, parce que c'est précisément la manip délicate. Ça m'intéresse !
