Forum Domoticz en français

Oui, quand il y a une modification de la page de paramétrage de DomoticZ, il est nécessaire de redémarrer complètement DomoticZ pour que la page soit mise à jour avec la nouvelle version.

OK, je ne savais pas et à mon sens, c'est un oubli car sur le redémarrage du plugin qui peut (même si cela doit être rare) changer les options de config Domoticz devrait refaire la page. Là, sur un update plugin classique, on se retrouve potentiellement avec une config HW/Dz frankenstein vs plugin, ce qui n'est quand même pas terrible. J'ai fait un message sur le forum anglophone à ce sujet.

Sur le reste du pb, même si moins aigu avec le nouveau coordinateur, il restait des vapeurs. J'ai vu que le source routing que j'avais vu évoquer (car bcp de pb similaires côté ZHA) en cherchant sur l'erreur logguée était dispo en activant la config avancée (Enable Zigbee Source routing (plugin)).

J'ai activé cela puis relancé le plugin et cela semble prometteur: Il reste qq erreurs, mais ça tombe à une toutes les ~20mn contre toutes les 4 ou 5s (phases à 100% avec l'ancien coordinateur, avec conso mémoire qui partait alors en live)....

'flow_control': None c'est le défaut et c'était le défaut.

Sur les coordinateur Silicon Labs None déclenche Xon/Xoff ( software ) alors que sur les TI cela reste à None

OK, cela ne surprendra donc personne.

Par contre, il semble bien que le source routing améliore bien les choses niveau delivery failed: J'en ai eu 24 sur le log depuis minuit en un peu plus de 8h. Soit un tous les 25mn.

Depuis le changement de coordinateur je n'avais plus du 100%, qui se retrouvait alors à charger le lien série entre la radio et le ttyUSB pouvant ajouter des congestions à ce niveau, mais cela restait important.

Avec le changement côté routage cela semble beaucoup mieux fonctionner.

Hello,

Bilan inchangé sur le WE depuis l'activation du source routing: Qq delivery failed (toujours le "sl_Status.ZIGBEE_DELIVERY_FAILED: 3074", vu également sur d'autres plateformes domotiques), généralement isolés ou limités à un burst de qq minutes. Comme je ne voyais plus de divergence dans l'occupation mémoire, je referais l'essai inverse dans la semaine, sur qq jours aussi si cela veut bien tenir de manière stable, afin de mesurer globalement la différence à matos identique... et si la statistique globale remonte fortement, il restera à remettre le contrôle de flux antérieur inadapté au matériel pour voir si impact sur l'utilisation mémoire.

A revoir les logs précédents, si j'ai toujours le 3074 ci dessus, je n'observe plus les 2 messages qui suivaient (_unicast_command-XXX) quand j'avais la mémoire disponible qui fondait rapidement, comme typiquement dans cet extrait:
Remettre un contrôle de flux SW permettra de voir si j'avais réellement un coordinateur HS ou un pb lié à de la perte de caractères entre le serial-USB et l'EFR, particulièrement quand il y a bcp d'erreurs qui remontent.

Il y a un github ou on trouve des FW silabs personnalisés (mais que des récents) pour les coordinateurs du marché, ce qui se résume visiblement à configurer les IO câblées pour l'UART de l'EFR, genre:

Sonoff:
https://github.com/darkxst/silabs-firmw ... B1B0.patch

Aeotec:
https://github.com/darkxst/silabs-firmw ... C1A4.patch

Les RTS/CTS du contrôle de flux HW sont commentés/inutilisé côté Sonoff et pas pour le Aeotec.

Ceci me permet aussi de comprendre le pb qui a eu lieu avec l'essai de FW pris directement chez silabs: Ce FW devait être une version de base pour leur carte d'évaluation, avec l'uart et les rx/tx de cette dernière qui ne coincidaient pas et commentés/modifiés dans les patch ci dessus.

Une fois flashé/redémarré, plus rien ne passe entre le serial-usb et l'EFR du coordinateur et c'est mort...

juste un commentaire sur le Source Routing.

Sauf si tu as un réseau de plus de 100 objets, je ne pense pas que ce soit pertinent, d'autant plus que par défaut, la base de données zigpy n'est monté qu'en mémoire. Du coup a chaque redémarrage il faut refaire la découverte). Par contre ca peut regler des problèmes induits par des routers qui ont des bugs de routing ( Osram pour les principaux, mais certains Tuya ...)

En revenant vers 'table routing' il faudra que les choses se mettent en place et ça prend du temps.


Plus d'infos ici
- https://meshstack.de/post/home-assistan ... uting-zha/
- https://github.com/zigpy/zigpy/discussions/1551

PS/ Si tu souhaites activer la persistance sur la base de données zigpy , il s'agit du paramètre "enableZigpyPersistentInFile" dans les settings avancés section "Paramètres expérimentaux"

Hello,

