Aller au contenu

Sniffer Zwave


jjacques68

Messages recommandés

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...

 

image.thumb.png.006e33fc85ae5270454e6ecf316f5d0c.png

 

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.

image.thumb.png.eecf3d4153910c03710b88767343c5ec.png

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 :

image.png.a7b3b3abf416263bf894ed0b44a699e1.png

 

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 :

image.png.841a7f42e11933b9cf665aabec9f1853.png

 

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

image.png.3201dd5d4ce6c30f1ec156ccd976f175.png

 

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 :

image.png.b1c98e02be29453aa52c86629badb2e5.png

 

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...

image.png.39d8d32f4f0e57126073b2f06bfa5253.png

 

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 !!

  • Like 1
  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

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.

 

Lien vers le commentaire
Partager sur d’autres sites

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 :

image.png.c588c3974f009b3194345b1ba7fc3348.png

 

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é par jjacques68
Lien vers le commentaire
Partager sur d’autres sites

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.

image.png.055edb7fb5c2932e380a1de4db8d5307.png

Modifié par jjacques68
Lien vers le commentaire
Partager sur d’autres sites

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é?

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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. 

Lien vers le commentaire
Partager sur d’autres sites

@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...

Lien vers le commentaire
Partager sur d’autres sites

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é par TonyC
Lien vers le commentaire
Partager sur d’autres sites

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 :) 

  • Like 2
Lien vers le commentaire
Partager sur d’autres sites

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

  • Like 2
Lien vers le commentaire
Partager sur d’autres sites

alors je pense comprendre 1- truc (une chose à la fois :) )

 

cette route 36 -> 33 -> 1

 

image.png.f611978d1c6c7a9ca749dc41cc4999bc.png

 

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é par jjacques68
  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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 !

Lien vers le commentaire
Partager sur d’autres sites

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é par TonyC
Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...