Soucis sur mon réseau z-wave

mortyre · Mars 25, 2020, 7:29

Un bon moyen de voir si le réseau est floodé par un module et d’allez sur la page configuration du module sur informations nœud et de regarder si il n’arrête pas d’envoyer des messages (dernier message)

Domatizer · Avril 1, 2020, 9:41

Petit retour.

Il y a une semaine, j’avais ré inclu en mode non sécurisé tous mes détecteurs de mouvement Fibaro Motion Sensor. Depuis, la domotique est devenue plus agréable.

Sur ces derniers jours, je n’ai constaté seulement que 2 ratés sur la détection de mouvement. Le capteur reste bloqué à ON jusqu’à ce qu’on repasse devant et qu’il revienne à OFF.

Voici le dernier cas.

Tout, d’abord, je précise que le %OK du module est 100% : aucun message envoyé en erreur.
Le capteur est actif lorsque Burglar = 8 et au repos lorsque Burglar = 0. Il passe au repos 30 secondes après la dernière détection, soit 50 secondes ici. (20:23:07 - 20:23:58)

2020-04-01 20:23:07.251 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:8, status=255
2020-04-01 20:23:07.327 Info, Node126, Received SensorBinary report: Sensor:75 State=On
2020-04-01 20:23:07.330 Info, Node126, Received SensorBinary report: Sensor:67 State=On

2020-04-01 20:23:58.250 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2020-04-01 20:23:58.312 Info, Node126, Received SensorBinary report: Sensor:180 State=Off
2020-04-01 20:23:58.327 Info, Node126, Received SensorBinary report: Sensor:188 State=Off

Plus tard, il s’active de nouveau puis passe au repos 30 secondes après. (20:25:51 - 20:26:26)

2020-04-01 20:25:51.200 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:8, status=255
2020-04-01 20:25:51.262 Info, Node126, Received SensorBinary report: Sensor:75 State=On
2020-04-01 20:25:51.277 Info, Node126, Received SensorBinary report: Sensor:67 State=On

2020-04-01 20:26:26.303 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255

Mais là, il reçoit partiellement l’information, le Burglar = 0 donc c’est bien un passage au repos. En revanche, le SensorBinary n’est pas reçu ! Comme la commande Présence est basée sur le SensorBinary, la détection de mouvement reste bloquée à l’état actif ! Comment peut-on perdre des informations ?
Avant et après cette communication, tout fonctionne bien. Le capteur 127 est passé au repos contrairement au 126.

2020-04-01 20:26:25.500 Info, Node127, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2020-04-01 20:26:26.278 Info, Node127, Received SensorBinary report: Sensor:181 State=Off
2020-04-01 20:26:26.282 Info, Node127, Received SensorBinary report: Sensor:189 State=Off
2020-04-01 20:26:26.303 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2020-04-01 20:27:11.748 Info, Node130, Received SensorMultiLevel report from node 130, instance 1, Temperature: value=20.25C

Finalement, il faudra attendre un nouveau cycle ON/OFF du capteur pour que tout rentre dans l’ordre.

2020-04-01 20:55:49.075 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:8, status=255
2020-04-01 20:55:49.788 Info, Node126, Received SensorBinary report: Sensor:75 State=On
2020-04-01 20:55:50.134 Info, Node126, Received SensorBinary report: Sensor:67 State=On

2020-04-01 20:56:53.678 Info, Node126, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2020-04-01 20:56:53.740 Info, Node126, Received SensorBinary report: Sensor:180 State=Off
2020-04-01 20:56:53.755 Info, Node126, Received SensorBinary report: Sensor:188 State=Off

Ainsi, le capteur était dans le bon état, mais pour Jeedom, il est resté actif pendant 30 minutes de 20:26:26 à 20:56:53, et la lumière aussi…

Dans cet exemple, il n’y a strictement aucun message d’erreur nulle part. Mais, il y a bien erreur sur l’état du capteur.

Domatizer · Avril 1, 2020, 10:56

Autre exemple de perte d’information Z-Wave.

Ici, 3 modules :

un capteur de porte Fibaro Door/Window 2 sécurisé,
un détecteur de présence Fibaro Motion Sensor 2 non-sécurisé
un dimmer Fibaro Dimmer 2 non-sécurisé

J’ai préféré commenter le log que de le mettre en pièce jointe pour faciliter la lecture.

À 18:49:15, j’ouvre la porte, le module galère un peu à communiquer mais j’ai bien Access Control event:22

