Soucis sur mon réseau z-wave

Bison · Avril 4, 2020, 7:07

Bonjour @Mav3656 et merci pour tout ces conseils

Pour ma part ça démarre mal car mon dongle zwave est branché sur mon NAS (Jeedom sur une VM du NAS) qui se trouve dans le meuble TV juste à côté de la box, etc…
Niveau ondes il doit être servi .

Hier j’ai redémarré le daemon pour passer les logs en info et essayer d’analyser un peu. Suite au redémarrage j’ai un nœud qui a été signalé mort dans les alertes (celles visibles en haut en Orange dans Jeedom). J’ai alors voulu le soigner car dans la santé zwave il était bien UP. Ensuite j’ai actionné le module pour fermer le volet. Et bien c’était mort, la queue zwave restait à 1 et n’a fait qu’augmenter quand je faisais des actions. Bref nouveau reboot du daemon.

Qu’entends-tu par ne plus s’appuyer sur OpenZwave ? Que Jeedom devrait intégrer nativement un code maison pour gérer le Zwave ?

EDIT : Par rapport au noeud voisins qui devrait finalement être assez limité, l’idée c’est donc finalement d’avoir plus de bleu que de vert dans la table de routage ?

Mav3656 · Avril 5, 2020, 12:26

Bonjour Bison,

Je te conseille fortement d’utiliser une rallonge USB et d’éloigner ton dongle Z-Wave comme indiqué dans mon message précédent. Cela améliorera sans aucun doute la stabilité de ton réseau.

Si la queue Z-Wave ne fait qu’augmenter, tu fais face à un autre problème qu’un réseau instable. Un réseau instable échoue dans l’envoi des messages mais la queue doit diminuer. Malheureusement j’ai peu de pistes à te proposer pour ce problème et je ne connais pas tes compétences linux. Si ce problème est systématique, tu peux ouvrir un ticket au support. Il n’est pas impossible que ton infrastructure et/ou sa configuration soit remise en cause. Dans ce cas, tu ne dois pas pouvoir piloter un seul de tes modules depuis Jeedom ?

:ligTu peux aussi poster tes logs suite au redémarrage du démon « openzwave » et « openzwaved » en debug (niveau de log à configurer dans la configuration Jeedom, onglet « log » puis redémarrer le démon).

A ma connaissance l’équipe Jeedom est consciente des limitations de la librairie. Peu de communications officielles à ce sujet, mais il n’est pas exclu qu’ils modifient un jour le plugin par du code maison, ou bien une autre librairie se basant sur le SDK Silicon Labs. C’est un autre débat…

Dis comme ça, non… Accordons nous sur la définition « vert=le module(dont l’id figure en début de ligne) pense que ce voisin (dont l’id figure en haut de la colonne) est directement joignable et est susceptible d’essayer de communiquer directement avec lui ». Bien entendu, si le vert n’est pas justifié, (a été acquis dans des conditions différentes lorsque le module n’était pas encastré dans le mur par exemple), la communication échouera et de la latence sera généré par cet échec (attente du timout de la communication). Reformulé autrement : il faut le + de verts possibles. Mais des vrai « verts », lorsque les modules sont à leur emplacement définitif et dans leur conditions réelles d’utilisation.

Attention à la matrice de routage qui donne beaucoup d’informations : à l’exception des associations directes si tu en utilises, les informations importantes sont :

entre le contrôleur et les autres nœuds (première ligne / première colonne - la matrice étant symétrique lorsque tout est en ordre)
entre les nœuds secteurs entre-eux
depuis un nœud à pile vers le contrôleur (et/ou vers les nœuds secteurs). L’important est d’avoir au moins 2 ou 3 voisins directs (minimum), sinon risque de fiabilité du réseau sur le nœud concerné (car en cas d’échec de la communication, il n’y aura pas d’autre route pour retenter la communication).

Communément, les informations de routage entre 2 noeuds à piles ne sont pas forcément intéressantes à analyser (sauf exceptions).

Bonne journée,
Cdt.,
Pierre (Mav3656)
Helper Officiel Jeedom.

Mips · Avril 5, 2020, 5:29

Bonjour,
Il faut aussi attendre, et plus que 30s, quand ça démarre ou qu’un soin global à été lancé, suivant la taille du réseau la queue peut monter très haut et cela pendant 5 min au moins.
Et c’est normal que toutes actions (allumé, éteindre…) ne fasse qu’augmenter celle ci.
Donc éviter de faire plein d’action, ne pas cliquer frénétiquement partout etc : Attendre.

Bison · Avril 5, 2020, 9:05

@Mav3656, ok je vais voir pour acheter ou retrouver une rallonge USB histoire d’éloigner un peu le dongle zwave.

J’observe effectivement 2 phénomènes :

Soit l’ordre n’arrive pas au module (reste à savoir s’il est vraiment envoyé comme le montrait @Domatizer) et il ne se passe donc rien mais en essayant à nouveau 2/3 secondes après, ça fonctionne
Soit l’ordre n’arrive pas au module et je rentre dans le cas ou la queue zwave ne cesse d’augmenter et là, en effet, le réseau zwave devient inutilisable je ne peux plus envoyer ou recevoir aucun ordre.
@Mips, bien sûr j’attends après le reboot que la queue soit à 0 pendant 2/3 minutes avant d’essayer d’envoyer un ordre. Ici je parle d’un problème qui survient aléatoirement au bout de quelques heures à quelques jours. L’état zwave est en network ready avec une queue à 0 et l’ensemble a fonctionné pendant un bon moment avant que ça dérape.

