[plugin-Zigbee BETA] Perte des nœuds après arrêt d'un routeur Zigbee

Plugins Protocole domotique
1

Bonjour,

Ayant basculé depuis peu sur le plugin Zigbee avec une clé EZSP, je viens d’être confronté à une problématique suite à l’arrêt hier soir d’un router Zigbee que j’avais ajouté pour tester.

En effet, les 3/4 de mes nœuds sont tombés dans la nuit provoquant même un arrêt des prises électriques ce matin.

J’avais ajouté le repeater Zigbee Tuya pour voir si cela améliorait le réseau et notamment le maillage :
image

Après m’être rendu compte que cela changeait pas grand chose (je suis en appartement, je n’ai pas une grande surfae), j’ai décidé de l’enlever, ce qui a fait tomber tout les nœuds par la suite. Seuls 2 ou 3 sont restés associés. Par ailleurs, il n’y avait pratiquement aucun nœud sur les routeurs, juste 1 ou 2, tous les autres étaient directement sur le coordinateur et j’ai l’impression que tous ceux qui étaient sur le coordinateur sont tombés.

Faire une tentative de réveil des capteurs ne change rien, je n’ai eu aucun message dans le centre pour dire que des capteurs étaient partis. J’avais par ailleurs désactivé les logs de debug il n’y a pas longtemps, trouvant que le réseau était stable, du coup je n’ai pas de logs détaillés de ce qu’il s’est passé…

Une connaissance a eu le même comportement, perte de la moitié de ses capteurs sans raison apparente, mais je pense qu’un de ses routeurs (prise Osram) avait également été débranché pour faire une manipulation sur la prise électrique.

Avez vous remarqué ce comportement ? Comment trouver des informations / débuguer ?

Je n’ai jamais eu cette problématique avec le plugin Abeille sur un pizigate, dès que je coupais des routers Zigbee, les nœuds basculaient automatiquement sur le coordinateur ou sur un autre nœud voisin.

Je sais que le plugin Zigbee se base sur Zigpy et que c’est géré très différemment, mais cela est plutôt gênant, surtout si cela se produit pendant une absence ou autre et que plus rien ne fonctionne dans la maison…

Sinon je suis sur une clé EZSP, ai un PI4 et suis à jour; 4.1.20 pour Jeedom et dernière version du plugin.

J’ai cherché sur le forum les cas similaires mais n’ai rien trouvé de particulier avec le plugin Zigbee (et surtout, pas facile de s’y retrouver dans tous les messages sur la beta).

Quelqu’un a déjà été confronté à une situation similaire ?

Cdt,
Mick74

2

Bonjour,
C’est normal c’est le fonctionnement du zigbee (rien a voir avec le plugin), le routage est statique si un routeur est perdu les nœud dessus (end device) :

  • au mieux se reconnectent sur un autre si leur code est bien fait
  • au pire sortent du réseaux (cas le plus fréquent sur en xiaomi) et faut refaire l’association (sans supprimer le module de jeedom)

Malheureusement il n’y a rien a faire pour empêcher cela, je suis d’ailleurs étonné que tu n’ais jamais eu ce soucis avec abeille car la le soucis c’est pas jeedom/zigbee/le contrôleur mais bien le code dans le module.

Desfois au bout de 24 à 48h le module revient (suivant les marques)

3

Merci pour ton retour Loic.
Non aucun problème avec Abeille. Quand je partais en vacances, je débranchais mes prises Osram et tous les nœuds basculaient automatiquement sur le coordinateur sans aucun problème de coupure ou perte de module. Pourtant c’est les mêmes nœuds, j’ai « juste » basculé d’un pizigate à une clé EZSP et du plugin Abeille au plugin Zigbee.

D’ailleurs pourquoi perdre tous les nodes qui étaient sur le coordinateur alors qu’ils n’étaient même pas rattachés au routeur que j’ai débranché ? je n’ai pas souvenir exact de l’état du réseau de hier soir avant débranchage du repeater mais j’ai l’impression que seuls les nœuds qui étaient justement raccordés aux 3 routeurs ont survécu. D’ailleurs j’ai coupé le repeater vers les 22h30 et tous les nodes ont cessé de dialoguer entre 4h et 5h30 du matin. Si les nœuds ne savaient plus router les messages à cause de la coupure du router, ils auraient dû également cesser de dialoguer vers les 22h30, non ?

4

Je peux pas te dire je te donne juste les informations de la doc officiel zigbee que j’ai lu et que j’ai pu comprendre.

Je vais être honnête clairement ton cas je peux rien y faire c’est trop bas niveau dans le protocole il faut voir avec les concepteur du protocole et ceux qui ont fabriquer tes modules et la configuration qu’ils ont mis dans leur firmware.

