Cmde 15/8015, liste des equipements... manquant

[tcharp38]

Salut @KiwiHC16 Si je demande la liste des equipements connus de la Zigate j'obtiens la liste suivante (donc 6 + la zigate)

Sauf que j'en ai bien + que ca.

Si je suppose que ceux en timeout ont du etre degagés à un moment ou un autre, il m'en manque au moins 1 qui lui est bien en vie.

D'ou cela peut il venir ? Une idée ?

Pour info, je bosse sur une fonctionalité de "nettoyage" d'Abeille qui me donne ca pour l'instant:

[KiwiHC16]

Tu ne peux pas proceder comme cela car personne ne sait qui est dans le réseau. La liste retournée par la zigate est la liste des voisines quelles connaient (pour avoir discuté recemment avec eux ou entendu parlé).

Comme le mesh est dynamique ces informations ne sont valide dans le temps que pendant un certain temps apres un timeout ils sont effacés de la memoire. Le meilleur moyen de savoir ce qu'il y a dans le reseau c est de faire un Get LQI. Pendant le Get LQI, si de nouvelles info remontent alors Abeille essaye de recuperer les infos de l equipement. Ce qui fonctionne bien pour les routeurs.

Il y a peut etre un moyen indirect qui serait de recuperer le contenu du PDM (Voir avec le dernier firmware) et de recuperer les IEEE pour lesquels la clef reseau a ete envoyée. Je ne sais meme pas si c est possible.

[tcharp38]

Le mesh peut etre reduit ou etendu certes mais aucun nouveau equipement ne peut y rentrer sans l'accord du coordinateur, donc la zigate. N'est ce pas ? Si tu es d'accord avec ca, elle connait forcement les periphs de son reseau, meme si cachés derriere un routeur. D'ailleurs c'est elle qui attribut l'adresse courte.

Je me trompe ?

[pipiche38]

@tcharp38 il y a eu beaucoup de discutions sur la commande 0x0015 et la réponse 0x8015. Je confirme aussi ce que dit @KiwiHC16 par mon expérience du firmware ZiGate. La réponse donnée via le 0x8015 donne une liste de device qui ont été vu par la ZiGate. On ne sait pas trop la logique qui est derrière, mais cette liste n'est en aucun cas exhaustive .

Pour ma part sur le plugin que j'utilise, au lancement je regarde ce qui est dans cette table et je vérifie que les devices n'ont pas changés de Short Address (si c'est le cas je mets à jour coté plugin).

Je pense que le seul moyen possible pour avoir la liste des équipements appairé de la ZiGate serait interroger la PDM qui elle à cette information. Cependant NXP ne fournie pas d'API pour y accéder

[tcharp38]

Merci à tous les 2 pour vos infos. Du coup je ne comprends pas l'interet de cette commande 0015 et si je veux pouvoir m'assurer que les 2 mondes (Jeedom & Zigate) sont en ligne, on n'a pas actuellement de solution, la zigate n'ayant pas de cmde adequate.

C'est bien ca ?

[pipiche38]

Merci à tous les 2 pour vos infos. Du coup je ne comprends pas l'interet de cette commande 0015 et si je veux pouvoir m'assurer que les 2 mondes (Jeedom & Zigate) sont en ligne, on n'a pas actuellement de solution, la zigate n'ayant pas de cmde adequate.

C'est bien ca ?

Oui

Par contre je pense que la commande est sa réponse a un intérêt, mais pas celui que tu attends qui est d'obtenir la liste exhaustive des devices appairés sur cette ZiGate.

[KiwiHC16]

Le mesh peut etre reduit ou etendu certes mais aucun nouveau equipement ne peut y rentrer sans l'accord du coordinateur, donc la zigate. N'est ce pas ? Si tu es d'accord avec ca, elle connait forcement les periphs de son reseau, meme si cachés derriere un routeur. D'ailleurs c'est elle qui attribut l'adresse courte.

Oui et non. En zigbee si le coordinateur (zigate) n'entend pas un equipement pendant un certain temps elle va l effacer de sa memoire. Si celui ci re-apparait, il y a un protocole pour gérer la situation (conflit d'adresse courte -> reallocation, rejoin,...).

[pipiche38]

Oui et non. En zigbee si le coordinateur (zigate) n'entend pas un equipement pendant un certain temps elle va l effacer de sa memoire. Si celui ci re-apparait, il y a un protocole pour gérer la situation (conflit d'adresse courte -> reallocation, rejoin,...).

