Dropping command

Bonjour,

Je viens de débuter avec ma box jeedom et malheureusement je suis confronté à un problème !

Mon installation est réalisé sur une RPI4 2G, raspberry pi OS lite, le système est sur une usb 3 de 32Go avec dongle aogen stick 5, sur un hub usb 2.0 (dû au problème de reconnaissance directement sur les ports RPI), 3 pluggin : zwave / jeeexplorer / virtuel

Pour l’instant je n’ai que 7 modules fibaro roller shuter 3 inclu en mode sécurisé.

Lorsque le démon zwave démarre je n’est aucun problème, les modules répondent bien, toutes les commande fonctionnent. Le problème survient après quelques heures, les modules ne repondent plus aux commandes.

Les logs d’erreur en debug ne mentionnent rien de particuliers. Seulement ces lignes :

Error, Node05, ERROR: Dropping command, expected response not received after 1 attempt(s)

Et ceci pour tout les nœuds lorsque j’effectue une action.
La seul solution est de redémarrer le demon…

Si vous avez une idée sur la résolution de ce problème, je suis preneur!

Merci !

Inclusion en mode sécurisé avec la version openzwave courante ne gère pas (mais alors pas bien du tout) le mode sécurisé…
Essaie sur un module de le passer en mode non sécurisé pour voir si cela vient bien de là.

Idem, mode sécurisé = pas bonne idée
il faut recommencer en mode normal, je crains que tu n’ai pas le choix

Merci pour vos réponses !
Je vais tout re inclure en non sécurisé et je reviens vers vous !

Bonjour,

Après la réinclusion des modules en mode non sécurisé j’ai fait plusieurs tests et malheureusement aujourd’hui je suis toujours confronté au même problème avec le même message d’erreur.

Au niveau du graph du réseau tout mes noeuds sont bien présents et vert.

La table de routage est 50% verte et 50% orange ( la route a plus d’un saut)
Ce qui est étonnant c’est que la table de routage est entièrement verte lorsque que je redemarre le demon.

J’ai tenté de ping l’entièreté des noeuds afin de rafraîchir les stats, et le message « Action réalisée avec succès » est apparu mais les stats n’ont pas changés.
J’ai voulu pinger une seconde fois et cette fois ci le message d’erreur « Controler is busy » est apparu.

Avez vous une autre idée afin de résoudre le problème ?

Merci par avance

Cedric

Bonjour,

Et si tu fais « soigner le réseau »?
Si tu as la moitié de ton réseau en orange c’est pas bon du tout.
Regarde aussi ta pile de commande zwave à combien elle est.

J’ai testé mais sans succès :frowning: j’avais le message « controller is busy ».

Quand tu parles de la pile de commande zwave, tu parles de la batterie du controller zwave aotec gen5 ?

Voici l’état actuel de mon réseau :

Ne pas prendre en compte le noeud 23, c’était un test du fgd 212, actuellement débranché :

Le noeud 24 est un motion sensor (1) de neocoolcam

Sur ce screen on voit que toute les routes sont OK.
Lorsque j’ai eu le problème, la partie entourée était entièrement orange.

Après 6h de redémarrage voici l’état des noeuds :

Je recontrolerais ce soir et demain matin pour voir l’évolution.

Je voulais dire en parlant de pile d’actions le nombre de commandes en attente indiqué dans la partie résumé « queue sortante ».
Ton nœud 23 pose problème car vu en dead. Mon expérience perso est que ça peut mettre le bazar dans ton réseau. Désactive le.

J’ai bien désactivé le noeud 23, et j’ai cru une journée que ça avait fonctionné, quasiment 24h sans problème !
Malheureusement le problèmes est revenu avec la même erreur :frowning:

Pour les queues sortantes je n’ai aucun message en attente :

Et mon réseau à l’air OK ?

Je ne sais plus quoi faire :frowning:

Bizarre en effet.
Que dis ta page Santé ?
Un autre truc bizarre : ton log parle de node 5. Mais je vois pas de N 5 dans ton réseau ? Et pourquoi le 1er id commence à 16 ? Tu avais inclu d’autres modules avant ?

Voici la page de santé :

Pour les id des noeuds c’est que j’avais inclu les modules en mode « sécurisé » et il a été conseillé de les reinclures en mode « non sécurisé », l’incrémentation s’est poursuivie lors de la ré-inclusion.

J’ai testé le bouton d’inclusion vi le pluggin et voici les erreurs dans les logs :

