jjacques68 Posté(e) le 6 mars 2021 Signaler Posté(e) le 6 mars 2021 Hello tout le monde, Merci à ceux qui prendront le temps de lire ces quelques lignes... Je me suis donc mis à sniffer les trames zwave... C'est très intéressant, mais pas toujours compréhensible... (à mon niveau) J'espère ne pas montrer des infos "confidentielles" avec les captures... 1ère découverte à laquelle je ne m'attendais pas, et bien c'est plutôt calme... Je pensais à voir plein de trames dans tous les sens (cf, sniffer LAN avec Wireshark), et bien pas du tout ! Donc c'est plutôt une bonne nouvelle j'imagine. 2ème découverte, et bien faut pas se mélanger les pinceaux avec les ID des modules (colonne Src et Dst) qui sont les "nodeID" et nom l'ID du device dans la base de donnée de la HC3. Certain le savait certainement déjà.. J'ai donc amélioré mon application qui me lister le maillage du réseau zwave, en interrogeant l'API, afin d'afficher les infos nécessaires. Les lignes en grises sont simplement les device qui servent de passerelle pour un autre device. 1ère lecture : Là je viens d'actionner un switch : On voit clairement le chemin que prend la trame avec les sauts de device en device. Ainsi que le retour d'état. Si je compare avec mon soft de maillage : Tout est nickel. 2ème lecture : Là on voit que visiblement, une route n'a pas fonctionnée ?? 28 -> 2 ne répondait pas... donc il a pris 28 -> 3 Par contre je comprends d'où il sort la route 28 -> 2 ?? Parce que clairement, d'après ce que je lis dans mon soft (donc dans l'API), c'est bien 28 -> 3... Et ça revient presque à chaque fois (le node 28 = une tête Danfoss, je dis ça parce que j'ai l'impression que c'est le bordel avec eux... je surveille ça du coin de l'oeil) 3ème lecture : là je constate une erreur (y en a quand même de temps en temps...) cette route n'est pas bonne : elle aurait du être (d'après l'API) : (36) -> 33 -> 34 -> 71 -> 333 -> (1) d'ailleurs quand je vois la ligne CRC_ERROR, tu peux être sûr que je comprends plus la route, comme si elle était perdues 4 ème lecture : Je comprends pas du tout ce scénario ?? qui revient souvent... Surtout que le Node 22 est en lien direct selon l'API... (et au passage, encore une tête Danfoss...) Ben voilà c'est quel le début des aventures Si qqun a des réponses/remarques/explications ... merci d'avance !! 1 1
Lazer Posté(e) le 6 mars 2021 Signaler Posté(e) le 6 mars 2021 Sans certitude, mais je me demande si cette différence entre les route réellement empruntée et la route stockée dans l'API, ne serait pas dû à la différence entre la route dans le sens Contrôleur => Module, et la route dans le sens Module => Contrôleur. Il faudrait tester les 2 cas de figure : - envoi d'un ordre depuis la box - envoi d'un retour d'état depuis le module Ainsi tu verrais si la route empruntée est la même dans les 2 cas. Et sinon, tu sauras à quelle direction de route correspond l'information stockée dans l'API.
jjacques68 Posté(e) le 6 mars 2021 Auteur Signaler Posté(e) le 6 mars 2021 (modifié) Ben c'est l'exemple donné dans le paragraphe "1ère lecture", les routes sont identiques et sont justes (du moins en phase avec ce que je lis dans l'API) Et dans les 2 sens.. Modifié le 6 mars 2021 par jjacques68
kioneoranga Posté(e) le 6 mars 2021 Signaler Posté(e) le 6 mars 2021 Sacré analyse et outil d'investigation. 1
jjacques68 Posté(e) le 6 mars 2021 Auteur Signaler Posté(e) le 6 mars 2021 il y a 1 minute, kioneoranga a dit : Sacré analyse et outil d'investigation. Le soft pour sniffer ne vient pas de moi, mais de Silicon Lab...
Lazer Posté(e) le 6 mars 2021 Signaler Posté(e) le 6 mars 2021 @jjacques68 j'ai l'impression que tu n'as pas compris ce que j'ai écris. Moi je parlais des différences que tu trouves à partir du test n°2. Le test n°1, tout va bien, donc il n'y a rien de plus à en dire
jjacques68 Posté(e) le 6 mars 2021 Auteur Signaler Posté(e) le 6 mars 2021 (modifié) Pas sûr de comprendre ce que tu veux... J'ai donc refait le test avec le device en question, le node 28 (tête Danfoss). J'ai donc modifier sa consigne depuis la box et voici l'échange, avec le retour : Et toujours cette route 28 -> 2 -> 1 au lieu de 28 -> 3 -> 1. edit : pas sûr que l'erreur soit dans l'échange, elle est apparue 2 secondes plus tard... Modifié le 6 mars 2021 par jjacques68
jjacques68 Posté(e) le 6 mars 2021 Auteur Signaler Posté(e) le 6 mars 2021 (modifié) Bon visiblement, J'ai un soucis avec une tête Danfoss (Node 26), à chaque fois qu'un échange se fait (en moyenne exactement toutes les 10 min = correspond au temps de réveil que j'ai fixé), j'ai des erreurs de CRC. Modifié le 6 mars 2021 par jjacques68
kioneoranga Posté(e) le 6 mars 2021 Signaler Posté(e) le 6 mars 2021 Il y a 2 heures, jjacques68 a dit : Le soft pour sniffer ne vient pas de moi, mais de Silicon Lab... C'est outil donc va avec la clé zwave que tu as acheté et reçu en cette semaine ? Ensuite via PC tu peux sniffer directement le réseau zwave? C'est quoi exactement la clé que tu as acheté?
jjacques68 Posté(e) le 6 mars 2021 Auteur Signaler Posté(e) le 6 mars 2021 @kioneoranga : oui tout à fait https://www.mouser.fr/ProductDetail/Silicon-Labs/ACC-UZB3-E-STA?qs=PqoDHHvF64%2B4K0jzr4qA%2BQ%3D%3D 1
TonyC Posté(e) le 7 mars 2021 Signaler Posté(e) le 7 mars 2021 Il y a 15 heures, jjacques68 a dit : à chaque fois qu'un échange se fait (en moyenne exactement toutes les 10 min = correspond au temps de réveil que j'ai fixé), j'ai des erreurs de CRC. pas certain que ton problème vienne de là. Sniffe en te mettant à coté de la tête histoire de voir si le CRC error est toujours là. Peut être laisser le sniiffer tourner pendant qlqs heures, puis filtrer dans data en cochant uniquement wakeup beam. Tiens moi au jus.
TonyC Posté(e) le 7 mars 2021 Signaler Posté(e) le 7 mars 2021 Il y a 18 heures, jjacques68 a dit : Par contre je comprends d'où il sort la route 28 -> 2 ?? Parce que clairement, d'après ce que je lis dans mon soft (donc dans l'API), c'est bien 28 -> 3... Et ça revient presque à chaque fois Remaille la tête, probablement un noeud qui n'existe plus. N'oublie pas de la réveiller pour que ton maillage prenne effet.
jjacques68 Posté(e) le 7 mars 2021 Auteur Signaler Posté(e) le 7 mars 2021 @TonyC : oui en effet, les erreurs de CRC ne viennent pas forcément du device en lui même, mais plutôt d'une mauvaise réception du sniffer... j'ai percuté à tard cela dit, les têtes Danfoss sont quand même montrées du doigt, et pas qu'une... je vais tenter un remesh d'une tête, mais c'est jamais évidemment pour les modules sur pile (réveil, portée, ...) Le reste semble vraiment bien...
TonyC Posté(e) le 7 mars 2021 Signaler Posté(e) le 7 mars 2021 (modifié) Oui c'est bien ça le sniffer ne trappait pas la trame d'où le CRC error. Ben disons que s'il y a vraiment un problème de portée, faudra l'identifier et le résoudre. Le fait d'avoir des noeuds inexistant ne génèrent que des messages supplémentaires qui viennent polluer. D'où l'importance de remesher quand on vire des modules, car les noeuds eux restent toujours dans le registre. Mais c'est quoi le réel problème qu'il te reste? je crois me souvenir que tu avais reparamétrer tes fgrm et que tu n'avais plus de problème de retour d'état, il y a d'autres soucis actuellement? Modifié le 7 mars 2021 par TonyC
jjacques68 Posté(e) le 7 mars 2021 Auteur Signaler Posté(e) le 7 mars 2021 En effet, depuis le re-paramétrage du FGRM, je n'ai plus de soucis. cette affaire de FGRM, m'a emmener sur l'histoire du maillage, qui m'a emmener sur le fait que de temps à autre j'ai des freeze de la box, qui m'a emmener sur l'histoire de sniffer le réseau. Comme quoi ça a fait une sacré route Pour pinailler, j'ai, rarement, une tête Danfoss qui ne réagit pas à l'envoi d'une consigne de la box. Alors je tourne autour, je découvre et finirai par trouver 2
Krikroff Posté(e) le 8 mars 2021 Signaler Posté(e) le 8 mars 2021 Que de mauvais souvenirs avec mes têtes danfoss, cela n’a peut-être rien à voir mais tu peux avoir de gros doutes ! Moi elles sont parties et c’est tant mieux Envoyé de mon iPhone en utilisant Tapatalk 2
mprinfo Posté(e) le 8 mars 2021 Signaler Posté(e) le 8 mars 2021 Moi j'ai 9 danfoss et aucun soucis comme quoi... Envoyé de mon BLA-L29 en utilisant Tapatalk
jjacques68 Posté(e) le 8 mars 2021 Auteur Signaler Posté(e) le 8 mars 2021 (modifié) alors je pense comprendre 1- truc (une chose à la fois ) cette route 36 -> 33 -> 1 ne correspond pas à ce que j'ai dans l'API qui devrait être : 36 -33 - 34 - 71 - 73 - 1 MAIS : le deuxième noeud (33) qui est utilisé dans cette route est lui même directement lié au contrôleur. Donc la route s'arrête au 33, pas la peine de passer par tous les autres ! Il prends un raccourci et ça se vérifie dans plusieurs cas ! Mais la question qui tue, pourquoi le contrôleur ne corrige pas les routes, quand les device eux-mêmes empruntent des raccourcis !! J'ai envie de dire que les routes inscrites dans le "lastWorkingRoute" ne servent à rien du coup !! oulà je me vais me faire gronder... Mais alors pour faire reconstruire une route avec un device sur pile... bonne chance pas encore réussi... Modifié le 8 mars 2021 par jjacques68 1
jjacques68 Posté(e) le 8 mars 2021 Auteur Signaler Posté(e) le 8 mars 2021 (modifié) @TonyC : je confirme, j'ai déplacé le sniffer, plus de soucis de CRC, mais alors plus aucun. Modifié le 8 mars 2021 par jjacques68
TonyC Posté(e) le 8 mars 2021 Signaler Posté(e) le 8 mars 2021 il y a 52 minutes, jjacques68 a dit : J'ai envie de dire que les routes inscrites dans le "lastWorkingRoute" ne servent à rien du coup !! oulà je me vais me faire gronder... Tu l'as peut être dis en tout petit mais tu l'as dit et tu as raison il y a 53 minutes, jjacques68 a dit : Mais alors pour faire reconstruire une route avec un device sur pile c'est quoi le problème ? tu ne trouves pas le bouton de wakeup de ton device ? il y a 43 minutes, jjacques68 a dit : plus de soucis de CRC, mais alors plus aucun Nickel !
jjacques68 Posté(e) le 8 mars 2021 Auteur Signaler Posté(e) le 8 mars 2021 à l’instant, TonyC a dit : 'est quoi le problème ? tu ne trouves pas le bouton de wakeup de ton device ? si si, après avoir cliquer sur remesh avec le bon N° de device, je réveille le module, mais rien... aucune réaction...
jjacques68 Posté(e) le 8 mars 2021 Auteur Signaler Posté(e) le 8 mars 2021 il y a 2 minutes, TonyC a dit : Tu l'as peut être dis en tout petit mais tu l'as dit et tu as raison quoi sur le fait qu'elle servent à rien ou que je vais me faire gronder ?
TonyC Posté(e) le 8 mars 2021 Signaler Posté(e) le 8 mars 2021 tu ne vois pas d'exploreur frame émissent par ton module ?
jjacques68 Posté(e) le 8 mars 2021 Auteur Signaler Posté(e) le 8 mars 2021 nan justement... je pensais voir qqch passé mais rien.
TonyC Posté(e) le 8 mars 2021 Signaler Posté(e) le 8 mars 2021 (modifié) J'ai dis des bêtises ce n'est pas un explorer frame mais tu devrais voir un broadcast ! ça donne ça dans le sniffer : 7 08.03.21 18:56:05.985 9.6K 77 1 0 139 255 FA0B08A8 Broadcast Node Info FA0B08A88B010125FF0101539C0107015E86725A5985738480715670318E229C7AEF208B04 le noeud 139 est celui que je remesh. Tu fais bien reconfigurer "ton device" sur le parent de préférence ? puis tu réveilles le device. dans la console de ta HC après le réveil de ton device tu dois voir ça : [08.03.2021] [19:06:44] [TRACE] [ZWAVE]: 905: Requesting neighbor list from the node is in progress [08.03.2021] [19:06:46] [TRACE] [ZWAVE]: 905: Requesting neighbor list from the node is in progress [08.03.2021] [19:06:49] [TRACE] [ZWAVE]: 905: Requesting neighbor list from the node is in progress [08.03.2021] [19:07:07] [TRACE] [ZWAVE]: 905: New neighbor list received Modifié le 8 mars 2021 par TonyC
Messages recommandés