2020-04-01 18:49:15.064 Info, Node056, Received SecurityCmd_NonceGet from node 56
2020-04-01 18:49:15.065 Info, NONCES: 0xcd, 0x36, 0xa8, 0x69, 0x8f, 0x17, 0x8d, 0x1a
2020-04-01 18:49:15.065 Info, NONCES: 0x25, 0xda, 0xed, 0x73, 0x56, 0xc7, 0xec, 0xf5
2020-04-01 18:49:15.065 Info, NONCES: 0x0b, 0xf6, 0xb6, 0xa1, 0x3b, 0x33, 0xe8, 0xe7
2020-04-01 18:49:15.065 Info, NONCES: 0x83, 0xc5, 0xa0, 0x28, 0x83, 0xc7, 0xd7, 0x64
2020-04-01 18:49:15.065 Info, NONCES: 0x5d, 0x8d, 0x93, 0xc9, 0x2c, 0xd7, 0x3a, 0xed
2020-04-01 18:49:15.065 Info, NONCES: 0xfc, 0x95, 0x8c, 0x46, 0x9b, 0x82, 0xde, 0x20
2020-04-01 18:49:15.065 Info, NONCES: 0x30, 0x30, 0xab, 0x34, 0x9f, 0x19, 0x52, 0x90
2020-04-01 18:49:15.065 Info, NONCES: 0xbf, 0x7b, 0x73, 0x60, 0x8a, 0x4b, 0x31, 0xc9
2020-04-01 18:49:15.065 Info, Node056, Sending (WakeUp) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0x25, 0xda, 0xed, 0x73, 0x56, 0xc7, 0xec, 0xf5, 0x05, 0x01, 0x3a:
2020-04-01 18:49:15.078 Info, Node056, Received SecurityCmd_NonceGet from node 56
2020-04-01 18:49:15.086 Info, NONCES: 0xcd, 0x36, 0xa8, 0x69, 0x8f, 0x17, 0x8d, 0x1a
2020-04-01 18:49:15.087 Info, NONCES: 0x25, 0xda, 0xed, 0x73, 0x56, 0xc7, 0xec, 0xf5
2020-04-01 18:49:15.087 Info, NONCES: 0xb9, 0x57, 0x1c, 0xd4, 0x48, 0x6b, 0xd0, 0xbe
2020-04-01 18:49:15.087 Info, NONCES: 0x83, 0xc5, 0xa0, 0x28, 0x83, 0xc7, 0xd7, 0x64
2020-04-01 18:49:15.087 Info, NONCES: 0x5d, 0x8d, 0x93, 0xc9, 0x2c, 0xd7, 0x3a, 0xed
2020-04-01 18:49:15.087 Info, NONCES: 0xfc, 0x95, 0x8c, 0x46, 0x9b, 0x82, 0xde, 0x20
2020-04-01 18:49:15.087 Info, NONCES: 0x30, 0x30, 0xab, 0x34, 0x9f, 0x19, 0x52, 0x90
2020-04-01 18:49:15.087 Info, NONCES: 0xbf, 0x7b, 0x73, 0x60, 0x8a, 0x4b, 0x31, 0xc9
2020-04-01 18:49:15.087 Info, Node056, Sending (WakeUp) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0xb9, 0x57, 0x1c, 0xd4, 0x48, 0x6b, 0xd0, 0xbe, 0x05, 0x01, 0xb8:
2020-04-01 18:49:15.088 Info, Node056, Received SecurityCmd_NonceGet from node 56
2020-04-01 18:49:15.088 Info, NONCES: 0xcd, 0x36, 0xa8, 0x69, 0x8f, 0x17, 0x8d, 0x1a
2020-04-01 18:49:15.088 Info, NONCES: 0x25, 0xda, 0xed, 0x73, 0x56, 0xc7, 0xec, 0xf5
2020-04-01 18:49:15.089 Info, NONCES: 0xb9, 0x57, 0x1c, 0xd4, 0x48, 0x6b, 0xd0, 0xbe
2020-04-01 18:49:15.089 Info, NONCES: 0x11, 0x7c, 0x45, 0x51, 0x36, 0xd6, 0xcb, 0x80
2020-04-01 18:49:15.089 Info, NONCES: 0x5d, 0x8d, 0x93, 0xc9, 0x2c, 0xd7, 0x3a, 0xed
2020-04-01 18:49:15.089 Info, NONCES: 0xfc, 0x95, 0x8c, 0x46, 0x9b, 0x82, 0xde, 0x20
2020-04-01 18:49:15.089 Info, NONCES: 0x30, 0x30, 0xab, 0x34, 0x9f, 0x19, 0x52, 0x90
2020-04-01 18:49:15.089 Info, NONCES: 0xbf, 0x7b, 0x73, 0x60, 0x8a, 0x4b, 0x31, 0xc9
2020-04-01 18:49:15.089 Info, Node056, Sending (WakeUp) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0x11, 0x7c, 0x45, 0x51, 0x36, 0xd6, 0xcb, 0x80, 0x05, 0x01, 0x01:
2020-04-01 18:49:15.091 Warning, m_currentMsg was NULL when trying to set MaxSendAttempts
2020-04-01 18:49:15.091 Always, 
2020-04-01 18:49:15.092 Always, Dumping queued log messages
2020-04-01 18:49:15.097 Always, 
2020-04-01 18:49:15.097 Always, 
2020-04-01 18:49:15.097 Always, End of queued log message dump
2020-04-01 18:49:15.097 Always, 
2020-04-01 18:49:15.107 Info, Node100, Received Central Scene set from node 100: scene id=1 with key Attribute 2. Sending event notification.
2020-04-01 18:49:15.117 Info, Node100, Value::Set - COMMAND_CLASS_CENTRAL_SCENE - Button - 3 - 1 - true
2020-04-01 18:49:15.182 Warning, m_currentMsg was NULL when trying to set MaxSendAttempts
2020-04-01 18:49:15.182 Always, 
2020-04-01 18:49:15.182 Always, Dumping queued log messages
2020-04-01 18:49:15.182 Always, 
2020-04-01 18:49:15.182 Always, 
2020-04-01 18:49:15.182 Always, End of queued log message dump
2020-04-01 18:49:15.182 Always, 
2020-04-01 18:49:15.183 Info, Node100, Received Central Scene set from node 100: scene id=1 with key Attribute 1. Sending event notification.
2020-04-01 18:49:15.183 Info, Node100, Value::Set - COMMAND_CLASS_CENTRAL_SCENE - Button - 3 - 1 - false
2020-04-01 18:49:15.191 Warning, m_currentMsg was NULL when trying to set MaxSendAttempts
2020-04-01 18:49:15.191 Always, 
2020-04-01 18:49:15.191 Always, Dumping queued log messages
2020-04-01 18:49:15.191 Always, 
2020-04-01 18:49:15.191 Always, 
2020-04-01 18:49:15.191 Always, End of queued log message dump
2020-04-01 18:49:15.191 Always, 
2020-04-01 18:49:15.224 Info, Raw: 0x98, 0x81, 0x1d, 0x02, 0xbe, 0x93, 0x24, 0x3d, 0xc3, 0x33, 0xb9, 0x45, 0x43, 0x66, 0x1e, 0x06, 0x62, 0xcb, 0xab, 0xd3, 0x11, 0x50, 0x91, 0x93, 0x26, 0xc1, 0x71, 0xdb, 0x6a, 0x4b
2020-04-01 18:49:15.224 Info, Node056, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Access Control event:22, status=255

