Bonjour,
Faisant suite aux échanges, si l’upgrade du protocole ZigBee a amélioré les choses, j’observe le comportement résiduel suivant :
Lorsque que les spots servant habituellement de relais sont non alimentés lorsque j’allume les spots habituellement dépendants, leur extinction ultérieure se passe sans problème.
Lorsque les spots relais sont alimentés lorsque j’allume les spots dépendants puis que je coupe l’alimentation des spots relai, les spots dépendants ne peuvent plus être éteints. L’extinction redevient possible lorsque je ré-alimente les spots relai.
En apparence : Il semble que le reroutage Zigbee n’est pas correctement réalisé, avec une différence de conséquence au moment de la disparition du relai, et postérieurement lors d’une commande d’un équipement habituellement dépendant. C’est difficilement compréhensible côté soft, mais pourtant reproductible : Il y a qqchose à analyser. Le cas que je soulève est certainement marginal, mais la correction pourrait résoudre certains pb vus comme aléatoires car non correctement circonstanciés, du style « par moment ma prise Zigbee ne répond plus, je la désenfiche et la remets et cela marche à nouveau ».
Ayant l’installation adaptée, je suis prêt à faire des essais en collaboration avec une personne qui aurait la vue sur le code ou les développeurs.
Hello.
Mauvaise idée de couper l’alimentation de routeurs dans un réseau maillé. En effet le routage se réajuste automatiquement certes mais pas instantanément voire parfois jamais selon la possibilité restante.
Sachant que un end device ne peut être routé que par un seul routeur à tout instant, si tu fais disparaître ce routeur entre deux actions rien ne dit que le routage aura été rétabli pour exécuter la seconde action.
Pas besoin de chercher ou d’investiguer plus loin le comportement que tu constates est normal et logique.
Pas si sûr que cela soit normal, car avec un spot routé allumé, lorsque le spot routeur est éteint, on peut attendre un temps infini : la demande ultérieure d’extinction du spot routé n’arrive jamais. Si on ré-alimente le spot routeur, tout devient normal.
- Comment corréler cela avec la qualité de Zigbee consistant en un réseau robuste parce que maillé ? En théorie, en l’absence de réponse, Zigbee devrait chercher une nouvelle route !
- Mon réseau comporte 11 routeurs (prises et spots) toujours alimentés en plus du Rpi/Conbee. Il n’y a que 3 spots dont l’alim peut être coupée. Donc, ce n’est pas les possibilité de routes qui manquent.
- Pour info complémentaire, 8 spots routeurs sont côte à côte, mais seulement 2 généralement ne répondent plus.
Bonjour,
La solution, ne rien appairer sur les spots qui peuvent être coupés ?
La solution c’est de ne pas utiliser des spots zigbee ou bien de ne pas les couper.
L’appairage initial ne garantit pas que les équipements ne changeront pas de routeur et donc n’utiliseront pas les spots en question à un moment.
Bonjour, il ne s’agit pas d’un appairage mais d’un routage. De plus, l’appairage est réalisé entre jeedom/zigbeelinker et l’équipement à apparirer et non avec les noeuds du réseau !
Si vous le dites !
Rebonjour.
L’appairage une fonctionnalité logique (lancée depuis une couche réseau application comme Jeedom ou équivalent) qui permet au contrôleur du réseau d’accepter (enrôler) un nouvel équipement et par la même occasion de générer une route initiale (le premier routage) entre le contrôleur et cet équipement; le contrôleur met à jour la table de routage … et communique au end device la liste de ses voisins routeurs accessibles dont un seul est retenu pour la suite…
Lorsque la topologie du réseau change (nouvel appairage, retrait d’un End Device ou d’un routeur par exemples) le contrôleur recalcule les routes. Si un end device ne trouve plus son routeur il pioche dans sa table et en choisit un autre selon la liste qui lui a été communiquée par le contrôleur.
Si le End Device ne trouve pas de routeur (parce que ces derniers sont KO ou bien que la table de routage n’est pas à jour) alors il émet une requête générale sur le réseau (une sorte de SOS) et attend que le contrôleur calcule une nouvelle route et lui communique de nouveaux voisins disponibles.
En conclusion l’appairage c’est l’inclusion et le routage initial d’un équipement dans le réseau. Par la suite seul le routage est nécessaire lorsque le réseau évolue.
Très bonne explication très pro.
Du coup, lorsque je désalimente un routeur, il en reste dans mon cas une dizaine connus dans la table : Le re-routage devrait aboutir et les commandes devraient être transmises par un chemin alternatif.
Avec les éléments posés, je ne trouvais pas d’explication logique et j’en ai déduit que le re-routage n’était pas déclenché. En faisant des photos d’écran de la carte réseau à chaque étape pour investiguer, le problème ne s’est pas reproduit : cqfd. J’ai donc cherché ce qui empêchait le re-routage. Je pense avoir trouvé une explication. Je poursuis l’analyse et reviendrai vers le forum avec la synthèse.
Merci
En fait ce qui est dommage c’est qu’on ne puisse pas désactiver la fonction routeur d’un module si on se souhaite pas qu’il le soit.
Bonjour,
Cela pourrait être un contournement, mais il y a un problème de fond :
Imaginons les thermostats de toute la maison (ou tout élément « critique ») pilotés un routeur de type prise qui tomberait en panne pendant une absence prolongée (ou que la femme de ménage aurait débranché pour mettre l’aspirateur). Cela veut dire que le chauffage ne serait plus piloté. C’est carrément inacceptable !
Pour moi, il s’agit d’un bug ou sinon d’une erreur de spécification.
En parallèle, la piste sur laquelle j’étais est sans issue. Le phénomène semble aléatoire sans doute du au grand nombre de configurations possibles de routage. J’ai aussi l’impression que la carte réseau est inexacte car lors du problème, si le spot ne répondant pas n’a pas de parent, d’autres équipements dans le même cas sont encore pilotables.
En fouillant le forum, je suis tombé sur un sujet corrélé. Parlons maillage zigbee.
Pour investiguer, y a-t-il un moyen de visualiser les tables de routage, et quel moyen pourrait-on utiliser pour forcer un re-routage complet (c’est ce qui est sans doute fait lors d’un appairage). Je comprends bien que des tables locales existent dans les routeurs mais a priori , les équipements terminaux sont pilotés à travers une chaine de routeurs. Je m’étonne que les routeurs ne s’inquiètent pas de la disparition d’un des leurs. Si cela provient d’une implémentation imparfaite dans certains équipements, il est souhaitable que l’appli jeedom / zigbeelinker/ zigbee2mqtt trouve un contournement.
Bonjour,
J’ai toujours eu des problèmes avec des routeurs trop prêts les uns des autres, ils se parasitent mutuellement. Exemple typique des prises connectées sur une même prise multiple. ça ne fonctionne pas correctement.
Il semblerait que vos spots sont très prêts les uns des autres ?
Contrairement au réseau wifi, le réseau zigbee est un réseau à très faible consommation électrique et les interactions entre les modules sont rares. Par exemple un détecteur d’ouverture de porte ne communiquera que lors d’une ouverture/fermeture de la porte et peut rester des jours sans communication et ne sait pas forcement que son routeur a disparu.
C’est pour cela qu’il est préconisé de ne jamais débrancher les routeurs.
- Pour l’aspirateur et la femme de ménage il est préférable de mettre une prise zigbee encastrée
- Pour le thermostat il est facile de prendre la température prévue par Météo France quand le thermomètre zigbee ne semble plus répondre (ou s’il y a trop d’écart …)
Cette affirmation contient en elle même un paradoxe. « Critique » et « routeur non adaptés ». Les applications critiques doivent être gérées par un système lui même critique donc tout sauf radio. Là ce n’est plus Zigbee qui est en cause mais la conception du système. Ensuite piloter un chauffage en passant par des routeurs et une box domotique multiplie le risque de défaillance (dont la chaudière elle même au passage).
Si l’application chauffage est sensible (et pas critique) et que le thermostat ainsi que la chaudière sont Zigbee natifs il faut binder le thermostat à la chaudière (sans passer par des routeurs) et se servir de Jeedom juste comme recueil d’information. Ainsi on réduit la chaine de commande au strict besoin et on divise le risque de défaut. Si pas possible alors passer par du filaire (solution domotique type KNX ou solution à l’ancienne non domotisée) ou sinon … accepter les aléas de fonctionnement inhérent à toute chaine de commande un peu complexe.(ou rendue complexe par la solution mise en place).
Bonjour,
Sans être critique (ce n’est pas du DAL-A), je voulais tout simplement dire fiable, c’est à dire que lorsqu’on souhaite gérer par exemple des thermostats de radiateurs ou simplement allumer des lampes, on aime bien, en tous cas c’est mon cas, que l’application marche « à tous les coups ». De même, lorsque je vais me coucher, je n’aime pas entendre ma femme dire qu’un spot ne s’est pas éteint, et là, cela devient rapidement critique, le terme ne se rapportant toujours pas à la Do178 mais au WAF.
Concernant le/les routeur intermédiaire, c’est le système qui choisi une prise câblée, une prise enfichée, ou un spot … Essayer de forcer le système en n’alimentant que les dispositifs jugés fiables au moment de l’appairage ne sert à rien car un reroutage arrivera peut-être immédiatement après ou à plus ou moins long terme en fonction de la puissance du signal radio reçu (éloignement, baisse de propagation, interférence ou autre)
Quoi qu’il en soit, rien ne peut expliquer que lorsque le routeur intermédiaire est non alimenté, je peux à ma guise allumer ou éteindre mes spots mais que lorsque je désalimente mon routeur intermédiaire alors que les spots sont allumés, certains ne sont plus commandables, avec la seule solution de rallumer le routeur. C’est pour le moins étrange. Que la liaison radio ne soit pas fiable tout court, je suis prêt à l’entendre (mais je suis sceptique au vu de l’architecture déployée), mais qu’elle décide par elle-même de m’empêcher seulement d’éteindre devient ésotérique. Une décision de routage qui dépendrait d’un état ou une commande applicatif ? Une autre explication existe assurément. Je verrais bien un bug de gestion d’erreur sur la commande n’aboutissant pas, peut-être un problème de pile « commande équipement n / gestion d’erreur équipement n, répétition sur non acquittement et traitement final avec reroutage », plusieurs commandes d’équipements étant enchaînées dans mon cas, mais pas forcément avec le même timing entre l’allumage et extinction … ce n’est qu’une des multiples hypothèses à vérifier en traçant les dialogues à différents niveaux. N’étant pas développeur du système domotique, je ne pense pas en avoir les moyens.