2020-08-03 19:21:24.382 Detail, Queuing (Controller) Add Device
2020-08-03 19:21:24.382 Info, Add Device
2020-08-03 19:21:24.382 Detail, contrlr, Queuing (Command) ControllerCommand_AddDevice: 0x01, 0x05, 0x00, 0x4a, 0xc1, 0xa2, 0xd3
2020-08-03 19:21:24.382 Detail, Notification: ControllerCommand - Starting
2020-08-03 19:21:24.386 Detail,
2020-08-03 19:21:24.386 Info, contrlr, Sending (Command) message (Callback ID=0xa2, Expected Reply=0x4a) - ControllerCommand_AddDevice: 0x01, 0x05, 0x00, 0x4a, 0xc1, 0xa2, 0xd3
2020-08-03 19:21:25.386 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-03 19:21:25.386 Detail, contrlr, Removing current message
2020-08-03 19:21:25.386 Detail, contrlr, Notification: Notification - TimeOut
2020-08-03 19:21:25.391 Detail, Notification: ControllerCommand - Error - Failed
2020-08-03 19:21:37.718 Detail, Queuing (Controller) Add Device
2020-08-03 19:21:37.719 Info, Add Device
2020-08-03 19:21:37.719 Detail, contrlr, Queuing (Command) ControllerCommand_AddDevice: 0x01, 0x05, 0x00, 0x4a, 0xc1, 0xa3, 0xd2
2020-08-03 19:21:37.719 Detail, Notification: ControllerCommand - Starting
2020-08-03 19:21:37.723 Detail,
2020-08-03 19:21:37.723 Info, contrlr, Sending (Command) message (Callback ID=0xa3, Expected Reply=0x4a) - ControllerCommand_AddDevice: 0x01, 0x05, 0x00, 0x4a, 0xc1, 0xa3, 0xd2
2020-08-03 19:21:38.723 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-03 19:21:38.723 Detail, contrlr, Removing current message
2020-08-03 19:21:38.723 Detail, contrlr, Notification: Notification - TimeOut
2020-08-03 19:21:38.724 Detail, Notification: ControllerCommand - Error - Failed

Ta page Santé a l’air OK.
On commence à atteindre les limites de mes faibles connaissances.
A tout hasard, as tu essayé de recompiler les dépendances ?
Avais tu bien exclu les modules avant de les réinclure en non-sécurisé ?
Après, je sais que sur pi4 parfois même avec un hub usb2 ça fait des choses bizarres. A tout hasard peux tu essayer avec un autre hub ?

J’ai recompilé les dépendances avant d’avoir reinclue les modules en module non sécurisé.

Je viens de lancer la réinstallation des dépendances, un redemarrage du demon va être effectué. Je reveindrais lorsque ça replantera.
J’ai bien exclu les modules un par un ,sinon je pense que je n’aurais pas pu les reinclures.

Pour ce qui est du RPI je n’ai pas d’autre hub. Je vais en acheter un pour tester. Je peux également ajouter une rallonge usb sur celui ci pour pour voir le comportement.

Une information que je n’ai pas donnés: l’installation se situe dans le garage sur le coffret électrique à côté du DTI et du switch pour le brassage du réseaux, des interférences peuvent elles être lié à mon problème ?

Tant que ta clé n’est pas dans une baie de brassage ça doit passer. C’est sûrement pas le dti ou le switch qui va perturber le signal. De toute façon ta page Santé n’aurait pas été à 100 % OK. Quand des commandes sont perdues le pourcentage baisse.
Pour le reste ton plan d’action me semble cohérent. Mais j’avoue que c’est très bizarre donc je mise sur un problème d’alim. A voir avec un autre hub, mais je ne veux pas te donner de faux espoirs.

J’ai ajouté une rallonge usb entre le hub et le controller zwave, toujours sans optimisation…

J’ai remarqué que le problème ne surviens pas si j’effectue des actions plus ou moins toutes les heures. Aujourd’hui j’ai effectué qu’une action vers 15h et attendu la soirée pour tester. Et le bug est bien présent :frowning:

Les log ci dessous :