J’entre dans le garage, le détecteur de mouvement me voit 0.3 seconde après.

2020-04-01 18:49:15.511 Info, Node129, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:8, status=255
2020-04-01 18:49:15.573 Info, Node129, Received SensorBinary report: Sensor:180 State=On
2020-04-01 18:49:15.588 Info, Node129, Received SensorBinary report: Sensor:188 State=On

À 18:49:20, un scénario se lance et envoie l’ordre d’allume la lumière.

[2020-04-01 18:49:20][SCENARIO] Exécution de la commande [Garage][Lumiere][Allumer]

Le contrôleur envoie la commande Z-Wave pour allumer la lumière.

2020-04-01 18:49:20.740 Info, Node092, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - \FF
2020-04-01 18:49:20.741 Info, Node092, SwitchMultilevel::Set - Setting to level 255
2020-04-01 18:49:20.741 Info, Node092,   Duration: Default
2020-04-01 18:49:20.741 Info, Node092, Sending (Send) message (Callback ID=0x6f, Expected Reply=0x13) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=92): 0x01, 0x0f, 0x00, 0x13, 0x5c, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0xff, 0xff, 0x25, 0x6f, 0xb7
2020-04-01 18:49:20.767 Info, Node092, Request RTT 26 Average Request RTT 25
2020-04-01 18:49:20.768 Info, Node092, Sending (Refresh) message (Callback ID=0x70, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=92): 0x01, 0x0d, 0x00, 0x13, 0x5c, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0x70, 0xa7
2020-04-01 18:49:20.794 Info, Node092, Request RTT 26 Average Request RTT 25
2020-04-01 18:49:20.805 Info, Node092, Response RTT 36 Average Response RTT 36
2020-04-01 18:49:20.805 Info, Node092, Received a MultiChannelEncap from node 92, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
2020-04-01 18:49:20.805 Info, Node092, Received SwitchMultiLevel report: level=79
2020-04-01 18:49:20.893 Info, Node092, Received SwitchMultiLevel report: level=99
2020-04-01 18:49:21.453 Info, Node092, Received SensorMultiLevel report from node 92, instance 1, Power: value=31.2W
2020-04-01 18:49:26.438 Info, Node092, Received SensorMultiLevel report from node 92, instance 1, Power: value=60.9W

À 18:49:22, je quitte la pièce et je ferme la porte.

2020-04-01 18:49:22.909 Info, Node056, Received SecurityCmd_NonceGet from node 56
2020-04-01 18:49:22.909 Info, NONCES: 0xcd, 0x36, 0xa8, 0x69, 0x8f, 0x17, 0x8d, 0x1a
2020-04-01 18:49:22.909 Info, NONCES: 0x25, 0xda, 0xed, 0x73, 0x56, 0xc7, 0xec, 0xf5
2020-04-01 18:49:22.909 Info, NONCES: 0xb9, 0x57, 0x1c, 0xd4, 0x48, 0x6b, 0xd0, 0xbe
2020-04-01 18:49:22.909 Info, NONCES: 0x11, 0x7c, 0x45, 0x51, 0x36, 0xd6, 0xcb, 0x80
2020-04-01 18:49:22.909 Info, NONCES: 0xad, 0x55, 0x4a, 0xa0, 0xd9, 0x93, 0x86, 0xfd
2020-04-01 18:49:22.909 Info, NONCES: 0xfc, 0x95, 0x8c, 0x46, 0x9b, 0x82, 0xde, 0x20
2020-04-01 18:49:22.910 Info, NONCES: 0x30, 0x30, 0xab, 0x34, 0x9f, 0x19, 0x52, 0x90
2020-04-01 18:49:22.910 Info, NONCES: 0xbf, 0x7b, 0x73, 0x60, 0x8a, 0x4b, 0x31, 0xc9
2020-04-01 18:49:22.910 Info, Node056, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0xad, 0x55, 0x4a, 0xa0, 0xd9, 0x93, 0x86, 0xfd, 0x05, 0x01, 0xf0:

Là, il manque des infos, j’aurais dû avoir quelque chose comme ceci avec un Access Control event:23

Info, Raw: 0x98, 0x81, 0x15, 0x4c, 0x70, 0xf7, 0x10, 0x03, 0x2d, 0xc2, 0xc5, 0x81, 0x76, 0xaa, 0x27, 0x2e, 0xd4, 0xf3, 0xa4, 0x63, 0xcd, 0xdd, 0xde, 0x39, 0xa4, 0xea, 0xcb, 0xde, 0x5b, 0x40
Info, Node056, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Access Control event:23, status=255

Donc, le module de porte a bien envoyé quelque chose, le controleur ne decode pas tout.
Résultat, la porte est toujours ouverte et non pas fermée pour Jeedom.

30 secondes plus tard, à 18:49:46, le détecteur de mouvement retombe à 0.

2020-04-01 18:49:46.510 Info, Node129, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2020-04-01 18:49:46.571 Info, Node129, Received SensorBinary report: Sensor:75 State=Off
2020-04-01 18:49:46.586 Info, Node129, Received SensorBinary report: Sensor:67 State=Off