Ca se trouve en zigate ton routage ne passait que par le coordinateur (ou pas), ou peut être que le répéteur a pris toute les routes et une fois déconnecter les modules n’avait plus aucune route donc impossible de revenir sur le réseaux, peut être que quand tu as débrancher le routeur il a envoyer un autre de déconnexions et ca a perturbé les modules… Clairement c’est largement au dessus de mes capacité de t’expliquer ce qu’il s’est passé (maintenant ou meme dans 10ans)

5

Merci pour ta franchise.
Avec un peu de chance quelqu’un de passage qui connait bien le protocole pourra nous aiguiller sur le sujet.

Je vais essayer de comprendre ce qu’il se passe et voir si le problème est reproductible, mais clairement c’est embêtant comme situation car une coupure électrique ou un débranchage temporaire d’une prise peut arriver, si on doit réinclure tous les modules à chaque fois, ça va pas être pratique. Le protocole doit bien prévoir ces cas là.

En attendant, je tente de rebrancher le repeater, je vais voir si ça repart.

6

Malheureusement non le protocole ne prévoit rien c’est les fabriquant qui décide, exemple simple pour les modules xiaomi si pendant 24h (peut être moins même) il ne communique pas avec le contrôleur alors faudra les réinclure.

En soit le protocole est bien le soucis c’est les firmware des modules qui sont pas forcement assez travaillé (mais au vu du prix des modules c’est evident)

7

Deux cas possibles :

  • le coordinateur a été surchargé ou sa capacité d’accueil en direct a été atteinte et il ne gère plus les tables de routage
  • le routeur que tu as retiré était le seul avec une communication correcte et servait à distribuer les tables de routages alentour. Une fois retiré les ZED qui y étaient rattachés ou ceux pour lesquels il servait les tables de routage se sont retrouvés isolés.
    Zigbee ou Abeille même conséquence. Comme l’a dit @Loic ensuite c’es la pile zigbee utilisée par les deux plug ins et les firmware de chaque équipement qui feront la différence(cf un de mes posts récents sur les LQI/RSSI pour comprendre ce qui se passe au niveau bas du protocole).sur un possible retour à l’équilibre.