Quand j’observe qu’un ou 2 ordres ne passent pas je vais regarder la queue. Dans le cas ou elle est à plus de 0 c’est cuit. J’ai déjà essayé de faire un « Annule toutes les commandes en cours sur le contrôleur. » mais ça ne donne rien et j’ai beau attendre des heures, le compteur dans la queue ne fait qu’augmenter au fur et à mesure des messages qui ne peuvent pas être traités.

Concernant les logs, je suis passé il y a peu en « info » pour observer un peu ce qu’il se passe quand on envois des ordres.

Même dans le cas ou un ordre est reçu immédiatement, le module continu de discuter un petit moment … c’est normal ?
Exemple :

2020-04-03 22:15:08.923 Info, Node024, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-04-03 22:15:08.964 Info, Node024, SwitchMultilevel::Set - Setting to level 0
2020-04-03 22:15:08.964 Info, Node024, Processing (Send) Nonce Request message (Callback ID=0x53, Expected Reply=0x13)
2020-04-03 22:15:08.964 Info, Node024, Sending (Send) message (Callback ID=0x02, Expected Reply=0x13) - Nonce_Get(SwitchMultilevelCmd_Set) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:09.030 Info, Node024, Request RTT 67 Average Request RTT 269
2020-04-03 22:15:09.111 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:09.112 Info, Node024, Sending (Send) message (Callback ID=0x55, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=24): 0x01, 0x0a, 0x00, 0x13, 0x18, 0x03, 0x26, 0x01, 0x00, 0x25, 0x55, 0xaa
2020-04-03 22:15:09.257 Info, Node024, Request RTT 293 Average Request RTT 281
2020-04-03 22:15:09.257 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x54, Expected Reply=0x04)
2020-04-03 22:15:09.257 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:09.350 Info, Node024, Request RTT 92 Average Request RTT 186
2020-04-03 22:15:09.432 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:09.432 Info, Node024, Sending (Refresh) message (Callback ID=0x56, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x56, 0xa8
2020-04-03 22:15:09.585 Info, Node024, Request RTT 328 Average Request RTT 257
2020-04-03 22:15:09.873 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:09.874 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x11, 0x43, 0xb9, 0x3a, 0xb8, 0x31, 0x3c, 0x59, 0x05, 0x01, 0xce:
2020-04-03 22:15:10.014 Info, Node024, Request RTT 758 Average Request RTT 507
2020-04-03 22:15:10.111 Info, Node024, Response RTT 854 Average Response RTT 573
2020-04-03 22:15:10.111 Info, Node024, Received SwitchMultiLevel report: level=58
2020-04-03 22:15:13.338 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:13.339 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x50, 0xb4, 0xf3, 0x61, 0x6f, 0x84, 0x93, 0xe7, 0x05, 0x01, 0x1a:
2020-04-03 22:15:13.571 Info, Node024, Received Meter report from node 24: Power=99.3W
2020-04-03 22:15:17.988 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x57, Expected Reply=0x04)
2020-04-03 22:15:17.988 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:18.055 Info, Node024, Request RTT 67 Average Request RTT 287
2020-04-03 22:15:18.142 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:18.142 Info, Node024, Sending (Refresh) message (Callback ID=0x58, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x58, 0xa6
2020-04-03 22:15:18.324 Info, Node024, Request RTT 336 Average Request RTT 311
2020-04-03 22:15:19.782 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x7c, 0x7f, 0xca, 0xb8, 0x5d, 0x82, 0x2a, 0x8f, 0x05, 0x01, 0xf8:
2020-04-03 22:15:19.786 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x02, 0x8b, 0xc9, 0xc7, 0xa1, 0x05, 0x0f, 0x6f, 0x05, 0x01, 0xb0:
2020-04-03 22:15:19.792 Info, Node024, Response RTT 5 Average Response RTT 289
2020-04-03 22:15:19.792 Info, Node024, Received SwitchMultiLevel report: level=2
2020-04-03 22:15:22.884 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:22.885 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xf2, 0x44, 0x32, 0x9c, 0x22, 0xdc, 0x02, 0xc5, 0x05, 0x01, 0xd2:
2020-04-03 22:15:23.121 Info, Node024, Received Meter report from node 24: Power=0.0W
2020-04-03 22:15:26.996 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x59, Expected Reply=0x04)
2020-04-03 22:15:26.996 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:27.063 Info, Node024, Request RTT 67 Average Request RTT 287
2020-04-03 22:15:27.142 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:27.142 Info, Node024, Sending (Refresh) message (Callback ID=0x5a, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x5a, 0xa4
2020-04-03 22:15:27.287 Info, Node024, Request RTT 291 Average Request RTT 289
2020-04-03 22:15:27.517 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:27.518 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xca, 0xe0, 0x72, 0x27, 0x63, 0x9d, 0xb6, 0x64, 0x05, 0x01, 0xa0:
2020-04-03 22:15:27.654 Info, Node024, Request RTT 658 Average Request RTT 473
2020-04-03 22:15:27.751 Info, Node024, Response RTT 755 Average Response RTT 522
2020-04-03 22:15:27.751 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:15:36.001 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x5b, Expected Reply=0x04)
2020-04-03 22:15:36.001 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:36.067 Info, Node024, Request RTT 66 Average Request RTT 269
2020-04-03 22:15:36.151 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:36.151 Info, Node024, Sending (Refresh) message (Callback ID=0x5c, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x5c, 0xa2
2020-04-03 22:15:36.296 Info, Node024, Request RTT 295 Average Request RTT 282
2020-04-03 22:15:36.528 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:36.528 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x80, 0x6b, 0x15, 0xa2, 0x48, 0x17, 0x67, 0x19, 0x05, 0x01, 0x8e:
2020-04-03 22:15:37.751 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xbc, 0x45, 0x72, 0xfa, 0x90, 0x88, 0xb5, 0x5b, 0x05, 0x01, 0x74:
2020-04-03 22:15:37.756 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x69, 0x28, 0x83, 0xcc, 0xc5, 0x3a, 0x30, 0xee, 0x05, 0x01, 0xdc:
2020-04-03 22:15:37.758 Info, Node024, Response RTT 1 Average Response RTT 261
2020-04-03 22:15:37.758 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:15:45.006 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x5d, Expected Reply=0x04)
2020-04-03 22:15:45.006 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:45.073 Info, Node024, Request RTT 66 Average Request RTT 269
2020-04-03 22:15:45.151 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:45.151 Info, Node024, Sending (Refresh) message (Callback ID=0x5e, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x5e, 0xa0
2020-04-03 22:15:45.297 Info, Node024, Request RTT 290 Average Request RTT 279
2020-04-03 22:15:45.529 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:45.530 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xd7, 0xf1, 0x3e, 0x11, 0x21, 0x2d, 0xcc, 0x7e, 0x05, 0x01, 0x44:
2020-04-03 22:15:45.746 Info, Node024, Request RTT 739 Average Request RTT 509
2020-04-03 22:15:45.767 Info, Node024, Request RTT 760 Average Request RTT 634
2020-04-03 22:15:45.840 Info, Node024, Response RTT 833 Average Response RTT 547
2020-04-03 22:15:45.840 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:15:52.948 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:52.949 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xa8, 0xbb, 0xa9, 0xc9, 0xe8, 0x76, 0x48, 0xcf, 0x05, 0x01, 0x99:
2020-04-03 22:15:54.012 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x5f, Expected Reply=0x04)
2020-04-03 22:15:54.012 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:54.079 Info, Node024, Request RTT 66 Average Request RTT 350
2020-04-03 22:15:54.162 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:54.162 Info, Node024, Sending (Refresh) message (Callback ID=0x60, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x60, 0x9e
2020-04-03 22:15:54.306 Info, Node024, Request RTT 293 Average Request RTT 321
2020-04-03 22:15:54.674 Info, Node024, Request RTT 662 Average Request RTT 491
2020-04-03 22:15:55.764 Info, Node024, Response RTT 1751 Average Response RTT 1149
2020-04-03 22:15:55.764 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:16:03.020 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x61, Expected Reply=0x04)
2020-04-03 22:16:03.020 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:16:03.087 Info, Node024, Request RTT 66 Average Request RTT 278
2020-04-03 22:16:03.171 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:16:03.172 Info, Node024, Sending (Refresh) message (Callback ID=0x62, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x62, 0x9c
2020-04-03 22:16:03.316 Info, Node024, Request RTT 295 Average Request RTT 286
2020-04-03 22:16:03.540 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:16:03.541 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x5a, 0x61, 0xf2, 0x42, 0xd7, 0x3a, 0x11, 0x5a, 0x05, 0x01, 0xde:
2020-04-03 22:16:03.674 Info, Node024, Request RTT 653 Average Request RTT 469
2020-04-03 22:16:03.770 Info, Node024, Response RTT 749 Average Response RTT 949
2020-04-03 22:16:03.770 Info, Node024, Received SwitchMultiLevel report: level=0

2020-04-03 22:15:27.751 Info, Node024, Received SwitchMultiLevel report: level=0 le volet a fini de descendre et pourtant ça papote encore jusqu’à 2020-04-03 22:16:03.770 Info, Node024, Received SwitchMultiLevel report: level=0, normal ?

Ensuite je vois régulièrement des lignes comme ça je présume que ce n’est pas trop normal :

2020-04-05 10:52:45.173 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:52:46.114 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:52:46.116 Warning, WARNING: Out of frame flow! (0x07). Sending NAK.
2020-04-05 10:53:15.074 Warning, m_currentMsg was NULL when trying to set MaxSendAttempts
2020-04-05 10:53:45.575 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:53:46.524 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:53:46.526 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.
2020-04-05 10:53:47.273 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:53:48.224 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:53:48.226 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.
2020-04-05 10:53:48.227 Warning, WARNING: Out of frame flow! (0x2a). Sending NAK.
2020-04-05 10:53:48.228 Warning, WARNING: Out of frame flow! (0x05). Sending NAK.
2020-04-05 10:53:48.229 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.
2020-04-05 10:53:48.231 Warning, WARNING: Out of frame flow! (0x57). Sending NAK.
2020-04-05 10:54:16.701 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:54:17.644 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:54:17.646 Warning, WARNING: Out of frame flow! (0x07). Sending NAK.
2020-04-05 10:54:51.430 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:54:52.374 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:54:52.376 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.

De ce que j’ai compris cela se produit quand un périphérique utilise le port USB en même temps.

Je suis tombé sur un forum de HomeAssistant qui parle qu’après avoir désactivé le ModemManager.service tout est rentré dans l’ordre. Sauf que sur ma Debian Stretch ce service n’est pas démarré ou n’existe pas. J’ai regardé sur Debian Buster (passage en V4 en cours d’analyse) et il existe bien.

Coté Linux je me débrouille alors si tu as des pistes @Mav3656, je peux regarder sans trop de problème

Domatizer · Avril 5, 2020, 2:25

Merci @Mav3656 pour tous ces bons conseils.

Aucun dongle Z-Wave n’a de véritable antenne comme on peut le voir sur des clés Bluetooth ou Wi-Fi. On remarque bien la différence de portée entre les modules secteurs avec un fil d’antenne et les petits modules sur pile avec des antennes enroulées. Il faudrait une antenne de 8.6 cm pour du 868 MHz.

C’est pour cela qu’on galère ici et ailleurs.

Exactement d’accord, la concurrence du Z-Wave arrive.

@Mav3656 J’aimerais bien connaître ton point de vue concernant la gestion d’openwave avec les noeuds inclus en mode sécurisés ?

J’ai remarqué que lorsque que j’ai un souci, il y a souvent un module sécurisé dans le mauvais coup. C’est soit un module sécurisé qui foire tout seul ou soit un module non sécurisé qui foire lors d’une collision avec un module sécurisé.

Mav3656 · Avril 5, 2020, 8:11

Bonjour,

@Mips a raison, il faut attendre de visualiser le temps qu’a mis le réseau à démarrer dans l’écran « réseau Zwave → résumé » avant toute chose. Un réseau correctement configuré doit démarrer rapidement, quelques minutes max.

En théorie, cela devrait démarrer en quelques secondes, mais à cause des nombreux messages non gérés par la librairie openzwave, on a énormément de timeout. En fait, chaque fois que vous avez le temps de visualiser la queue du contrôleur figée sur un nombre donné (>0) l’espace de quelques secondes, c’est un message non géré (pour un réseau bien configuré et en dehors des pannes matérielles bien sur).

Il faut savoir que les échanges lorsqu’ils fonctionnent sont de l’ordre de la millisecondes, ce qui est déjà extrêmement lent pour un protocole de communication mais n’oublions pas que le protocole répond à des contrainte de basse consommation, d’où le bas débit. On est bien loin des débits gigabytes éthernet, mais à l’échelle humaine on ne devrait absolument pas avoir le temps de se rendre compte de quoi que ce soit.

Yes, c’est la priorité dans ton cas. Cela ne réglera pas tes problèmes de queue qui ne se dépile plus. Mais cela stabilisera tes communications. Lorsque tu auras placé le dongle, il faudra que tu soignes l’ensemble de ton réseau.

Tu n’utiliserais pas l’API REST du plugin Zwave par hasard ? Via un script ou n’importe quoi d’autre ?

Je ne sais pas si c’est le module qui envoie des ordres spontanément. Je crois plus que c’est le plugin Jeedom qui scrute et interroge plusieurs fois en se disant « j’espère bien avoir la bonne réponse à la fin de tout ça ». C’est pareil chez moi. Je te propose de te concentrer sur ce qui te pose vraiment problème (latences et blocage de la queue)

Pour le coup ça je n’ai jamais eu. De ce que je comprend ta machine perd les pédales en parsant les messages (j’ai l’impression que ce sont les messages reçus, mais je ne suis pas sûr sur ce coup là). Si c’est les messages reçus, il se peut que ça vienne des perturbations (introduisant du non sens dans tes trames d’où des erreurs de parsing), et le fait d’éloigner le dongle zwave de toutes perturbations électromagnétiques peut améliorer les choses. Si c’est un problème au niveau des accès à ton port USB sur ta machine, je n’ai pas d’idée dans l’immédiat à part essayer un autre port USB.

Si tu héberges sur autre chose qu’une machine dédiée (un simple raspberry pi suffit), ton problème peut venir d’interactions avec le monde extérieur (tout le reste qui tourne sur cette même machine). C’est l’une des raisons pour lesquelles j’ai exclu l’hébergement de Jeedom sur le Synology. Une autre raison est que lors des mises à jour du DSM, tu ne peux jamais être sûr que tout va continuer de bien fonctionner. D’ailleurs le service est interrompu pendant la mise à jour du Synology. Toutes ces raisons font que je ne trouve pas cette solution viable pour un Jeedom de production, où une qualité de service est attendue. En revanche c’est très bien pour faire du test ou prendre en main l’interface avant d’acheter quoi que ce soit.

Lorsque la queue zwave est bloquée, tu peux essayer de regarder du côté de la commande « htop ». Ca ne va pas te dépanner, mais je suis curieux de savoir si le processus qui héberge ton démon zwave est toujours là et dans quel état. Pour ma part quand j’ai eu ce problème, j’utilisais l’API REST, et je l’ai constaté avec une utilisation du processeur constante. J’ai déjà remonté ce problème, je n’ai pas eu de retour pour l’instant.

source : Queue zwave qui monte après maj zwave ou reboot smart - #5 par Mav3656

@Domatizer Je conseille de faire du sécurisé tant que possible. Il faut bien sur changer la clé Zwave par défaut avant la première inclusion (attention il faut la remettre à chaque mise à jour du plugin !). Je n’ai pas refait les tests effectués par @nechry mais je lui fait confiance, pour dire que seule la payload est chiffrée et que réseau chiffré et non chiffré cohabitent pour le routage. En tant qu’ingénieur et développeur, c’est aussi ce qui me parait le plus logique. Il faudrait vérifier au niveau du protocole pour être 100% sûr.

source : https://nechry-automation.ch/2018/01/22/modifier-cle-de-securite-zwave/
source : https://nechry-automation.ch/2018/01/25/maillage-mixte/

S’il est vrai que l’inclusion sécurisée génère un peu plus de traffic, cela ne devrait pas se sentir à l’échelle humaine. Malheureusement la librairie openzwave n’implémente que très peu de choses, et n’a pas fait des classes de sécurité sa priorité. Nous subissons donc de nombreux timeout sur ce traffic supplémentaire, et donc des ralentissements perceptibles. Cela ne doit en aucun cas se traduire par un ordre qui n’a pas été exécuté. Uniquement des ralentissements.

J’espère avoir répondu à vos questions,
Bonne journée à tous,
Pierre (Mav3656)
Helper Officiel Jeedom.

Domatizer · Avril 7, 2020, 3:18

Merci @Mav3656 pour tes réponses.

Dans la doc du plugin, il est écrit la même chose.

Depuis l’apparition du Z-Wave+, il est possible de sécuriser les échanges entre le contrôleur et les noeuds. Il est donc recommandé de faire les inclusions en mode Sécurisé

C’est ce que j’ai fait au début pour tous les modules et j’ai choisi le Z-Wave pour ça aussi.

J’avais vu cette info bien après. Dommage que la clé ne soit pas modifiable dans Jeedom facilement en début d’installation. Je n’ai pas le courage de tout recommencer. Je ne le ferai pas avant 1 an ou 2 lorsque les ennuis du Z-Wave auront disparus. Car il faut être bien motivé pour exclure puis ré inclure tous les modules…

Ok pour de la latence. Mais certains ordres ne sont bien pas exécutés comme démontrés précédemment.

D’après mes nombreuses lectures sur les forums, mon ressenti est que jusqu’en 2018, openzwave fonctionnait bien. Je ne sais pas qui c’est passé en 2019, mais des gens qui n’avaient pas de soucis avant ont commencé a galérer. D’où ce post [avis] fiabilité z-wave et plugin openzwave
Depuis, peu de mises à jour…

En attendant d’avoir la nouvelle version d’openzwave 1.6 ou autre plugin basé sur le SDK, je cherche à obtenir un réseau stable, même si je n’ai pas accès à toutes les fonctions, mais il faut que que ça marche.

Ma conclusion actuelle est que le mode sécurisé fonctionne, oui mais aléatoirement avec les modules Fibaro Motion Sensor 2. Peut-être que c’est la faute d’autres modules ? Je n’en sais rien mais depuis que ces détecteurs sont non sécurisés, je peux enfin faire confiance en ma gestion de la présence. J’ai laissé tous les capteurs de portes/fenêtre en sécurisé, il y a tout de même des problèmes de collisions, mais cela reste gérable.

Voici les conséquences sur le comptage du nombre de présences confirmées dans la maison.

Passage en mode non sécurisé le 25 mars, pas de changement de scenarii, même matériel, nous sommes toujours 3 personnes présentes, pas de visites depuis début mars et bien confinées depuis mi-mars. Ce nombre ne doit donc pas dépasser 3. En mode sécurisé avant le 25 mars, ça déconnait plusieurs fois par jour. Depuis 2 semaines, c’est clean.

Actuellement, j’en suis entre 0 et 10 lignes d’erreur sur 10000 lignes de log openzwaved (avec un pic d’une trentaine au démarrage). J’ai bien avancé ce moi-ci. Prochaines étapes : passer en non sécurisé les Fibaro Dimmer 2 qui ne le sont pas, puis tous les capteurs de portes et enfin tous les autres modules.

Voilà, malheureusement, je ne suis pas prêt d’aller faire du sécurisé avant un moment…

Bison · Avril 7, 2020, 7:38

Salut et merci pour les explications.

J’ai donc fais quelques modifications.

Je suis passé en V4 from scratch (en installant tout de même des plugins …).
J’ai re-syncrhronisé ma clef zwave et donc réimporté les modules. J’ai dû tous les renommer.
J’ai utilisé une rallonge USB pour éloigner la clefs de la box et du NAS QNAP sur lequel tourne la VM Debian Buster (USB2 indiqué dans la conf de la VM).

Le réseau zwave démarre en 286 secondes (variant suivant les fois).

Déjà dès le départ dans la santé zwave il manque plein de noms. Il suffit d’aller sur l’équipement, de sauver sans rien toucher et le nom apparait dans la santé zwave … ça sent un peu le bug.

Je soigne un noeud, 2 noeuds, j’attends bien que la queue retombe à 0 à chaque fois et pouf au 3eme noeud ça par en vrille.

A ce moment là @Mav3656 voila l’état du htop. Le processus python qui gère le zwave prends tout le CPU et reste comme ça jusqu’à reboot du daemon ou kill du processus en question.

Au départ je me suis dit, bon ben c’est ce module qui pose problème. Je reboot je recommence et ça le fait avec un autre module. Je reboot une 5eme fois et cette fois c’est caremment le module zwave qui ne vois plus les voisins. On tente de soigner le noeud mais ça fait rien et au bout d’un moment le CPU repart à 100%…

Qu’est-ce que c’est énervant

Je pars remettre la clef zwave en directe sur le port USB parce que là visiblement je m’en sort pas !

Bison · Avril 7, 2020, 8:29

Bon évidemment ça marche pas mieux et ça plante également.

Possible que ce soit la clef Zwave qui déconne ? Vous avez déjà eu ce genre de cas ?
Au dernier reboot elle ne voyait même plus de voisins alors que les modules si … c’est totalement incompréhensible.

Je veux bien tenter d’acheter une machine physique avec un SSD pour mettre proxmox dessus à la place du NAS mais je vois moyennement pourquoi ça marcherait mieux …
Qu’est-ce qui se fait de bien pour pas trop cher ? Je trouve les NUC un peu cher quand même.

mich0111 · Avril 7, 2020, 8:57

Bonsoir,
Quel serait ton budget?
Ceci étant, je serais surpris que les problèmes viennent de la plateforme.
J’ai d’abord eu un RPI3 maintenant un miniPC à base de I5.
Mes clés sont toutes branchées côte à côte sur les ports USB du pc et à part le Zigbee pour lequel je perds régulièrement des noeuds, je sais que le problème vient du maillage et je suis en train de l’améliorer, ça tourne comme une horloge.
Auparavant sur RPI3 les clés étaient toutes branchées sur un hub autoalimenté placé juste à côté du RPI. Là encore, pas de problème.
Peut-être la chance, alors j’en profite.

Bison · Avril 7, 2020, 9:06

Salut,

Disons 150-200€, ça me parait pas trop mal. Sauf si c’est moins bien que mon QNAP 253A encore que lui n’a pas que ça a faire tourner … il a tout ses propres services.

Après peut-être que QNAP a une mauvaise gestion des ports USB et de la virtualisation !?
Ou alors comme je disais, que la clef que j’ai (Vision ZU1401-5) est à la ramasse.

C’est pas facile à dire mais j’ai l’impression qu’au départ j’avais moins de soucis, que c’était plutôt invisible à part quelques ordres qui ne passaient pas.
Maintenant depuis que la queue zwave ne dépile plus parce que le processus monte à 100% assez souvent ça devient vraiment galère de faire avec.

Alors ce qui est impossible à dire c’est si c’est à cause d’un problème matériel, d’un update du QNAP ou autre qui a foutu le bronx ou bien à force de rajouter des fonctionnalités et donc d’un confit entre le core et des plugins.

Entre parenthèse, sais-tu si le plugin fullyKiosk fonctionne bien en V4 car ce n’est pas annoncé comme tel et je l’ai tout de même installé sur ma récente V4.

Merki

Domatizer · Avril 7, 2020, 10:19

Bonsoir @Bison

J’ai eu la même réflexion que toi en ce début d’année quand rien ne marchait correctement. J’avais hésité entre idéalement la Jeedom Pro, la JeedUp, un NUC, un vieux PC portable. Mais mettre 200€ ou 400€ dans du matos pour ne pas être sûr du résultat. Je n’ai pas franchi le pas et depuis, en persévérant, cela fonctionne bien mieux. A terme je passerai sur quelque chose de plus puissant car je suis toujours entre 1 et 2 de CPU.

Je suppose que tu as repris ta sauvegarde. Donc Jeedom n’a pas perdu les équipements. Dans un premier temps, ne te lance pas dans des exclusions/inclusions. Il faut d’abord que tu retrouves tous tes modules avec les noms.

Ouais, je trouve aussi que la syncho entre Jeedom/openzwave et la clé est limite. Souvent, dans la configuration, les paramètres du module de l’onglet Paramètre ne correspondent pas avec les paramètres réel du module. Donc, je fais « Actualiser les paramètres » plusieurs fois et je vais réveiller les modules sur piles. Combien de fois j’ai rentré les mêmes valeurs des paramètres inutilement, je croyais que le module les avait perdus, mais en fait, non, c’est Jeedom/openzwave qui n’avait pas les bonnes valeurs.

J’avais lu sur le net qu’il fallait prendre la Aeotec Z-stick Gen 5 et rien d’autre, c’est la meilleure à ce jour. Dans le doute, j’avais pris ce modèle. Je ne voulais pas gratter 30€ pour avoir des emmerdes ensuite.

Il faut que tu règles en priorité tes nœuds inconnus au niveau du plugin.

Mav3656 · Avril 7, 2020, 11:10

Quelque chose se passe mal autour de la communication avec ta clé zwave qui fait planter le démon. Sauf erreur de ma part tu ne m’as pas répondu. Utilises tu par un quelconque moyen l’API REST proposée par le plugin zwave ?

Je n’ai pas de solution miracle a te proposer. En revanche je peux te proposer des tests à faire pour essayer de cibler le ou les problèmes que tu rencontres. Pour commencer je te propose de remettre la rallonge USB pour te mettre dans de bonnes conditions. Ensuite, à des fins de débug et diagnostiques, essaie de faire un test avec un Jeedom from scratch, aucun autre plugin / script ou scénario qui tourne. Essaies d’abord de faire fonctionner tout ton réseau zwave. De pouvoir ne serait-ce que soigner tes noeuds un par un sans jamais que ça plante, envoyer des commandes depuis le dashboard. Ce genre de test. Si déjà ça ne fonctionne pas sur ta plateforme, on peut se poser la question « puisque ça peut marcher, la preuve ça tourne chez d’autres, est-ce que mon problème vient de la clé ou de l’environnement/plateforme sur lequel je le fais tourner ? »

Pour ce faire : t’es il possible de tester ta clé sur un autre hard, si t’as un pc qui traine ou n’importe quoi d’autre, tu installes Jeedom et tu fais que du zwave avec tout ton réseau et tu regardes si tu arrives à tout piloter/soigner ?

Pour résumer, on part du principe que ça peut marcher puisque ça marche chez d’autres. On détermine :

si ça vient de quelque-chose que tu utilises sur Jeedom qui fout la grouille (pour ça on repart from scratch et on met rien d’autre)
si ça vient de l’environnement HOST du Jeedom ou de sa configuration : pour ça on test sur un autre environnement tout simple, un RPI ou vieux pc qu’on met sous debian stretch (version officielle supportée pour Jeedom) et qui fait que ça.
si ça vient de la clé : la faut tester avec une autre clé. Si les tests du dessus ne sont pas concluant, et si tu peux te le permettre, investi quelques dizaines d’euros sur l’Aeotec gen 5 et refait les tests ci dessus. Elle est en vente sur Domadoo, revendeur « de confiance » (c’est mon avis) et SAV irréprochable si t’as un retour faire.

Bon courage

Remarque concernant la clé Aeotec gen5, cette clé a une petite batterie qui te permet de faire des inclusions NON SÉCURISÉE mais facilement dans toute ta maison. Si tu veux faire des inclusions sécurisées il faut la laissée connectée à Jeedom (raison : la clé de sécurité n’est pas contenu dans le contrôleur USB).

Autre remarque : si tu testes avec une autre clé, il faut que tes autres modules ne soient plus appariés à ton ancienne clé. Pour ça tu peux au choix faire des exclusions ou reset tes modules.

Autre remarque : on croit gagner du temps mais parfois c’est plus compliqué de repartir d’un backup que de réinclure les modules proprement. Tu peux reset ton contrôleur zwave dans les actions du plugin zwave. Attention si tu fais ça, tu devras exclure ou reset tes modules pour qu’ils acceptent d’être réinclus. De plus pense à supprimer tes équipements dans le plugin zwave (ou au moins mettre à 0 la valeur du « node I’d » de tes équipements obsolètes si tu ne veux pas les supprimer) avant de réinclure les modules.

Autre remarque : il n’est pas possible de soigner le contrôleur principal. En revanche ce problème se règle facilement en cliquant sur « rafraîchir les infos du module » sur le contrôleur principal. Tu verras apparaître les vrais voisins du contrôleur. Ce problème ne devrait pas arriver en théorie, et je n’ai pas réussi à mettre en évidence une situation pour le reproduire de manière systématique.

J’ai déjà vu ça. De mémoire tu te retrouves dans cette situation si tu utilises le bouton orange « régénérer la détection du nœud » mais ce n’est peut-être pas le seul cas… Comme tu l’as dit tout rentre dans l’ordre en cliquant sur le bouton pour rafraîchir les paramètres. C’est le plugin qui n’avait pas les bonnes infos.

Autre remarque : la Jeedom smart fonctionne très bien et me semble bien dimensionner pour héberger Jeedom, et le service pack power qui vient avec te permet d’avoir un dns à vie avec certificat de sécurité valide pour attaquer en HTTPS. L’hébergement sur EMMC est un bon compromis en rapidité et fiabilité.

Bonne journée à tous,
Pierre (Mav3656)
Helper Officiel Jeedom.

Bison · Avril 8, 2020, 7:04

Salut,

Non justement j’avais installé une Debian Buster pour tester la V4 il y a déjà quelques temps et j’en ai profité pour tout refaire afin de ne conserver que l’essentiel car parfois on test des trucs et on garde les scénarios ou autres widget dont on ne se sert finalement plus.
Les équipements ont été re-crées en appuyant sur « Synchroniser » mais du coup avec les noms par défaut correspondant au modèle. Il me parait donc normal d’avoir eu à les renommer.

En effet, j’ai fini par comprendre ça également. Il suffit de faire un actualiser les paramètres pour reprendre les informations du module, pas de soucis. Ce dont je parle est juste dans la « Santé zwave » ou seul 3 modules sont identifés, les autres sont unknown ce qui est anormal.
Si je retourne sauver les paramètres de l’équipement zwave sans apporter aucune modification le nom correcte apparait dans la « Santé zwave », jusqu’au prochain reboot du Daemon…

J’ai lu sur Domotique-store qu’il fallait éviter cette clef sur RPi4 car problème apparemment avec Buster.
Du coup vu que mon but était de basculer sur la V4 avec une Debian Buster … est-ce que c’est un bon plan de prendre cette clef ? Est-ce que le problème n’est que sur RPi4 et n’apparait pas si Debian Buster est installé sur un PC ?

Pas de noeud réellement inconnus, juste ce bug dans la « Santé zwave »

Le seul truc que j’utilise en API REST me semble t’il (sinon c’est involontaire), c’est une requête Jeedom qui vient d’un autre Jeedom externe afin de le monitorer (il remonte l’état d’une prise). Suite à ta remarque j’avais stoppé le scénario du Jeedom externe qui envoi l’info via API REST.

@Mav3656, ok donc l’idée est de repartir à nouveau sur une Debian Stretch pour toi. Mais on peut tout à fait installer la V4 dessus ?

Je pourrais remonter à nouveau une VM sur le QNAP avec juste Debian Stretch + Jeedom V4 puis Synchroniser la clef et enfin essayer de soigner les noeuds un par un.

Si déjà ça ne fonctionne pas … j’aviserai avec un autre matériel.

Oui je vais surement me laisser tenter suivant le résultat au dessus ou même pour avoir un backup mais même remarque qu’au dessus, est-ce que cette clef fonctionne sur Debian Buster pour la suite ?

Mav3656 · Avril 8, 2020, 9:42

Si ça réapparaît au prochain reboot il y a un truc qui se passe vraiment pas correctement. Comme si des informations n’étaient pas persistées. Peux tu dire si ça fait pareil sous stretch en v4 ? Si oui, veux tu essayer stretch en V3 juste pour le test ?

N’oublie pas de mettre à jour le core et les plugins, et de forcer la réinstallation des dépendances du plugin zwave après une installation.

Pas d’info la dessus.
Stretch étant maintenu jusqu’en juin 2022 tu n’as pas de souci à te faire, je pense qu’il y aura du changement si ce problème existe réellement sur Buster d’ici là. Il sera toujours temps d’y passer plus tard.

Je pense que oui. Pour moi Stretch est la version officiellement supportée, au moins pour la V3. As tu vu ou lu quelque part une information contraire ?

Bonne journée,
Pierre (Mav3656)
Helper Officiel Jeedom.

Madcow · Avril 8, 2020, 9:46

Bonjour,

La clé Aeotec fonctionne sans problème sous Buster et Jeedom v4.

Bon courage !

Tonio16 · Avril 8, 2020, 10:00

Le souci c’est le pi4 avec cette clé.

Antoine

Domatizer · Avril 8, 2020, 10:01

@Bison
Tu es reparti de zéro, c’est lourd de tout recommencer.

Tu avais pourtant un très bon maillage. Donc ton matos était déjà correct. C’est bon signe.
Il aurait été peut-être préférable de continuer sur ton ancienne config et de passer en non sécurisé les modules un par un.

J’ai lu que la clé Aeon n’était pas compatible avec les ports USB3 du RPi4, il fallait passer par un Hub USB2.

En théorie, c’est bien. Mais on ne voit pas trop ce qu’on fait. Ensuite, il faut retrouver ses petits avec les ID lors de la synchronisation. Vu comment une inclusion peut mal se passer, il vaut mieux les faire une par une. Perso, je préfère laisser la clé sur Jeedom pour voir ce qui se passe lors les inclusions.

mich0111 · Avril 8, 2020, 10:55

Salut,
J’ai acheté mon miniPC sur Ali.
Il est basé sur un I5 et m’est revenu à 150€ avec 8go de ram et j’ai ajouté dessus une SSD que j’avais dans un tioir.
Pas de VM, je sais que c’est 'argement surdimensionné mais aucun problème depuis que je l’ai.

Bison · Avril 8, 2020, 11:05

C’est ce que j’ai commencé par faire il y a quelques jours en fait. Passer les 3 modules qui étaient sécurisés en non sécurisés mais comme ça n’a rien arrangé j’ai poursuivi les investigations.

Le problème n’est forcement si régulier que ça, par exemple depuis que j’ai à nouveau remis la rallonge USB comme conseillé et reboot le Daemon zwave, je n’ai rien touché et le réseau fonctionne.
Je suis sûr qu’au bout d’un moment ça va partir en vrille mais je ne sais pas quand.

Ce que j’ai remarqué hier en revanche c’est que je n’arrive pas à soigner les modules puisque assez vite au bout du 2eme, 3eme, 4eme (?), et bien le process python passe à 100% et ne redescend plus.

@mich0111, ok merci

@Madcow et @Tonio16 merci pour la confirmation, il faut donc juste éviter le RPi4 avec cette clef. Ce n’est pas juste un pb de Debian Buster