Un scénario se lance et envoie l’ordre d’éteindre la lumière

[2020-04-01 18:49:48][SCENARIO] Exécution de la commande [Garage][Lumiere][Eteindre]

Le contrôleur envoie la commande Z-Wave pour éteindre la lumière

2020-04-01 18:49:48.336 Info, Node092, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 
2020-04-01 18:49:48.336 Info, Node092, SwitchMultilevel::Set - Setting to level 0
2020-04-01 18:49:48.336 Info, Node092,   Duration: Default

Mais, il manque encore des lignes, le message n’est donc pas envoyé. Je peux comprendre que le contrôleur ne puisse pas reçevoir entièrement un message, mais pas pour enovoyer.
J’aurais dû avoir quelque chose comme ceci.

Info, Node092, Sending (Send) message (Callback ID=0x65, Expected Reply=0x13) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=92): 0x01, 0x0f, 0x00, 0x13, 0x5c, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0x65, 0x42
Info, Node092, Request RTT 26 Average Request RTT 25
Info, Node092, Sending (Refresh) message (Callback ID=0x66, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=92): 0x01, 0x0d, 0x00, 0x13, 0x5c, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0x66, 0xb1
Info, Node092, Request RTT 25 Average Request RTT 25
Info, Node092, Response RTT 36 Average Response RTT 36
Info, Node092, Received a MultiChannelEncap from node 92, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
Info, Node092, Received SwitchMultiLevel report: level=0
Info, Node092, Received SwitchMultiLevel report: level=0
Info, Node092, Received SensorMultiLevel report from node 92, instance 1, Power: value=18.4W
Info, Node092, Received SensorMultiLevel report from node 92, instance 1, Power: value=0.0W

Exactement au même instant, à 18:49:48.336, il y a une communication avec le capteur de porte. Là, je comprends qu’il y a un conflit de communication entre les 2 modules qui causent en même temps. Qu’a prévu de faire le protocole Z-Wave dans le cas de communications simultanées ?

2020-04-01 18:49:48.336 Info, NONCES: 0xcd, 0x36, 0xa8, 0x69, 0x8f, 0x17, 0x8d, 0x1a
2020-04-01 18:49:48.336 Info, NONCES: 0x25, 0xda, 0xed, 0x73, 0x56, 0xc7, 0xec, 0xf5
2020-04-01 18:49:48.336 Info, NONCES: 0xb9, 0x57, 0x1c, 0xd4, 0x48, 0x6b, 0xd0, 0xbe
2020-04-01 18:49:48.337 Info, NONCES: 0x11, 0x7c, 0x45, 0x51, 0x36, 0xd6, 0xcb, 0x80
2020-04-01 18:49:48.337 Info, NONCES: 0xad, 0x55, 0x4a, 0xa0, 0xd9, 0x93, 0x86, 0xfd
2020-04-01 18:49:48.337 Info, NONCES: 0x6d, 0x74, 0x71, 0xc4, 0x3b, 0x5d, 0xb9, 0xf4
2020-04-01 18:49:48.337 Info, NONCES: 0x30, 0x30, 0xab, 0x34, 0x9f, 0x19, 0x52, 0x90
2020-04-01 18:49:48.337 Info, NONCES: 0xbf, 0x7b, 0x73, 0x60, 0x8a, 0x4b, 0x31, 0xc9
2020-04-01 18:49:48.337 Info, Node056, Sending (Send) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0x6d, 0x74, 0x71, 0xc4, 0x3b, 0x5d, 0xb9, 0xf4, 0x05, 0x01, 0x54:
2020-04-01 18:49:48.337 Error, Node056, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-01 18:49:53.069 Info, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep.

Enfin, c’est l’obtention du fameux Dropping command, expected response not received after 1 attempt(s)

Résultat : la lumière n’a pas pu s’éteindre, la porte est considérée comme toujours ouverte pour Jeedom et le chauffage s’est donc arrêté, 50 min en tout… Et tout ça pour avoir été mettre un truc à la poubelle dans le garage.

J’accepte, depuis peu, que le capteur de porte qui fonctionne en mode sécurisé pourrait poser problème. Mais, je ne comprends pas qu’openzwave ou le contrôleur puisse faire de la merde pareil pour envoyer un ordre.

Bison · Avril 2, 2020, 6:26

D’où l’idée d’un plugin qui pourrait compenser une partie du problème (l’envoi des commandes et la vérification de l’action) mais pour le moment il ne rencontre pas un franc succès .

Domatizer · Avril 2, 2020, 4:50

@Bison

J’y ai pensé aussi à ce genre de système, cela me semble bien lourd à mettre en place.
Il faut doubler toutes les commandes de type Action : une commande pour l’état idéal et une autre venant du retour d’état du module. Plus le système (un plugin) qui compare les 2 et qui corrige en cas différence…

Pour l’instant, je préfère m’attaquer aux causes des problèmes et non à leurs conséquences, mais peut-être que cela viendra.

Dans la série des messages qui se perdent, voici un nouvel exemple avec les 2 modules suivants :

un relai contac sec Qubino ZMNHND1 Flush 1D relay non-sécurisé
un dimmer Fibaro Dimmer 2 sécurisé

À 13:50, le relais (Node101) coupe la chaudière correctement

2020-04-02 13:50:22.820 Info, Node101, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - False
2020-04-02 13:50:22.820 Info, Node101, SwitchBinary::Set - Setting node 101 to Off
2020-04-02 13:50:22.820 Info, Node101, Sending (Send) message (Callback ID=0x89, Expected Reply=0x13) - SwitchBinaryCmd_Set (Node=101): 0x01, 0x0a, 0x00, 0x13, 0x65, 0x03, 0x25, 0x01, 0x00, 0x25, 0x89, 0x08
2020-04-02 13:50:22.845 Info, Node101, Request RTT 24 Average Request RTT 40
2020-04-02 13:50:22.846 Info, Node101, Sending (Refresh) message (Callback ID=0x8a, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=101): 0x01, 0x09, 0x00, 0x13, 0x65, 0x02, 0x25, 0x02, 0x25, 0x8a, 0x0a
2020-04-02 13:50:22.871 Info, Node101, Request RTT 24 Average Request RTT 32
2020-04-02 13:50:22.901 Info, Node101, Response RTT 55 Average Response RTT 73
2020-04-02 13:50:22.901 Info, Node101, Received SwitchBinary report from node 101: level=Off
2020-04-02 13:50:23.090 Info, Node101, Received SwitchBinary report from node 101: level=Off

À 14:02, le chauffage doit se rallumer, mais le message n’est bien pas envoyé

2020-04-02 14:02:08.908 Info, Node101, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - True
2020-04-02 14:02:08.908 Info, Node101, SwitchBinary::Set - Setting node 101 to On
2020-04-02 14:02:08.909 Info, Node101, Request RTT 706063 Average Request RTT 353047

À 16:48, je me rends compte que la maison vient de perdre 1°C, je rallume manuellement le chauffage et là l’ordre est bien envoyé.

2020-04-02 16:48:18.730 Info, Node101, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - True
2020-04-02 16:48:18.730 Info, Node101, SwitchBinary::Set - Setting node 101 to On
2020-04-02 16:48:18.731 Info, Node101, Sending (Send) message (Callback ID=0xf3, Expected Reply=0x13) - SwitchBinaryCmd_Set (Node=101): 0x01, 0x0a, 0x00, 0x13, 0x65, 0x03, 0x25, 0x01, 0xff, 0x25, 0xf3, 0x8d
2020-04-02 16:48:18.756 Info, Node101, Request RTT 25 Average Request RTT 176536
2020-04-02 16:48:18.756 Info, Node101, Sending (Refresh) message (Callback ID=0xf4, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=101): 0x01, 0x09, 0x00, 0x13, 0x65, 0x02, 0x25, 0x02, 0x25, 0xf4, 0x74
2020-04-02 16:48:18.781 Info, Node101, Request RTT 24 Average Request RTT 88280
2020-04-02 16:48:18.819 Info, Node101, Response RTT 61 Average Response RTT 67
2020-04-02 16:48:18.819 Info, Node101, Received SwitchBinary report from node 101: level=On
2020-04-02 16:48:18.969 Info, Node101, Received SwitchBinary report from node 101: level=On

Que s’est -il passé à 14:02 ?

Juste avant à 14:02:08, il y a le dimmer sécurisé (Node054) qui cause.

