Aller au contenu
jjacques68

Sniffer Zwave

Recommended Posts

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

Partager ce message


Lien à poster
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.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par jjacques68

Partager ce message


Lien à poster
Partager sur d’autres sites
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... ;) 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

 

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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é?

Partager ce message


Lien à poster
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.

Partager ce message


Lien à poster
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. 

Partager ce message


Lien à poster
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...

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
Partager sur d’autres sites

Moi j'ai 9 danfoss et aucun soucis comme quoi...

Envoyé de mon BLA-L29 en utilisant Tapatalk

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
Partager sur d’autres sites

@TonyC : je confirme, j'ai déplacé le sniffer, plus de soucis de CRC, mais alors plus aucun. :) 

Modifié par jjacques68

Partager ce message


Lien à poster
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 !

Partager ce message


Lien à poster
Partager sur d’autres sites
à 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...

Partager ce message


Lien à poster
Partager sur d’autres sites
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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites

tu ne vois pas d'exploreur frame émissent par ton module ?

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
Partager sur d’autres sites

×