2020-08-04 14:55:25.857 Detail, Node017, Notification: ValueChanged
2020-08-04 21:21:56.431 Info, Node019, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-08-04 21:21:56.431 Info, Node019, SwitchMultilevel::Set - Setting to level 0
2020-08-04 21:21:56.431 Detail, Node019, Queuing (Send) SwitchMultilevelCmd_Set (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x26, 0x01, 0x00, 0x25, 0xef, 0x1b
2020-08-04 21:21:56.431 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf0, 0x05
2020-08-04 21:21:56.432 Detail,
2020-08-04 21:21:56.432 Info, Node019, Sending (Send) message (Callback ID=0xef, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x26, 0x01, 0x00, 0x25, 0xef, 0x1b
2020-08-04 21:21:57.432 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:21:57.432 Detail, Node019, Removing current message
2020-08-04 21:21:57.432 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:21:57.436 Detail,
2020-08-04 21:21:57.436 Info, Node019, Sending (Refresh) message (Callback ID=0xf0, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf0, 0x05
2020-08-04 21:21:58.436 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:21:58.436 Detail, Node019, Removing current message
2020-08-04 21:21:58.436 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:22:05.444 Info, mgr, Refreshing node 19: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2020-08-04 21:22:05.444 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf1, 0x04
2020-08-04 21:22:05.444 Detail,
2020-08-04 21:22:05.444 Info, Node019, Sending (Refresh) message (Callback ID=0xf1, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf1, 0x04
2020-08-04 21:22:06.444 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:22:06.444 Detail, Node019, Removing current message
2020-08-04 21:22:06.445 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:22:14.448 Info, mgr, Refreshing node 19: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2020-08-04 21:22:14.448 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf2, 0x07
2020-08-04 21:22:14.448 Detail,
2020-08-04 21:22:14.448 Info, Node019, Sending (Refresh) message (Callback ID=0xf2, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf2, 0x07
2020-08-04 21:22:15.448 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:22:15.449 Detail, Node019, Removing current message
2020-08-04 21:22:15.449 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:22:23.449 Info, mgr, Refreshing node 19: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2020-08-04 21:22:23.449 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf3, 0x06
2020-08-04 21:22:23.450 Detail,
2020-08-04 21:22:23.450 Info, Node019, Sending (Refresh) message (Callback ID=0xf3, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf3, 0x06
2020-08-04 21:22:24.450 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:22:24.450 Detail, Node019, Removing current message
2020-08-04 21:22:24.450 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:22:32.455 Info, mgr, Refreshing node 19: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2020-08-04 21:22:32.569 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf4, 0x01
2020-08-04 21:22:32.569 Detail,
2020-08-04 21:22:32.569 Info, Node019, Sending (Refresh) message (Callback ID=0xf4, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf4, 0x01
2020-08-04 21:22:33.569 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:22:33.569 Detail, Node019, Removing current message
2020-08-04 21:22:33.569 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:22:41.578 Info, mgr, Refreshing node 19: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2020-08-04 21:22:41.578 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf5, 0x00
2020-08-04 21:22:41.578 Detail,
2020-08-04 21:22:41.578 Info, Node019, Sending (Refresh) message (Callback ID=0xf5, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf5, 0x00
2020-08-04 21:22:42.578 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:22:42.578 Detail, Node019, Removing current message
2020-08-04 21:22:42.579 Detail, Node019, Notification: Notification - TimeOut
2020-08-04 21:22:50.587 Info, mgr, Refreshing node 19: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2020-08-04 21:22:50.587 Detail, Node019, Queuing (Refresh) SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf6, 0x03
2020-08-04 21:22:50.587 Detail,
2020-08-04 21:22:50.587 Info, Node019, Sending (Refresh) message (Callback ID=0xf6, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xf6, 0x03
2020-08-04 21:22:51.587 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-08-04 21:22:51.587 Detail, Node019, Removing current message
2020-08-04 21:22:51.587 Detail, Node019, Notification: Notification - TimeOut

Je n’ai lu que la moitié des postes donc désolé si c’est une redite mais après avoir inclus un module, tu le remet à sa place et ensuite il faut bien le soigner et mettre à jour les voisins sinon le réseau le croit toujours à côté du contrôleur.

Faire ça un par un, attendre que les voisins soient correctes avant inclure le suivant

Merci pour le conseil !
J’inclus mes modules directement depuis l’endroit où il est destiné à être. Je dirais que la plus grande distance est d’un 15aine de mètres.

Je vais me résigner à acheter un autre hub usb 2.0.
Et si cela ne fonctionne toujours pas, je vais refaire l’installation de rpi os + jeedom sur une autre clef usb.
PS : voici le hub que j’avais pris lors des problèmes de reconnaissance de clefs, https://www.amazon.fr/Sabrent-HB-MCRM-480Mbit-Noir-concentrateur/dp/B00L2442H0?ref_=ryp_hz_thnk_l_1

Tu inclus à 15m?
Sans compter les murs…

Es tu sur que l’inclusion est complète ?
Le contrôleur est bien dans le groupe lifetime?

En principe une inclusion se fait à 2m du contrôleur.
Dans les fait je n’ai personnellement je n’ai jamais réussi à inclure à plus de 4m ou 5m donc je me demande bien comment ça a pu fonctionner.

1 « J'aime »

Comment je peux savoir si l’inclusion est complète ?
A savoir que mon problème n’est pas présent après le redemarrage du démon. Cela va fonctionner quelque heures puis tomber en heure non stop.

Qu’est-ce que le groupe lifetime ?