2020-04-02 14:02:08.287 Info, Node054, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-04-02 14:02:08.287 Info, Node054, SwitchMultilevel::Set - Setting to level 0
2020-04-02 14:02:08.287 Info, Node054,   Duration: Default
2020-04-02 14:02:08.287 Info, Node054, Processing (Send) Nonce Request message (Callback ID=0x99, Expected Reply=0x13)
2020-04-02 14:02:08.288 Info, Node054, Sending (Send) message (Callback ID=0x02, Expected Reply=0x13) - Nonce_Get(MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set) - 0x01, 0x09, 0x00, 0x13, 0x36, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-02 14:02:08.311 Info, Node054, Request RTT 23 Average Request RTT 51
2020-04-02 14:02:08.325 Info, Node054, Received SecurityCmd_NonceReport from node 54
2020-04-02 14:02:08.325 Info, Node054, Sending (Send) message (Callback ID=0x9b, Expected Reply=0x13) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=54): 0x01, 0x0f, 0x00, 0x13, 0x36, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0x9b, 0xd6
2020-04-02 14:02:08.354 Info, Node054, Request RTT 66 Average Request RTT 58
2020-04-02 14:02:08.355 Info, Node054, Processing (Refresh) Nonce Request message (Callback ID=0x9a, Expected Reply=0x04)
2020-04-02 14:02:08.355 Info, Node054, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x36, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-02 14:02:08.378 Info, Node054, Request RTT 22 Average Request RTT 40
2020-04-02 14:02:08.393 Info, Node054, Received SecurityCmd_NonceReport from node 54
2020-04-02 14:02:08.393 Info, Node054, Sending (Refresh) message (Callback ID=0x9c, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=54): 0x01, 0x0d, 0x00, 0x13, 0x36, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0x9c, 0x21
2020-04-02 14:02:08.423 Info, Node054, Request RTT 67 Average Request RTT 53
2020-04-02 14:02:08.436 Info, Node054, Received SecurityCmd_NonceGet from node 54
2020-04-02 14:02:08.439 Info, NONCES: 0x2c, 0x71, 0x7b, 0xc6, 0xd3, 0xda, 0xea, 0xcf
2020-04-02 14:02:08.439 Info, NONCES: 0x7d, 0xb6, 0x99, 0xd3, 0x51, 0x14, 0x44, 0x86
2020-04-02 14:02:08.439 Info, NONCES: 0x87, 0x86, 0x1a, 0x5a, 0x61, 0x04, 0x29, 0xde
2020-04-02 14:02:08.439 Info, NONCES: 0x21, 0x77, 0x13, 0x11, 0xf5, 0xff, 0x6b, 0x61
2020-04-02 14:02:08.439 Info, NONCES: 0x73, 0x59, 0xf3, 0xf5, 0x45, 0x3d, 0x5e, 0xb7
2020-04-02 14:02:08.439 Info, NONCES: 0xf7, 0xee, 0xbe, 0xa6, 0x8b, 0xbb, 0xa5, 0xb3
2020-04-02 14:02:08.439 Info, NONCES: 0x12, 0x09, 0x79, 0x25, 0x5d, 0x50, 0x9c, 0x7d
2020-04-02 14:02:08.439 Info, NONCES: 0xc7, 0xaf, 0x8f, 0xbd, 0xae, 0xfa, 0x1e, 0x22
2020-04-02 14:02:08.439 Info, Node054, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x36, 0x0a, 0x98, 0x80, 0x87, 0x86, 0x1a, 0x5a, 0x61, 0x04, 0x29, 0xde, 0x05, 0x01, 0x0e:
2020-04-02 14:02:08.464 Info, Node054, Request RTT 108 Average Request RTT 80
2020-04-02 14:02:08.484 Info, Raw: 0x98, 0x81, 0x1b, 0x7f, 0x1a, 0x03, 0x3c, 0x54, 0xd9, 0x1b, 0x24, 0xe9, 0x95, 0x28, 0x33, 0x20, 0x46, 0xd3, 0x87, 0x53, 0x88, 0x00, 0x11, 0xab, 0x28, 0x11, 0x13, 0x03
2020-04-02 14:02:08.484 Info, Node054, Response RTT 128 Average Response RTT 126
2020-04-02 14:02:08.484 Info, Node054, Received a MultiChannelEncap from node 54, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
2020-04-02 14:02:08.484 Info, Node054, Received SwitchMultiLevel report: level=0
2020-04-02 14:02:08.883 Info, Node054, Received SecurityCmd_NonceGet from node 54
2020-04-02 14:02:08.883 Info, NONCES: 0x2c, 0x71, 0x7b, 0xc6, 0xd3, 0xda, 0xea, 0xcf
2020-04-02 14:02:08.883 Info, NONCES: 0x7d, 0xb6, 0x99, 0xd3, 0x51, 0x14, 0x44, 0x86
2020-04-02 14:02:08.883 Info, NONCES: 0x87, 0x86, 0x1a, 0x5a, 0x61, 0x04, 0x29, 0xde
2020-04-02 14:02:08.883 Info, NONCES: 0xbb, 0xc3, 0xb2, 0x0d, 0xd7, 0xf6, 0x94, 0x82
2020-04-02 14:02:08.883 Info, NONCES: 0x73, 0x59, 0xf3, 0xf5, 0x45, 0x3d, 0x5e, 0xb7
2020-04-02 14:02:08.883 Info, NONCES: 0xf7, 0xee, 0xbe, 0xa6, 0x8b, 0xbb, 0xa5, 0xb3
2020-04-02 14:02:08.883 Info, NONCES: 0x12, 0x09, 0x79, 0x25, 0x5d, 0x50, 0x9c, 0x7d
2020-04-02 14:02:08.883 Info, NONCES: 0xc7, 0xaf, 0x8f, 0xbd, 0xae, 0xfa, 0x1e, 0x22
2020-04-02 14:02:08.883 Info, Node054, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x36, 0x0a, 0x98, 0x80, 0xbb, 0xc3, 0xb2, 0x0d, 0xd7, 0xf6, 0x94, 0x82, 0x05, 0x01, 0x2d:

À 14:02:08.908, l’ordre d’activer le relai de la chaudière commence à être envoyé

2020-04-02 14:02:08.908 Info, Node101, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - True
2020-04-02 14:02:08.908 Info, Node101, SwitchBinary::Set - Setting node 101 to On

Mais au même instant, il y a aussi une communication avec le dimmer

2020-04-02 14:02:08.908 Info, NONCES: 0x2c, 0x71, 0x7b, 0xc6, 0xd3, 0xda, 0xea, 0xcf
2020-04-02 14:02:08.908 Info, NONCES: 0x7d, 0xb6, 0x99, 0xd3, 0x51, 0x14, 0x44, 0x86
2020-04-02 14:02:08.908 Info, NONCES: 0x87, 0x86, 0x1a, 0x5a, 0x61, 0x04, 0x29, 0xde
2020-04-02 14:02:08.908 Info, NONCES: 0xbb, 0xc3, 0xb2, 0x0d, 0xd7, 0xf6, 0x94, 0x82
2020-04-02 14:02:08.908 Info, NONCES: 0xf4, 0x87, 0x71, 0x17, 0x9c, 0xe9, 0x5a, 0x03
2020-04-02 14:02:08.908 Info, NONCES: 0xf7, 0xee, 0xbe, 0xa6, 0x8b, 0xbb, 0xa5, 0xb3
2020-04-02 14:02:08.908 Info, NONCES: 0x12, 0x09, 0x79, 0x25, 0x5d, 0x50, 0x9c, 0x7d
2020-04-02 14:02:08.908 Info, NONCES: 0xc7, 0xaf, 0x8f, 0xbd, 0xae, 0xfa, 0x1e, 0x22
2020-04-02 14:02:08.909 Info, Node054, Sending (Send) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x36, 0x0a, 0x98, 0x80, 0xf4, 0x87, 0x71, 0x17, 0x9c, 0xe9, 0x5a, 0x03, 0x05, 0x01, 0xe4:
2020-04-02 14:02:08.909 Info, Node101, Request RTT 706063 Average Request RTT 353047
2020-04-02 14:02:08.909 Error, Node054, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-02 14:02:08.911 Warning, m_currentMsg was NULL when trying to set MaxSendAttempts
2020-04-02 14:02:08.911 Always,
2020-04-02 14:02:08.911 Always, Dumping queued log messages
2020-04-02 14:02:08.911 Always,
2020-04-02 14:02:08.911 Always,
2020-04-02 14:02:08.911 Always, End of queued log message dump
2020-04-02 14:02:08.911 Always,
2020-04-02 14:02:08.927 Info, Raw: 0x98, 0x81, 0x7d, 0xbd, 0x0f, 0x83, 0x32, 0x88, 0x43, 0x21, 0x73, 0xae, 0xd6, 0x0c, 0xbb, 0x1a, 0xbc, 0x30, 0xbd, 0x8b, 0x8a, 0xda, 0x95, 0x93
2020-04-02 14:02:08.928 Info, Node054, Received SwitchMultiLevel report: level=0
2020-04-02 14:02:09.343 Info, Node054, Received SensorMultiLevel report from node 54, instance 1, Power: value=2.0W
2020-04-02 14:02:19.330 Info, Node054, Received SensorMultiLevel report from node 54, instance 1, Power: value=0.0W