Je suis loin des 100: Il y en a que 6 en tout (le gros de ma domotique antérieure à l'ajout du zigbee est en zwave), 3 prises identiques Nous qui font du maillage et 3 capteurs de vibration Moes à pile que tu avais optimisé il y a ~1 an 1/2.

C'est vraiment un très très petit réseau et qui tournait sans pb jusque juin dernier!

Et la prise la plus proche qui relaie est à moins de 4m du coordinateur en vue quasi directe, juste une cloison fine en "obstacle".

Je comptais en effet laisser tourner afin que la topologie se (re)fasse, possible vu que cela ne posait plus de pb de stabilité lié à la conso mémoire.

Sinon, je tenterais de changer de coordinateur (à priori pour le modèle en 1er message car version plus récente/perenne? mais restant visiblement compatible de l'EFR) et surtout avec une antenne externe contrairement au ZGA008. Je garderais alors ce dernier en backup si panne.

Jamais eu aucun pb avec un contrôleur à antene intégrée en zwave, je ne me suis donc pas méfié, mais avec le 2.4GHz un peu plus encombré (et des wifi qui peuvent changer de canal à la volée) que le 868MHz c'était peut-être pas l'idée du siècle...

Hello,

Après 24h sans source routing niveau erreurs c'est au taquet et ne faiblit pas à regarder les derniers logs: On est à 12k sur ~24h, soit en moyenne 8/mn pour un réseau avec 6 objets dont 50% assurant routage!

Avant changement (source routing actif), c'était tombé au ras des pâquerettes:
Et la journée suivant le changement c’était pas bien haut non plus:
Je verrais demain si cela s'est calmé, mais je pense que mon zigbee fonctionne désormais très mal avec la config par défaut, malgré le faible nombre de nœuds. Aucune idée de quand cela a démarré, n'ayant pas regardé les logs plugin entre le tout début du zigbee chez moi (et je n'avais pas bien plus de messages d'erreur que de réussite, cela m'aurait un peu inquiété!) et les problèmes allant au crash par conso mémoire il y a un peu plus d'1 mois.

Aucune idée de combien de temps pour qu'une topologie se refasse, mais surtout avec si peu de nœuds cela m'étonne qu'on dépasse qq heures.

À mon avis, cela indique probablement que certains de tes routeurs perturbent le réseau Zigbee. En effet ce que tu permets le Source Routing c'est de s'affranchir des tables de routage propre à chaque router.

Pour en avoir le cœur net, je te recommande de faire du sniffing réseau. Cela te permettra de vérifier le cheminement des messages : ceux-ci devraient partir correctement du coordinateur, arriver à un routeur, mais ne pas être transmis jusqu’au destinataire final.

Une solution simple à tester serait d’éteindre tous tes routeurs pendant environ 15 secondes, tout en laissant le plugin et le coordinateur actifs, puis de les rallumer. Cela pourrait résoudre temporairement le problème.
J'ai rencontré une situation similaire avec une prise connectée Osram. La seule solution durable dans mon cas a été de la retirer complètement du réseau. Ce qui était fou, c'est que le router transmettait bien du device -> coordinateur, mais pas l'inverse

Un autre utilisateur ayant des ampoules Osram a trouvé une solution radicale en créant un réseau Zigbee dédié, avec une instance spécifique du plugin uniquement pour les appareils Osram. Depuis, il n’a plus rencontré de problèmes et la stabilité est revenue.

Si tu as la possibilité de faire un Sniff, tu peux me l'envoyer. M'envoyer les Logs du plugin pour que je puisse detecter les failure, et également un export.json pour voir les caracteristiques de chaqun des objets.

Sources:

* Il y a aussi des SonOff smartplug qui semblent etre connu pour etre des mauvais routers. ( https://github.com/Koenkk/zigbee2mqtt/issues/10282 )

* Note that some Zigbee devices are also not fully compatible with all brands of Zigbee router devices. Xiaomi/Aqara devices are for example known not to work with Zigbee router devices from Centralite, General Electrics, Iris, Ledvance/OSRAM, LIGHTIFY/Sylvania, Orvibo, PEQ, Securifi, and SmartThings/Samsung. Better results can usually be achieved by using mains-powered devices IKEA and Nue/3A Home or dedicated DIY routing devices based on Silicon Labs EFR32MGxx, Texas Instruments CC253x/CC26x2, or XBee Series 2/3 Zigbee radios. ( https://community.home-assistant.io/t/z ... ing/515752)

Salut, merci pour ces suggestions, pour le sniff il faudrait un 2nd adaptateur et pour le moment je n'ai pas, même si je compte racheter un spare histoire de pas être coincé un mois dans le futur sur un pb de coordinateur. Je tenterais le retour en routage table et débrancher les routeurs ce WE, j'imagine que cela les force à refaire une topologie? Même si le mode de fonctionnement actuel semble (au moins sur les 2x qq jours d'essai) bien plus stable cela permettrait de confirmer un probable pb routeur.

En zigbee j' n'ai pas vu l'équivalent qu'on avait en zwave: Commande de "heal network" pour refaire globalement une topologie, ce qui était long/déconseillé sur un gros réseau, ou plus finement, une commande permettait de forcer un nœud à réapprendre son voisinage et lancer cela a qq minutes d'écart sur qq nœuds sur secteur géographiquement bien choisis puis réveiller manuellement les nœuds à pile voisins qui avaient trop de timeout corrigeait rapidement et efficacement les petits pb, souvent liés à une inclusion non réalisable sur le point d'installation et donc faite proche du contrôleur, ou nœud ayant été bougé après inclusion, choses qui peuvent perturber un maillage.

Côté matos zigbee c'est assez simple: 3 prises Nous TS011F identiques et 3 capteurs de vibration Moes TS0210 à pile.
Ces prises assurant routage sont ce modèle:
https://www.domadoo.fr/fr/prises-connec ... 33517.html

Export joint: