Pb routage réseau avec Zigate v2/+, pb NO_ACK

[eoeir]

Bonjour @tcharp38,

Suite au pb rencontré depuis quelques temps (voir ici, je viens de faire une RAZ de la Zigate, toujours en version 3A0 du firmware, puis réinclus presque tous mes équipements. Les inclusions se sont bien passées dans l'ensemble (toujours ces prises Legrand qui sont pénibles à intégrer...). J'ai d'abord réinclus les routeurs puis les capteurs pour que la topologie réseau se construise correctement.

Cela semblait bien fonctionner mais le réseau est retombé en carafe 1-2 heures après :

Les équipements sont en timeout et ils ne sont plus visibles dans le réseau.

J'ai l'impression qu'il a complètement perdu les routes et je vois pas mal d'erreurs dans AbeilleParser :

[2023-08-20 11:30:53] Abeille1, Type=8701/Route discovery confirm, MACStatus=00/ZPS_EVENT_NONE, NwkStatus=D0/ZPS_NWK_ENUM_ROUTE_DISCOVERY_FAILED, Addr=3259 [2023-08-20 11:30:56] Abeille1, Type=8011/APS data ACK, Status=A7/NO_ACK, Addr=3259, EP=01, ClustId=0B04, SQNAPS=B8 [2023-08-20 11:30:56] Abeille1, Type=8000/Status, Status=00/Success, SQN=EB, PacketType=0100, Sent=01, SQNAPS=B9, NPDU=03, APDU=01 [2023-08-20 11:30:56] Abeille1, Type=8702/APS data confirm fail, Status=D4/ZPS_NWK_ENUM_FRAME_IS_BUFFERED, SrcEP=01, DstEP=01, AddrMode=02, Addr=7542, SQNAPS=B9, NPDU=03, APDU=00

Le temps d'écrire ce message, le réseau est totalement vide, pourtant je vois bien des messages passer dans les logs...

Le package de logs :

AbeilleLogs-230820(2).tar.gz

[tcharp38]

La 3.A0 a beau corriger plein de trucs, elle semble aussi une cata :( Regarde ce sujet à l'occase... #2608

Ton réseau n'est pas vide du tout mais je vois des pbs de lecture. La requete LQI est ignorée car arrive en timeout (executée trop tard car 3259 est NO ACK). Les pbs sont liés mais la base est le manque de reponse de plusieurs devices comme le 3259. Peux tu essayer de le desactiver pour voir ?

Les timeouts eux sont + importants. Mais ca m'a l'air tres proche du sujet 2608. Tu en penses quoi ?

[eoeir]

Alors du point de vue de la Zigate c'est normal que le 3259 ne réponde pas puisque qu'il fait partie des équipements que je n'ai pas réinclus (2 sauf erreur de ma part). Je comprends qu'Abeille cherche quand même cet équipement même s'il n'est pas dans le réseau, parce qu'il est présent dans Jeedom.

Je viens de désactiver le 3259 et le 1315 dans la configuration de l'équipement.

Effectivement je trouve que cela ressemble beaucoup au sujet 2608. J'ai également eu un équipement fantôme qui est réapparu avant la RAZ.

[eoeir]

Comme je continuais à avoir beaucoup de messages d'erreurs concernant 3259 dans les logs, je l'ai réinclus.

[tcharp38]

Tu as raison. Si l'equipement etait désactivé il ne devrait pas etre contacté du tout. Neanmoins il peut etre desactivé mais toujours lui envoyer des messages vers la Zigate.

Du coup je confirme le bug. Il y a du polling regulier sur ce device .. et le fait qu'il soit désactivé ne semble pas etre pris en compte. Pas bon.

En attendant la beta, tu peux ecraser core/class/Abeille.class.php avec celui ci Abeille.class.php.zip

[eoeir]

Petit topo sur où j'en suis actuellement.

Comme j'ai vu que suite à la réinclusion de 3259 j'avais beaucoup moins d'erreurs dans les logs, j'ai réintégré la plupart de mes routes dans la soirée (je n'ai pas fait ceux qui sont dans mes combles...). J'ai constaté le lendemain que cela semblait stable, donc j'ai réintégré une partie de mes capteurs. Ce soir le réseau semble toujours OK donc je vais inclure ceux qui manquent pour voir si cela tient toujours.

Donc la situation semble s'améliorer même si je ne comprends pas ce qu'il s'est passé.

Voici des logs récents :

AbeilleLogs-230822.tar.gz

Je n'ai pas encore appliqué le nouveau fichier Abeille.class. Quand sera publiée la nouvelle beta ?

[eoeir]

Nouvelle beta appliquée hier soir. Cela a l'air de tenir depuis 2 jours, il me reste les équipements des combles à remettre dans le réseau.

[eoeir]

Équipements des combles réinclus ce matin. Je laisse tourner ce WE et je fais le point sur la situation.

[eoeir]

Hello,

Petit update sur la situation. J'ai rapidement perdu deux capteurs qui sont situés dans les combles dans la journée qui a suivi je n'avais pas trop le temps de m'en occuper et tout le reste semblait stable.

Je constate de nouvelles anomalies aujourd'hui. Je ne suis pas intervenu sur mon setup si ce n'est de faire la mise à jour d'Abeille (hier).

• Surlignés en rouge dans le screenshot, les deux capteurs des combles qui sont "perdus"
• Surlignés en jaune les équipements qui viennent d'être perdus
• Surligné en vert le sonoff qui est réapparu dans un nouvel équipement

Au niveau des logs j'ai encore quelques erreurs 83 mais moins qu'avant il me semble.

[2023-09-11 16:55:54] Abeille1, Type=9999/Extended error, ExtStatus=83, NPDU=00, APDU=00
[2023-09-11 19:27:50] Abeille1, Type=9999/Extended error, ExtStatus=83, NPDU=00, APDU=00
[2023-09-11 19:31:34] Abeille1, Type=9999/Extended error, ExtStatus=83, NPDU=04, APDU=00
[2023-09-11 19:31:34] Abeille1, Type=9999/Extended error, ExtStatus=83, NPDU=04, APDU=00
[2023-09-11 19:32:27] Abeille1, Type=9999/Extended error, ExtStatus=83, NPDU=00, APDU=00
[2023-09-11 19:32:28] Abeille1, Type=9999/Extended error, ExtStatus=83, NPDU=00, APDU=00

Si je regarde le cas du Sonoff qui a disparu (F33C) puis réapparu (F268), je vois la dernière communication à 20:15 :

[2023-09-10 20:15:07][DEBUG] : msgFromParser(): Attributes report by name from 'Abeille1/F33C/01
[2023-09-10 20:15:07][DEBUG] :   'etat' (0006-01-0000) => 0

Puis un device inconnu qui apparait à 20:17 :

[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Attributes report by name from 'Abeille1/F268/01
[2023-09-11 20:17:36][DEBUG] :   Unknown device 'Abeille1/F268'
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): New device: Abeille1/F268, ieee=804B50FFFE08DEC9
[2023-09-11 20:17:36][DEBUG] :   newJeedomDevice(Abeille1, addr=F268)
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Abeille1/F268, IEEE addr response, ieee=804B50FFFE08DEC9
[2023-09-11 20:17:36][DEBUG] :   updateTimestamp(): WARNING: Abeille1/F268, missing cmd 'Time-TimeStamp'
[2023-09-11 20:17:36][DEBUG] :   updateTimestamp(): WARNING: Abeille1/F268, missing cmd 'Time-Time'
[2023-09-11 20:17:36][DEBUG] :   updateTimestamp(): WARNING: Abeille1/F268, missing cmd 'Link-Quality'
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Abeille1/F268/, Device updates, {"type":"deviceUpdates","net":"Abeille1","addr":"F268","ep":"","updates":{"endPoints":{"01":[],"F2":[]}}}
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Abeille1/F268/01, Device updates, {"type":"deviceUpdates","net":"Abeille1","addr":"F268","ep":"01","updates":{"servClusters":"0000/0003/0004/0005/0006/1000"}}
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Abeille1/F268/, Device updates, {"type":"deviceUpdates","net":"Abeille1","addr":"F268","ep":"","updates":{"macCapa":"8E","manufCode":"1002"}}
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Abeille1/F268/01, Device updates, {"type":"deviceUpdates","net":"Abeille1","addr":"F268","ep":"01","updates":{"manufId":"SONOFF","modelId":"01MINIZB","location":""}}
[2023-09-11 20:17:36][DEBUG] : msgFromParser(): Eq announce received for Abeille1/F268, jsonId='01MINIZB', jsonLoc='Abeille'
[2023-09-11 20:17:36][DEBUG] : createDevice(update, dev={"net":"Abeille1","addr":"F268","ieee":"804B50FFFE08DEC9","modelId":"01MINIZB","manufId":"SONOFF","jsonId":"01MINIZB","jsonLocation":"Abeille","macCapa":"8E"}
[2023-09-11 20:17:36][DEBUG] :   Already existing device Abeille1/F268 => [Maison][Abeille1-192]

Le capteur 1EBD semble toujours envoyer des infos mais est en timeout :

[2023-09-11 20:09:45][DEBUG] : msgFromParser(): Attributes report by name from 'Abeille1/1EBD/01
[2023-09-11 20:10:03][DEBUG] : msgFromParser(): Attributes report by name from 'Abeille1/1EBD/01

Le capteur E43C et le module 7EC0 ne donnent plus signe de vie depuis hier soir...

Le package de logs : AbeilleLogs-230911.tar.gz

Une idée pour avancer ?

[eoeir]

Complément sur mon message d'hier soir. La moitié des équipements sont en timeout et les erreurs 83 sont revenues en grand nombre : environ 1500 depuis 6:30 ce matin.

AbeilleLogs-230912.tar.gz

En creusant un peu je vois que deux équipements sont à la source de nombreux messages "NO_ACK" :

[2023-09-12 07:24:11] Abeille1, Type=8011/APS data ACK, Status=A7/NO_ACK, Addr=**FB6B**, EP=01, ClustId=0006, SQNAPS=77
[2023-09-12 07:25:11] Abeille1, Type=8011/APS data ACK, Status=A7/NO_ACK, Addr=**F33C**, EP=01, ClustId=0006, SQNAPS=7E

Je suppose que cela a un rapport avec les erreurs 83.

0x83 There are no free APS acknowledgement handles. The number of handles is set in the “Maximum Number of Simultaneous Data Requests with Acks” field of the “APS layer configuration” section of the config editor

Est-ce qu'ils sont la source du pb ou ça en est juste la conséquence ?

[tcharp38]

Salut @eoeir Si tu as des devices en "NO_ACK" ca peut pourrir l'ensemble. Je ne sais pas encore comment traiter ce genre de cas. As tu tenté de désactiver les 2 equipements dans ce cas ?

Concernant les erreurs x83, c'est un souci du FW mais si je comprends bien ca vient d'un trop grand nombre de requetes en meme temps, meme des requetes venant du device. Je vois par ex que 3FE4 demande si une mise à jour de FW existe.. mais il fait ca non stop et ca engendre ces erreurs x83. A voir si c'est la zigate qui repond mal ou simplement lui qui a un FW deja pourri. Je n'ai pas de zigate v2 mais je vais déja verifier que sur la v1 la zigate repond bien quand aucun FW n'est dispo.

[tcharp38]

Je viens de verifier sur la zigate v1, si pas de FW + recent dispo la zigate repond bien comme il faut. Ca doit donc arreter les requetes du device qui demandent un FW. Mais sur la v2.. je sais pas. C'est peut etre un autre bug.

[eoeir]

Ce soir le module 3FE4 floode littéralement AbeilleParser.log de "NO_ACK" : 8000 erreurs en 30 mins.... J'ai désactivé les trois équipements qui font le plus d'erreur (3FE4, FB6B et F33C) mais ça n'a pas l'air très efficace. J'ai toujours plein d'erreur de 3FE4. Impossible de les exclure du réseau non plus.

AbeilleLogs-230912(1).tar.gz

[tcharp38]

Je vois ça :(

Ces "NO ACK" semblent venir de l multitude de requetes du device qui demande si un FW est disponible

[2023-09-12 22:39:48] Abeille1, Type=8002/Data indication, Status=00, ProfId=0104, ClustId=0019, SrcEP=01, DstEP=01, SrcAddrMode=02, SrcAddr=3FE4, DstAddrMode=02, DstAddr=0000
[2023-09-12 22:39:48]   FCF=01/Cluster-specific/Cli->Serv, SQN=6B, cmd=01/Query Next Image Request
[2023-09-12 22:39:48]   fieldCtrl=01, manufCode=128B, imgType=0102, fileVers=00010007, hwVers=0000
[2023-09-12 22:39:48]   NO fw update available for this manufacturer.

Je n'ai pas de Zigate v2. Je ne sais pas trop comment t'aider. En + tu as le FW le plus recent mais pour moi il n'est toujours pas mature et pas d'update à l horizon. Je vais peut etre finir par en acheter une d occase pour voir si je peux ameliorer le FW de mon coté.

[eoeir]

Je pensais le déconnecter électriquement ce WE mais l'ensemble des équipements est maintenant en timeout (depuis le 14/09 après-midi). J'étais absent donc je n'ai pas pu regarder avant.

AbeilleLogs-230917.tar.gz

Je pense qu'il ne me reste plus qu'à recommencer depuis le début en ne réintégrant pas les équipements qui ont générés les erreurs.

[tcharp38]

Salut @eoeir Ce sujet me chagrinne. Je ne sais pas trop comment avancer. Le FW de la Zigatev2 me semble le seul responsable d'un tel comportement.

N'avais tu pas une zigate v1 avant ? Je dis ca car pour confirmer, basculer ces devices NOACK sur une v1 et voir comment ca se comporte pourrait clarifier. Abeille supporte 6 Zigates. Bref. juste une reflexion que je partage.

[eoeir]

Depuis hier 6 équipements sont revenus dans le réseau. Le reste est en timeout. Je n'y comprends rien... voici les logs au cas où : AbeilleLogs-230919.tar.gz

J'avais une Pizigate v1. Il faut que je remette la main dessus pour faire des tests. Quelle serait la manière de procéder ? Après installation de la Pizigate sur le raspberry et dans Abeille, j'inclus simplement ces équipements sur la Pizigate ?

[tcharp38]

Oui je suis un peu perdu moi aussi.

Si tu peux ajouter ta pizigate aussi, tu la

• configure dans Abeille
• tu la mets à jour en FW 0004-0323 (c'est la version OPDM) si pas deja le cas
• erase PDM
• redemarrer Abeille
• la passe en mode inclusion
• et declenche un reset de ton device pour qu'il quitte le reseau 1 et bascule sur celui qui est ouvert.. donc le 2

Du coup tu peux juste tester sur un device qui est toujours/souvent en NOACK (ex Philips Hue outdoor sensor) et voir comment il se comporte sur une zigate v1.

Autre piste que je discutais avec un autre utilisateur qui lui a rebroussé chemin et laissé tomber la 3.A0 pour rebasculer sur la 3.22. Pour lui la 3.A0 mettait trop le bazard.

[tcharp38]

Pour info je viens de faire qq modifs pour remonter l'info "NO-ACK" sur un device => 230919-BETA-1

Le status de la page santé est ainsi amélioré

• ok
• Timeout
• No-Ack
• ou Time-out & No-ack

Pour rappelle timeout indique qu'on n'a pas recu d'infos du device alors que noack dit plutot que ce dernier n'a pas repondu.

[eoeir]

Effectivement, j'ai vu ça suite à la MAJ de la beta, ça va être utile !

Quelques nouvelles de mon côté. J'ai galéré pour essayer de remettre en fonction ma pizigate v1. 1ère mise à jour plantée sur le RPi4, j'ai dû remonter mon RPi1B avec un OS neuf pour réussir à remettre le firmware (en 0323 OPDM). De retour sur le RPi4 et configurée dans Abeille, je viens d'avoir l'erreur suivante :

| 2023-09-25 23:05:05 | Abeille | La ruche 2 a été détruite. Veuillez redémarrer Abeille.

Cela a rendu temporairement impossible d'accéder à la page d'Abeille qui affiche Call to a member function getConfiguration() on bool

Après un reboot du système, retour à la normale. Mais même si la ruche 2 semble toujours là, la zigate ne réagit pas à une mise en mode inclusion et des tests d'inclusion ne donnent rien... J'ai bien fait attention à la mettre en mode production avant.

La pizigate semble plus ou moins HS. Durant l'ensemble de mon troubleshoot, j'ai eu l'impression qu'elle répond après un reboot mais qu'elle freeze ensuite. Je te mets les logs pour voir si tu trouves quelque chose pour m'aider à avancer.

AbeilleLogs-230925(1).tar.gz

[tcharp38]

Attention. Tu as le meme canal sur tes 2 zigates. Pas bon ca. Donc passer sur le canal 15 par ex sur ta Zigate 2 (la PI) via sa page equipement.

En dehors de ca je vois que la config de la Z2 ne semble pas se faire completement mais j'ai du mal à reflechir la. Je creuse demain.

[tcharp38]

Bon en dehors d'une sequence de démarrage qui meriterait surement d etre améliorée, et du mauvais canal Zigbee, ca semble ok. La PiZigate passe bien en mode inclusion mais apres plus de trace alors je ne sais pas si tu as tenté d inclure un equipement ou pas.

[eoeir]

Ce sujet est resté en attente pendant plusieurs semaines car je n'avais pas le temps de tester.

Comme je n'ai pas réussi à faire fonctionner ma vieille PiZigate v1 et qu'il y avait trop d'inconnues à résoudre (Zigate HS ? Conf OK sur Raspi v4 ? autre pb de conf ?) j'ai changé d'approche.

J'ai essayé de refaire mon réseau une nouvelle fois (avec un effacement PDM) et en retirant du réseau tous les équipements qui pouvaient être source de perturbation (vieux équipements plus utilisés, en test, ampoule pas tout le temps allumée, équipements générant des erreurs depuis passage en 3.0A...).

Le réseau est redevenu plus stable mais présentant toujours des erreurs NO_ACK récurrentes sur de nombreux équipements. En plus, toujours des soucis avec certains (les Aeotec voir ici ) impossibles à réintégrer.

Donc j'ai fini par repasser en FW 3.22 sans effacement des équipements cette fois ci. Et là, miracle quasi instantané, tous les équipements sont online et j'arrive à réintégrer tout le monde. Et pour l'instant plus aucun NO_ACK dans mes logs.

Donc cela confirme, comme on s'en doutait, que le FW 3.0A est le responsable de mes pbs.

AbeilleLogs-231108.tar.gz

[tcharp38]

J'en étais déja à cette conclusion mais tu confirmes. Oublier le FW 3.A0 et rester en 3.22 pour toute Zigate v2.

Du coup sur cette base que reste il a creuser ? Cote Zigate je ne peux rien faire. Perso je n'ai pas de v2 et je n'y passerai jamais.

[eoeir]

A ce stade je ne vois pas trop quoi faire de plus à part attendre le prochain firmware et cette fois ci migrer plus précautionneusement.

[tcharp38]

Je ferme le sujet.

En résumé, pour la v2, rester en 3.22 et ne PAS BASCULER sur la 3.A0.