On voit une erreur pour le dimmer (Node054), mais aucune pour le relai alors que l’ordre n’est pas envoyé. Les 2 modules ont pourtant un %OK=100%. Perso, je ne suis pas 100% OK avec ça !

C’est le 2ème exemple où je constate un conflit entre 1 module non sécurisé qui peut ne recevoir un ordre complètement à cause d’un autre module sécurisé qui communique exactement en même temps. Ce conflit de communication s’appelle une collision. Je comprends mieux le côté aléatoire des bugs. En voyant cela, je pense que l’augmentation du nombre de modules dans le réseau n’arrange pas les choses.

Mon réseau possède 63 modules, loin des 232 maximum, avec un bon maillage (les dimmers ont énormément de voisins).

Dans les posts précédents, il a été dit que le plugin peut génèrer des soucis avec le mode sécurisé. Je le comprends POUR les modules sécurisés. Maintenant, est-ce que la mauvaise gestion du mode sécurisé génère aussi des soucis AVEC les modules sécurisés POUR les autres modules non sécurisés ?

Pour ceux qui ont inclus tous leurs modules en mode non sécurisé et qui ont des problèmes, pouvez-vous regarder s’il a des « collisions » comme dans l’exemple ? Mettre le niveau de log en Info au minimum.

Bison · Avril 2, 2020, 5:10

Je vais essayer de fait le même type de debug mais j’ai pas l’habitude encore de ce à quoi il faut s’attendre dans les logs même si tu l’as quand même assez bien expliqué pour tes modules.

Je n’ai plus aucun module en sécurisé depuis quelques jours car j’ai justement remis en non sécurisé 3 modules Fibaro qui était en sécurisé pour voir si c’était mieux. Franchement je ne trouve pas que ça a amélioré les choses (j’ai limite l’impression que c’est pire, bref) puisque encore hier j’ai ouvert le portail et les LED extérieur ne se sont pas allumés.
Dans la journée, plein de fois les ordres envoyés aux volets n’arrivent pas. En tout cas je ne pense pas que je devrais attendre bien longtemps pour avoir un résultat.

J’ai bien moins de modules que toi et le maillage me semble plutôt normal/performant :

EDIT : il faut redémarrer le daemon pour que le niveau de log passe en info (après l’avoir sélectionné) ? ça a pas l’air très verbeux pour le moment.

Domatizer · Avril 2, 2020, 5:26

Merci @Bison

Ton maillage est excellent, en plus tu n’as pas beaucoup de modules. Je peux pas admettre qu’on puisse perdre des infos avec un tel maillage. Si une route peux poser problème, OK. Mais il y tellement de routes possibles, donc c’est inadmissible. Le maillage, c’est disant la force du Z-Wave !

Soigne ton réseau module par module, en priorité les modules qui ne sont pas 100% OK. Entre temps essai d’aller réveiller les modules sur piles. Cela fait beaucoup de communications, tu auras des erreurs, mais bon. Ensuite, redémarre plusieurs fois de suite fois ton réseau. Tu peux aussi redémarrer le réseau après chaque nœud soigné. Le nombre d’erreur devrait baisser…

Bon courage

Oui, sinon tu n’auras pas les lignes « Info » (c’est pénible ce bug aussi de devoir redémarrer pour avoir le log).

Bison · Avril 2, 2020, 5:42

Je ne comprends pas trop cette partie ?
J’avais cru qu’à chaque redémarrage du daemon l’ensemble était perdu est il fallait qu’il reconstruise les routes … non ?

Domatizer · Avril 2, 2020, 9:37

Je ne sais pas exactement ce qu’il fait. Je dirais que l’ensemble n’est pas perdu, les infos sont stockées dans le fichier de configuration zwcfg_0x********.xml. Il remet à jour des routes, la listes des voisins des modules. Les colonnes de la table de routage sont mises à jour après un redémarrage. Après une inclusion, je dois redémarrer le réseau pour compléter les colonnes. Je trouve qu’il y a plus de bénéfices que de risques avec un redémarrage… Si tu le supprimes le fichier de conf XML, là oui, il va devoir tout recréer, c’est ce que j’avais fait pour pouvoir utiliser l’analyseur de log sur le site openzwave (voir plus haut) Soucis sur mon réseau z-wave - #43 par Domatizer

Domatizer · Avril 2, 2020, 10:40

@Bison
Sur l’ancien forum, les conseils de @Mav3656 peuvent répondre à tes questions
https://forum.jeedom.com/viewtopic.php?p=758527

PHB_fr · Avril 3, 2020, 6:20

Bravo et un gros merci pour cette analyse.