@KiwiHC16 tu es sur de ça ? Pour moi l'information est stockée dans la PDM du controleur (et y restera jusqu’à ce qu'il y a Leave du device), afin de pouvoir le cas échéant si le device revient vérifier que le device était bien provisionné . Car effectivement il va y avoir un Device Annoucement sur le réseau (puisque clef déjà connue)

[KiwiHC16]

Ce que j'ai vu c'est que lorsqu'un equipement est sensé déjà avoir la cléf réseau la zigate ne la renvoie pas. Pour pouvoir le re-inclure il faut qu'il fasse un leave pour libérer l'info dans la zigate.

Ma comprehansion c'est que toutes les info dans la zigate sont soumises à timer. La raison etant la flexibilité du reseau et surtout la taille reduite des mémoires. Par exemple si un equipement est cassé, la zigate ne va le voir pendant un certain temps et va l effacer de sa base. C'était un soucis avec les equipments xiaomi et un timer avait été mis au max pour essayer de ne pas les perdre car ils ne font pas de rejoin. Et je crois me souvenir l avoir lu dans la norme mais ca fait longtemps alors peut etre que je me trompe.

[pipiche38]

Je pense que les Xiaomi sont un cas particulier notamment , ils envoient un paquet régulièrement. Pour les devices compatible Zigbee 3.0, le device se met en sommeil et ne communique plus du tout … et cela peut etre pendant une éternité . Quand il se reveille il envoie un Device Annoucement (avec flag de Rejoin) mais il n’y a pas re-association (le réseau n’étant pas ouvert). Et la communication reprend comme si le device n’avait jamais été en sommeil. Ma compréhension est que l’information reste coté Gateway sur l’existence de ce device. Ce qui est par contre vrai c’est que ce device va disparaître des tables de voisinages du fait des timeout, mais reste connu du contrôleur

Voir avec @fairecasoimeme

On 29 Sep 2020, at 13:28, Ben notifications@github.com wrote:

Ce que j'ai vu c'est que lorsqu'un equipement est sensé déjà avoir la cléf réseau la zigate ne la renvoie pas. Pour pouvoir le re-inclure il faut qu'il fasse un leave pour libérer l'info dans la zigate.

Ma comprehansion c'est que toutes les info dans la zigate sont soumises à timer. La raison etant la flexibilité du reseau et surtout la taille reduite des mémoires. Par exemple si un equipement est cassé, la zigate ne va le voir pendant un certain temps et va l effacer de sa base. C'était un soucis avec les equipments xiaomi et un timer avait été mis au max pour essayer de ne pas les perdre car ils ne font pas de rejoin. Et je crois me souvenir l avoir lu dans la norme mais ca fait longtemps alors peut etre que je me trompe.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KiwiHC16/Abeille/issues/1260#issuecomment-700641250, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7IKWTPPBZL2SJY6FCJBG3SIHAFDANCNFSM4R3W7CBQ.

[KiwiHC16]

Il faut vérifier dans la norme. Je vais voir ce que l on trouve dans les PDM que l on peut recuperer avec le firmware 3.1d qui va sortir.

[tcharp38]

@pipiche38, ton dernier commentaire est celui que j'allais ajouter. Le coordinateur doit maintenir une table des devices appairés (donc correspondance short/IEEE). Ca n'est pas possible autrement. Le reseau le plus simple est un coordinateur et des periphs et je ne vois pas ce standard industriel imposer de refaire des inclusions suite à coupure de courant pendant plusieurs jours par ex.

[pipiche38]

Il faut vérifier dans la norme. Je vais voir ce que l on trouve dans les PDM que l on peut recuperer avec le firmware 3.1d qui va sortir.

https://github.com/KiwiHC16/Abeille/issues/1260#issuecomment-700670092

Le firmware 31d ne permet pas d'accéder au PDM sauf si tu prends la version PDMonHost, mais je pense que l'idée est là et entre autre @fairecasoimeme a creusé le sujet à la recherche du pb de corruption de PDM avec le firm 31c

[KiwiHC16]

Oui c est PDMonHost que j ai en tete mais pas encore regardé le sujet en detail.

Sinon vous devez avoir raison, la zigate doit garder les IEEE dans le TC.

[tcharp38]

Je close ce sujet. On verra ce que tu arrives à faire avec PDMonHost