J’ai une Atlas (avant une Smart), correctement mise à jour et j’ai plusieurs modules Zigbee depuis près de 2 ans. En général, je dirais que le réseau Zigbee fonctionnait correctement 90-95% de fiabilité mais malheureusement pas à 100%. Au fil du temps j’ai rajouté des modules en 230v afin d’améliorer la couverture… et la performance était satisfaisante (sans être parfaite).
Depuis plusieurs jours, cette performance est descendue en dessous de 50%… c-à-d que mes détecteurs ne répondent plus, de même pour l’interrupteur… et puis cela remarche… et puis plus… Le graphique du réseau ne semble pas indiquer de bonnes connexions, même si physiquement il n’y a jamais plus de cinq mètres séparant les modules entre eux…
J’ai tout essayé (redémarrer l’Atlas), synchroniser le zigbee, relancer les dépendances… parfois cela semble remarcher mais l’espoir est de courte durée…
Bonjour,
Les raisons peuvent être multiples.
Est-ce que le maillage Zigbee est suffisamment étoffé ? Il faudrait peut-être ajouter quelques routeurs par-ci par-là pour voir si cela pourrait améliorer les choses (routeur = interrupteurs, ampoules, répéteurs, analyseur d’air, relais Zigbee… bref, tout module qui s’alimente sur le secteur car il assure également et normalement une fonction de routeur Zigbee).
Autre piste, s’il ne s’agit que de modules ‹ end-terminal › (c’est à dire de modules alimentés sur batteries) qui finissent par se déconnecter : changer tout simplement les piles.
Elles durent au moins 2 ans, voire beaucoup plus (j’ai des modules de détection d’ouverture de porte Aqara parfaitement fonctionnels et dont je n’ai jamais changé les piles, installés en… 2019 !). Mais il faut quand même penser à au moins tester avec une pile neuve (note : l’indicateur d’usure des piles dans ‹ équipements › reste un indicateur, pas plus… J’ai une télécommande à 1% de batterie restante, et ce depuis plus d’un an, mais qui fonctionne toujours très bien…).
L’indicateur de LQI (Link Quality Indicator, représenté sur le schémas graphique) permet également de voir s’il y a un problème potentiel de portée, mais là aussi ce n’est qu’un indicateur.
Ou encore passer sur une clé Zigbee USB déportée, dotée d’une ‹ vraie › antenne 2,4Ghz permettant d’améliorer sensiblement la portée.
A voir…
Bonjour @DanielJ et merci pour cette réponse rapide…
En fait j’ai développé mon réseau au fil du temps, et à la base il n’y avait pas de routeurs (prises et ampoules) et ils fonctionnaient tous… Puis j’ai rajouté ampoules et prises, la surface n’est pas énormes, aucun modules n’est à plus de 5 mètres d’un élément routeurs…
Quant aux piles, au début je pensais que c’était le problème… mais là je les change au moins tous les 6 mois…
Ah, OK…
Après, vu le nombre relativement peu important de modules (à priori), ca vaudrait peut-être le coup de repartir de zéro en faisant une RAZ des modules, et procéder à une re-inclusion de ceux-ci en commençant par les modules routeurs (important !), car j’ai l’impression que c’est l’inverse qui s’est produit (inclusion initiale des quelques modules sur piles, puis introduction des modules sur secteur…).
La portée et la stabilité d’un réseau Zigbee tient quelque fois à peu de choses…
je pensais aussi (et craignais) à tout ré-inclure… mais je gardais cela comme dernière solution avant d’abandonner le Zigbee… (j’utilise aussi d’autres protocole, comme le wifi pour les modules shelly et là je n’ai jamais de problème… mais je suis étonné de ces soucis avec zigbee qui pourtant devrait être fiable, je sais qu’il y a des personnes qui utilisent ce protocole en tant que système d’alarme, de mon côté après ces expériences, je ne le ferais jamais pour une telle application).
je prendrais un peu de temps pour effectuer cette tâche, merci @DanielJ pour ces conseils !
Causes qui pourraient expliquer une soudaine baisse de la fiabilité d’un réseau zigbee :
Branchement d’un nouveau périphérique USB sur le même concentrateur USB où est branché la clef zigbee. Comme par exemple un disque dur ou bien une autre cle domotique (cle bluetooth par exemple). Cela peut s’expliquer soit par une interférence induite par le protocole radio utilisé si le périphérique branché venait à être un device radio. Soit par une puissance d’alimentation réduite par le concentrateur USB, qui ne permet plus d’alimenter correctement la cle Zigbee.
Déplacement d’un périphérique électronique à proximité (comme une box internet, une alimentation DC, un routeur ou borne wifi etc… Ou bien déplacement de la clef zigbee elle même proche d’un autre device electronique. Pour ma part, j’ai gagné énormément en fiabilité en branchant ma clef zigbee sur une rallonge USB de 1m et l’éloigner de tout mon matériel domotique (serveur, box internet, borne wifi, multiprise etc…). A noter aussi de faire attention à ne pas disposer la cle près d’un mur dans lequel passe une gaine technique électrique, qui peut aussi être source d’interférences.
Une modification du réglage dans les paramètres du wifi du foyer. Comme par exemple modificaition de la fréquence utilisée (2.4 ou 5GHz), ou modification de la largeur de bande (20, 40 ou 80MHz), ou bien encore changement du canal wifi utilisée par la box wifi (manuellement ou automatiquement) sur ta box ou celle d’un voisin proche si tu habites en appartement. Car les ondes zigbee peuvent être fortement perturbées par le wifi
Pour avoir longtemps galérer avec ces problèmes de fiabilité zigbee, chez moi j’ai définitivement réglé le problème en :
1/ Eloignant la cle Zigbee via une ralonge USB de tout mon matériel domotique
2/ Branché ma cle sur un hub alimenté dédié (plutôt que directement sur le concentrateur USB du serveur/RPI/box).
Sur le graphique ca fait un peu sac de noeud mais faut voir que chaque composant est au moins rattaché à un autre composant routeur en vert : LQI 255 (max). Je n’ai que 3 composants sur ces 92 à moins de 200 LQI (mais je peux pas faire grand chose ils sont loins dans une cabane au fond du jardin alors je leurs pardonnent ^^)
Pour le coup ca n’a pas toujours été le cas et je confirme de grandes amélioriations sur les remarques précédentes :
Rallonge AUTO-ALIMENTE (hyper important, j’ai testé sans et c’était cata) USB pour éloigner mon controleur de ma box wifi… Si possible une rallonge dédiée pour cette clé, évité 4 clés avec des protocoles dans tous les sens sur une multi USB. Mais ça vaut pour tous les protocoles, c’est juste une bonne pratique.
Reglage des canaux WIFI de la maison pour ne pas rentrer en conflit
Mon objet magique : routeur zigbee alimenté par USB Répéteur / routeur zigbee alimenté par USB, compatible Tuya Smart Life, Lidl Home, etc. - www.domotique-store.fr
J’avais plein de prises avant mais franchement l’implémentation du routing n’est pas forcément clean et la discression du constructeur… ca c’est uniquement conçu pour, je me suis pas prit la tête, j’en ai mit 1 dans chaque pièce pour bien couvrir les soucis de mur porteurs et aussi pas trop trop éloignés les composants d’une source fiable.
Enfin on réimporte chaque module et on le rattache correctement… Grace au point d’avant j’avais un routeur dans chaque pièce, chaque routeur est rattaché soit au controleur principal soit à un autre routeur par rapport à sa distance.
Chaque module est ensuite rattaché à son routeur unique dans la pièce, au plus prêt au plus clean grâce à cet ajout pas si vieux que ca dans jeedom, la possibilité de lancer l’inclusion sur un composant directement. Ca a tout changé, ca a permis de donner une dimension spaciale à la conception de son réseau.
Depuis plus de soucis, tout remonte bien, même après des gros restart, coupure courant, etc. J’ai mon alarme, lumière, prises, thermostats, mouvement, fenetre, la totale.
Là, ce serait quand même assez dommage…
Le protocole Zigbee, contrairement au Wifi, est conçu et optimisé pour des échanges concis et efficaces, en minimisant le besoin d’énergie. Ce qui n’est absolument pas le cas du Wifi. Donc pour des modules sur batterie (évidemment je ne parle pas des modules sur secteur comme les Shelly), je doute fortement qu’un module Wifi tienne aussi longtemps qu’un module Zigbee dans le temps (je l’ai dit : après 5 ans mes modules Aqara répondent toujours présents !).
D’ailleurs, c’est possible qu’il y en ait, mais perso je ne connais pas beaucoup de module Wifi alimentés uniquement sur batterie… Et encore moins avec des piles boutons.
Sinon +1 avec @yus34, @Dreaky et @Mackile (mais là, il s’agit d’une box Atlas avec une clé Zigbee déjà intégrée, et équipée qui plus est d’une antenne déportée…).
Le zigbee a peut etre des défauts mais il a été concu pour de la domotique, imaginé pour avoir des composants légés, flexible, facile à produire, bien moins chère.
Le Wifi a été tordu pour cet usage mais pas prévu pour cela. Jamais tu auras du Wifi sur des petits composants autonomes, je pense même que miser sur le Wifi comme choix de protocole en 2024 serait un peu risqué Mais encore une fois ca dépend des usages et des besoins.
merci à tous @DanielJ, @yus34, @Dreaky et @Mackile pour vos conseils…
comme indiqué par Daniel, je suis sur Atlas… donc avec zigbee intégré… (avant sur ma Smart, j’étais aussi passé sur une cable USB pour déporter la clé conbee…).
@Mackile le graphique du réseau est vraiment impressionnant…
comme conseillé, j’ai effacé tous mes modules zigbee et je suis en train de les réinstaller… dur dur pour les scénarios qu’il faut revoir…
j’ai commencé par les éléments routeurs branchés sur secteur, tout bon…, maintenant j’ai des soucis pour « inclure » certains modules sur batterie… même après plusieurs essais cela ne marche pas, malgré la présence proche d’un routeur…
Question: y-a-t-il un temps de latence ou d’adaptation pour que le réseau atteigne son équilibre (il me semble avoir lu ceci un jour) ???. Lorsque je me rapproche avec le module en question de l’Atlas, là il est reconnu… mais je crains qu’il ne soit plus détecté une fois retourné à sa place… ! ??
NONNNNNNN, tu n’as pas besoin de supprimer ton composant pour le réinclure. Je comprends pourquoi tu ne souhaitais pas passer par la réinclusion. En gros jeedom n’est qu’une passerelle entre tes scénarios et le protocole domotique. Jeedom relis son composant interne au composant zigbee via l’identification de ton composant (adresse MAC).
Quand tu demandes un inclusion tu demandes finalement à zigbee d’inclure ton objet à son réseau, ou à le réinclure, mais il gardera toujours la même adresse MAC, le meme identifiant, et donc jeedom le connait donc aucun soucis.
Tu as juste à réinclure tes objets dans le bon ordre et rien toucher à tes objets ou composant jeedom (heureusement). Le maillage se refera après au bout de quelques heures et c’est bon.
Oui, quand tu fais une inclusion tu vas indiquer le endpoint optimal mais lui a son propre algo de construction, il va chercher des voisins etc… sur un réseau aussi petit ca ne devrait pas prendre trop de temps. Mais si ton premier composent routeur est bien inclus, bizarre que tu ne puisse pas inclure un autre à partir de ce dernier.
PS : j’ai oublié un détail : bien inclure les composants à l’endroit où ils seront à terme. Ne pas inclure un composant à côté et le bouger directement après. Eventuellement le rapproche d’un metre ou deux metres et encore, j’ai envie de dire si l’inclusion ne marche pas à l’endroit où vous souhaitez le placer c’est que tot ou tard ca va déconner.
PS : un autre détail, bien vérifier les piles des composants autonome, ils ont l’habitude d’envoyer des impulsions de temps à autre, l’inclusion c’est le solliciter plus qu’il n’a l’habitude.
Et pourtant, je n’ai jamais parlé d’effacer les modules au niveau de Jeedom !
Bon, je crois qu’il faut revoir les bases en effet… Bien relire ce qui a été écrit ci-dessus, en particulier par @Mackile, il y a plein de très bons conseils.
Un autre outil à connaître qui peut être très pratique dans ce genre de cas (si ce n’est pas trop tard) : la fonction remplacer… Voir ici pour la doc.
donc pour être sur: j’aurais dû effacer la référence de l’object dans la « configuration du réseau / Noeuds », et ensuite refaire une inclusion sans avoir effacer l’objet ? Correct ?
Non, pas du tout. Il n’y a rien à faire au niveau de Jeedom si ce n’est de répéter une procédure d’inclusion.
Dans l’ordre :
1.- RAZ du module lui-même. Cela passe souvent par un appui prolongé (5 ou 10") sur un bouton physique présent sur le module, ou appuyer dessus 5 fois consécutivement (modules de la gamme Trädfri d’Ikéa par exemple). Cela permet de sortir le module du réseau Zigbee, et de le mettre en configuration d’appairage (souvent matérialisé par une LED qui clignote).
2.- Sur Jeedom (ou sur l’interface de z2m) : lancer simplement une inclusion (inutile de supprimer quoi que ce soit). Avec les dernières versions de z2m, il est même possible de forcer le module routeur sur lequel on veut se synchroniser.
3.- C’est tout…
Le module nouvellement inclus sera reconnu et reprendra toutes ses références au sein de Jeedom (virtuels, scénarios, etc…) sans aucune conséquence donc tant qu’il n’a pas été supprimé, et au niveau réseau Zigbee il sera considéré comme un nouveau module, et sera inséré dans le réseau en tant que tel. Mais là aussi, aucune conséquence n’est à prévoir.
c’est très clair, et beaucoup plus simple… (pas toujours habittué à cette simplicité !) un grand merci…
ps: je suis en train de reconstruire mon réseau (et mes scénarios (car effacement !)), il me reste deux modules recalcitrant (je pense que je vais encore changé la pile !).
Ok, bon courage !
Dernier conseil puisqu’il y a eu effacement, et donc une probabilité pour qu’il reste des commandes non reconnues (des expressions de type #1234# dans des scénarios, virtuels ou autres…), l’outil de détection des commandes orphelines (dans Analyse, Équipement, onglet Commandes orphelines) permet de les traquer et de vérifier qu’il n’en reste pas.
Exemple :
Si c’est le cas, comme ci-dessus, il faut alors les reprendre une par une et les corriger en remplaçant cette expression #1234# par la commande correspondante (#[Garage][Porte][Ouverture]# par exemple).
Mais encore une fois ca dépend des usages et des besoins.
… mais j’apprends !!