Ce qui est étonnant avec ce niveau de précision c’est le silence des helpers et des développeurs. Je pensais qu’avec tout cela un patch serait plus facilement réalisable.

Je m’étonne aussi du fait que certains répondent qu’ils ont pas de problème chez eux. Jeedom pour ses box ont une solution zwave en carte maison ( merci pour la vidéo domotech ) Si ça se trouve il y a une grosse différence de fonctionnement par rapport a l’USB.

C’est peut être pour cela que le problème n’a pas été vu avant alors que pour beaucoup d’entre nous il est général.

Mips · Avril 3, 2020, 6:49

Hello,

2 points:

Attention de ne pas confondre : les développeurs tiers non pas de lien avec les plugins officiels.
On peut aider mais ce n’est pas notre rôle de faire le support la dessus, perso j’ai aussi un boulot…
Si vous voulez une réponse il faut faire un ticket.
je fais partie des gens qui disent qu’ils n’ont « plus » de problèmes car c’est le cas ou très peu. Tout est automatisé et ça fait ce que ça doit quand il faut (et donc je n’analyse pas les logs en détails). BTW je pense qu’il faut mettre le code en parallèle des logs sinon peu de conclusions possible.
Et sur mon install principal j’avais plus de soucis avec ma smart qu’avec mon nuc + clé usb mais la smart est à présent dans une deuxième maison avec très peux de modules et tout fonctionnent aussi.

akenad · Avril 3, 2020, 9:38

Il n’y a pas de différence, un contrôleur Z-Wave qu’il soit GPIO ou USB, expose une interface série.
Plus de détails :
ici : [Présentation] akenad - #4 par akenad
et ici : [RTEX] Odroid-C2 - eMMC - Armbian Buster Kernel 5.3 - Jeedom V4

akenad

PHB_fr · Avril 3, 2020, 4:48

Merci @Mips pour ta precision ! tu as raison de me reprendre Jeedom est OpenSource je n’ai pas a faire un ticket a une entreprise. Je fais plus confiance « sur la communauté » pour des pistes collectifs.

Zut je pensais que USB pouvait être une piste (surtout avec la porté et l’antenne pour un signal plus puissant dommage d’avoir ruiné mon idée @akenad

Je pense que tant que l’on aura pas la solution en version 1.6 de la lib ca restera un problème (meme s’il est apparu pour moi en 2018)

Mav3656 · Avril 4, 2020, 12:36

Bonjour a tous,

Ca discute bien ici j’ai lu plusieurs messages en diagonale et certaines choses avec lesquelles je suis d’accord (beaucoup en fait !)

En complément :

je continue de penser que le zwave est super fiable et à l’heure actuelle sur le podium des protocoles domotiques (oui faut que Jeedom fasse quelque chose pour arrêter d’utiliser ASAP la librairie openzwave au risque de perdre une énorme partie de sa clientèle dès 2020)

Maintenant, pour essayer d’arranger les choses chez vous :

le zwave a vraiment une très mauvaise portée. C’est impressionnant a quel point c’est mauvais et fragile. Heureusement c’est maillé… on est sauvé, il faut bien le régler ! Et bien réglé ca fonctionne
CONSEIL : mettre votre contrôleur Z-Wave (la Smart ou le dongle USB, peu importe ce que vous utilisez) loin de toute perturbation électromagnétique (télé, téléphone fixe, répéteur wifi, câbles électriques…) L’impact est énorme sur la stabilité du réseau. C’est aussi vrai pour les modules.
Il faut inclure les équipements en portée directe du contrôleur, ça beaucoup d’entre vous le savez déjà. Vous éviterez les inclusions non abouties.
CONSEIL : soigner vos noeuds lorsqu’ils sont a leur endroit définitif (pour un module secteur, remettez les caches, couvercles, et ou interrupteurs en place avant de soigner !)
procédez module par module et observez le résultat. Normalement c’est assez rapide de soigner un module. Quelques secondes.
ATTENTION : beaucoup d’entre vous se rassurent d’avoir beaucoup de noeud voisin. Il n’en est rien au contraire. Croire qu’on a un voisin et ne pas réussir a le joindre génère du DROP COMMAND et de la latence. Si des voisins disparaissent lorsque vous soignez le réseau, c’est peut-être bon signe. Avoir moins de voisins mais des voisins proches est gage d’un meilleur réseau, plus stable.
concernant le contrôleur principal : si les voisins du contrôleur principal ne sont pas mis à jour lorsque vous soignez un module (la table de routage devient asymétrique) → vous pouvez « rafraîchir les infos » dans la configuration du noeud représentant le contrôleur (souvent c’est le noeud 1) → ou vous pouvez redémarrer le démon zwave mais ça prend plus de temps !
si vous déplacez des meubles ou faites des travaux, il se peut que vous deviez soignez le réseau. Encore une fois c’est sensible à l’environnement.
RAPPEL : soigner le réseau est un processus qui prend du temps. Les noeuds secteurs se mettent à jour immédiatement. Pensez a réveiller vos noeuds sur pile pour aboutir plus rapidement, et retrouver la stabilité dans votre réseau.
il est indispensable d’avoir aucun NOK dans la vie santé du zwave. Si vous en avez, vous pouvez rafraîchir les infos du noeud concerné. Si ça ne fonctionne pas exclure puis réinclure le noeud
supprimez vos noeuds ou équipements dont l’inclusion a échouée. Pensez a cliquer sur « synchroniser » dans la page du plugin zwave pour les faire apparaître, et supprimez ces noeuds en échec et/ou fantômes.

Très bonne journée a tous
Pierre (Mav3656)
Helper Officiel Jeedom.

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