Dans les deux cas il faut remettre en place un routeur fixe et réveiller tous les routeurs et équipements terminaux pour que le réseau se reconstruise petit à petit (il va falloir un peu de patience le temps que tout les équipements sur le réseau se fassent leur place et leur rôle au travers d’échanges mutuels ainsi qu’avec le coordinateur. C’est un réseau maillé donc il y a pas mal de boucles itératives au niveau de chaque saut pour redéfinir les routes entre équipements.

Conseil général : le zigbee est un réseau maillé globalement fait pour des applications quasi statiques domotiques (ce ne sont pas des trackers GPS ni des objets mobiles). Enlever un ou des routeurs à la volée c’est tout sauf une bonne idée. Les routeurs du réseau doivent rester le plus possible en place en utilisation courante. Retirer des routeurs ne doit se faire que pour des opérations de maintenance en connaissance de cause.

On peut faire l’analogie avec une voiture à laquelle un quidam s’essaierait de retirer une roue histoire par exemple d’économiser en pneumatique. Se poser ensuite la question de pourquoi la voiture fait du bruit ou pourquoi elle va moins vite ou pourquoi elle est « plantée » n’aura que peut de réponses sinon de réinstaller la roue car la voiture a été conçue pour quatre roues.

1 « J'aime »
8

Merci pour les explications.

C’est très intéressant. Je viens de trouver un résumé de la norme et du fonctionnement global sur le site de Silicon labs qui est vraiment pas mal, je vais lire ça à tête reposée. Mais en tout cas le réseau est bien prévu pour se reparer tout seul via une relance d’une requête de découverte du réseau. Juste que ça peut prendre beaucoup de temps.

ug103-02-fundamentals-zigbee.pdf (1,1 Mo)

9

C’est la theorie en pratique en fonction de comment le fabricant implemente cette redecouverte ca marche pas trop…

10

Salut @mick74
J’ai aussi le problème avec des sondes sonoff qui disparaissent sans raison. (avec ou sans répéteur sur le reseau). J’ai 6 devices au total.
Je trouve ce protocole tres mal conçu comparé au zwave.

11

Le protocole demande avoir des noeuds routeur toujours alimenté et un réseaux statique (typiquement les ampoule hue qui peuvent voir leur courant coupé c’est un probleme…)

12

C’est bien mon cas. Je n avais que des sondes juste avec la conbee2.
Certaines disparaissaient. J ai ajouté un device tjs alimenté qui fait office de routeur a côté des sondes (ctrl led gledopto qui fonctionne parfaitement)
Même topo sauf qu’elles mettent plus de temps a disparaitre.
Je cherche la cause mais du mal a avancer

13

Sauf que les ampoules Hue avec le pont Hue, tu peux en éteindre électriquement la moitié pendant 1 mois, dès que tu les rallumes elles reviennent immédiatement et tout remarche instantanément. En 5 ans d’utilisation des Hue, j’ai jamais eu une seule deconnection d’ampoules ou d’accessoires non alimenté en 220V.

C’est pour ça que je suis étonné, d’autant plus qu’avec Abeille c’était également très stable. Le seul souci que j’ai eu ( d’ailleurs c’est sûrement ton souci @loic69), c’est des perturbations avec le WiFi et l’USB 3 qui génère des fortes perturbations électromagnétiques et provoquait des pertes des nœuds Zigbee. J’ai été obligé de bien régler les canaux des 2 protocoles et de passer mes appareils en usb2.
Mais une fois ce problème trouvé et corrigé, je pouvais débrancher mes prises pendant 3 semaines, mes objets ne tombaient pas et quand je remettais les prises, tout se remettait normal comme s’il n’y avait pas eu de coupure.
Du coup, soit les objets ne passaient pas par les prises et étaient raccordés au coordinateur directement, mais cela voudrait dire que le graphique d’Abeille serait faux, soit Abeille implémente mieux le protocole que Zigpy et gère mieux les messages de découverte du réseau (ce qu’expliquait Yves).

J’ai modifié de mon côté le firmware de l’ezsp pour mettre le non officiel proposé par le plugin et ai remodifié le canal Zigbee pour remettre exactement le même que j’avais sur la pizigate, je vais refaire l’expérience dans la nuit.

14

Avec hue tu utilises très peu de module sur pile (l’on explication n’est que pour les end device) et ceux utilisé sont souvent de la marque hue qui ont un firmware gérant très bien la disparition de router (c’est logique il savent que les router peuvent disparaître avec leur système)

Après oui le firmware de la clef joue beaucoup personnellement je tourne en deconz et ezsp non officiel et aucun soucis ça marche très bien.

15

De monn côté sur ma conbee2, j’etais avec le plugin deconz à la base. J’avais ces problèmes de perte définitive de end device.
Je suis passé sur plugin zigbee (que je trouve mieux perso) et j’ai également le même souci.
Je pense donc que c’est plutôt un problème de firmware conbee2…

16

Justement, si tu as le problème avec les 2 plugins, c’est sûrement un problème d’interférences. Si tu as du wifi à proximité, le plus simple est de mettre les 2 canaux à 11 (même chiffre mais le canal n’est pas du tout sur les mêmes fréquences, c’est pratiquement les opposés) sur la borne wifi et le canal Zigbee.

Sinon quel matériel ? Raspberry Pi ? L’histoire de l’USB 3 est une vraie plaie, de mon côté, ça me fait même planter le WiFi 2,4GHz… Bref, tu as les pistes :wink:

17

Juste pour info

18

Merci pour vos retours. Oui je viens de decouvrir ce post qui est top.
A l’heure ou je parles mes 2 bornes wifi sont sur les canaux 6 et 11 mais de mémoire elles sont réglées en auto. Je vais essayer de verrouiller ce point pour ne pas chevaucher sur mon canal zigbee 11 qui correspond au 1 en wifi.
En tout etat de cause, le firmware conbee2 ne devrait pas shooter mes devices, c est un peu exagerer de les supprimer de l’association du reseau zigbee…

@mick74
VM sur NAS Syno. Pas de problème chez moi sur l’USB, Le port est configuré en USB3. J’ai un hub USB3 Amazon qui fonctionne nickel. J’ai dessus pas mal de choses (RFXCOM, Aeotec ZWAVE version hardware mise à jour suite pb USB, BLEA,…)

19

Bonjour,
Ce n’est pas le firmware de la conbee qui les sort mais les device eux meme qui sorte du réseaux. C’est bien le soucis en zigbee c’est que si le device n’a pas de nouvelle de clef pendant X secondes/minutes/heures il sort de lui meme du réseaux et ca on peut rien y faire c’est le fabricant qui le code dans le device.

20

Bonjour,

Comme le dis @Loic cela dépend je pense du firmware de l’équipement (je dis je pense car je n’ai rien lu moi :stuck_out_tongue: ), j’ai déjà entendu la particularité de capteur aqara (Xiaomi) que j’ai constaté quand j’ai changé ma clé C2531 avec une combee. Le capteur garde la route établi a son appairage.

Un capteurs ainsi que d’autre équipement ne répondais plus quand je débranchais (coupure inter) une ampoule HUE.
A première vu on incrimine la clé, ce que j’ai fais, mais en vérité après réflexion il est possible que les conditions d’appairage ne soit pas les même.

Dans le doute pour appairer un équipement zigbee sans souci, je préconise 2 règles pour l’appairage:

  • Déconnecter le temps de l’appairage les routeurs « déconnectable »
  • Appairer l’équipement a l’endroit final de son utilisation

J’ai fais l’erreur d’appairer des équipements devant le pc, au final, le capteur se connectait a la HUE de l’étage alors que je capteur était utilisé a la cave et et que la combee est au RDC.

Apres avoir respecté les règles précédente, plus aucun soucis.

1 « J'aime »