Soucis sur mon réseau z-wave

[Domatizer]

Merci énormément @Mav3656 pour cette traduction de communication sécurisée. Je n’avais jamais lu ce genre d’infos très utile

@Mav3656

Partons du principe que Jeedom a reçu le 1er message, puisqu’il est dans les logs. Hypothèses (non exhaustives

C’est souvent le cas, on voit un début de communication et puis bug…

@Mav3656

il est quand même 3h du mat’ et ça fait une bonne heure que je rédige ce message

Attention à toi

@Mav3656

1.1) Problème de communication entre les 2 modules (le message a bien été émis par Jeesom, mais n’est pas arrivé à cause d’une perturbation électromagnétique (ça peut arriver, c’est pourquoi Zwave fait plusieurs tentatives et demande systématiquement des accusés réception). Quand c’est ça, il faut remettre en cause le positionnement des éléments principalement.

Oui, un problème de communication peut arriver.L Je remarque que j’ai très rarement des messages retransmis (2 en 20h depuis le redémarrage du réseau).

@Mav3656

1.1.1) Si l’ordre n’avait pas été reçu, ce qui n’est pas le cas ici, il faudrait alors vérifier que l’équipement a bien plusieurs routes possibles pour communiquer avec le destinataire du message. En effet, si une seule route possible, les tentatives pour faire parvenir le message à destination s’arrêteront rapidement.

Que du bleu et vert dans la matrice. Donc plusieurs routes possible.

@Mav3656

1.2) Si le positionnement a été remis en cause, et que ce n’est pas la raison 1.1, alors c’est peut-être une défaillance du module qui a émis par erreur une 2ème fois la requête ? Si cela arrive que sur un module et toujours le même, pourquoi pas, la garantie des équipements est là pour ça…

Je ne crois pas à une défaillance des modules. Si c’était le cas, ça ne marcherait pas de façon plus systématique. J’ai pris les marques les plus réputées et acheté les modules en boutiques spécialisées donc pas souci de version non adaptée pour l’Europe que certains peuvent avoir en achetant sur Amazon

@Mav3656

2) Jeedom n’a pas réussi à répondre dans les temps
2.1) Il était occupé à faire autre chose ? Les mécanismes de retry (ZWave) sont là pour couvrir ce genre de cas. Rien à faire dans ce cas mais on devrait voir de l’activité dans les logs ayant lieu en mêmes temps. Donc ici on dirait que ce n’est pas ça.

Je trouve que je ne vois pas beaucoup les mécanismes de retry lorsque ça bug.

@Mav3656

2.2) Représentation du maillage en désaccord avec la réalité. Jeedom a bien essayé d’émettre selon les informations de routage qu’il possède, mais ce ne sont pas les bonnes infos. Là il suffit de soigner le réseau et vérifier que tous les équipements ont bien communiqués pour se mettre à jour (réveiller les noeuds à piles). Ensuite, redémarrer le démon Z-Wave pour visualiser les bonnes infos dans la table de routage.

Sur ce point, je pense que mon maillage est bien clean. J’ai tellement soigner les modules, j’ai redémarrer assez régulièrement ces derniers temps, les modules n’ont pas bougé de place. j’estime que tout est jour.

@Mav3656

2.3) Problème d’alimentation instable du contrôleur ZWave ? De nombreux témoignages indiquent avoir des messages non émis et des erreurs « ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack ». Certaines personnes ont résolu ce problème en connectant le dongle ZWave sur un hub USB auto-alimenté. (Je note que tu es déjà familiarisé avec ce problème puisque tu en as un, mais je note aussi que ton dongle ZWave est branché en direct sur ton Jeedom). Je ne dis pas que c’est ça, je dis juste que c’est « une » possibilité. Pour le savoir, il suffit de brancher ton dongle USB sur un hub USB auto-alimenté (qui n’est pas lui même surchargé pour être sûr qu’il fourni bien l’électricité requise - juste le temps de confirmer/infirmer cette hypothèse).

Dans le doute, j’ai gardé l’alim 3A du Hub USB. Je n’ai pas vu de différence en branchant le dongle sur le Hub, je l’avais mis en direct sur Pi pour éviter les conflits avec la clé GSM. Mais je pourrais encore refaire un essai en mettant tout sur Hub.

@Mav3656

2.4) Problème quelconque, instabilité pouvant résulter de l’architecture matériel, (le raspberry Pi, le QNAP, l’Odroid, peu importe ce qui est utilisé) engendrant un problème d’accès spontané à la ressource USB. Pour s’assurer que ce n’est pas ça, commencer par changer de port USB. Sinon essayer une autre architecture matérielle. (c’est galère, donc à faire en dernier lieu).

Je pense que les ports USB du Pi ne sont pas si robustes, peut-être que je me trompe ? Je voulais faire un essai sur un PC, mais comme tu dis, galère, je n’ai plus le courage de faire comme @Bison

Pour avoir des collisions, je n’ai pas suivi mes propres conseils :

@Domatizer

Alors, pour éviter les collisions, j’ai la solution : j’ouvre la porte, j’attends 2 secondes que le détection soit envoyée, j’allume la lumière à l’interrupteur, j’attends 2 secondes que l’info soit remontée, j’entre dans la pièce, j’attends 2 secondes que la détection soit envoyée

J’ai fait exprès de fermer la porte juste au moment où lumière s’allume comme un vicelard.
Bah c’est difficile de ne pas avoir de collision, mais c’est aussi difficile aussi d’en avoir !

J’ai réussi avoir une collision entre le module sécurisé et le module non sécurisé (déjà présenté dans un de mes précédents posts)

Le Fibaro Door Sensor 2 sécurisé (Node056) communique une première fois lorsque la porte s’ouvre

2020-04-13 15:39:35.200 Detail, Node056,   Received: 0x01, 0x08, 0x00, 0x04, 0x00, 0x38, 0x02, 0x98, 0x40, 0x11
2020-04-13 15:39:35.200 Info, Node056, Received SecurityCmd_NonceGet from node 56
2020-04-13 15:39:35.200 Info, NONCES: 0x97, 0xff, 0xcf, 0xce, 0x1a, 0xc4, 0x8f, 0x0e
2020-04-13 15:39:35.201 Info, NONCES: 0xb6, 0x62, 0x29, 0x49, 0xe3, 0xd3, 0x0b, 0xfa
2020-04-13 15:39:35.201 Info, NONCES: 0x81, 0x5f, 0xac, 0x89, 0x48, 0x8b, 0x5d, 0x58
2020-04-13 15:39:35.201 Info, NONCES: 0xc4, 0xca, 0xdd, 0x15, 0xbb, 0x8d, 0xe2, 0x5a
2020-04-13 15:39:35.201 Info, NONCES: 0x39, 0x80, 0x69, 0x1c, 0xeb, 0x0b, 0xf0, 0xb6
2020-04-13 15:39:35.201 Info, NONCES: 0x30, 0xa3, 0x74, 0x09, 0xeb, 0x83, 0xa8, 0x92
2020-04-13 15:39:35.201 Info, NONCES: 0xb4, 0xa3, 0xf0, 0x97, 0x42, 0xc2, 0xd1, 0x3e
2020-04-13 15:39:35.201 Info, NONCES: 0x24, 0xc1, 0x5d, 0x8b, 0xd2, 0xf2, 0xcc, 0xe6
2020-04-13 15:39:35.201 Info, Node056, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0x97, 0xff, 0xcf, 0xce, 0x1a,$
2020-04-13 15:39:35.209 Detail,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-04-13 15:39:35.209 Detail,   ZW_SEND_DATA delivered to Z-Wave stack
2020-04-13 15:39:35.471 Detail,   Received: 0x01, 0x07, 0x00, 0x13, 0x01, 0x00, 0x00, 0x1b, 0xf1
2020-04-13 15:39:35.471 Detail,   ZW_SEND_DATA Request with callback ID 0x01 received (expected 0x01)
2020-04-13 15:39:35.642 Detail, Node056,   Received: 0x01, 0x23, 0x00, 0x04, 0x00, 0x38, 0x1d, 0x98, 0x81, 0xab, 0xe8, 0xd8, 0x0b, 0x35, 0x5b, 0x6a, 0x4b, 0x9a, 0xa8, 0x64, 0xfe, 0x6e, 0xb5, 0xd0, 0x$
2020-04-13 15:39:35.642 Info, Raw: 0x98, 0x81, 0xab, 0xe8, 0xd8, 0x0b, 0x35, 0x5b, 0x6a, 0x4b, 0x9a, 0xa8, 0x64, 0xfe, 0x6e, 0xb5, 0xd0, 0xfc, 0xce, 0xc9, 0x97, 0x23, 0x9e, 0xcd, 0x88, 0x4d, 0x7c, 0x$
2020-04-13 15:39:35.642 Detail, Node056, Decrypted Packet: 0x00, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x06, 0x16, 0x00
2020-04-13 15:39:35.642 Detail,
2020-04-13 15:39:35.642 Info, Node056, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Access Control event:22, status=255
2020-04-13 15:39:35.642 Detail, Node056, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:35.642 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:35.642 Detail, Node056, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:35.642 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:35.642 Detail, Node056, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:35.642 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:35.642 Detail, Node056, Refreshed Value: old value=23, new value=22, type=byte
2020-04-13 15:39:35.642 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:35.642 Detail, Node056, Refreshed Value: old value=96, new value=75, type=byte
2020-04-13 15:39:35.642 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:35.643 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:35.648 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:35.652 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:35.656 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:35.661 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:36.236 Detail, Node116,   Received: 0x01, 0x0f, 0x00, 0x04, 0x00, 0x74, 0x09, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0x08, 0x00, 0x0d
2020-04-13 15:39:36.236 Detail,

Tout s’est bien passé, le détecteur de présence Fibaro Motion Sensor non sécurisé (Node0129) me voit

2020-04-13 15:39:38.121 Detail, Node129,   Received: 0x01, 0x0f, 0x00, 0x04, 0x00, 0x81, 0x09, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0x08, 0x00, 0xf8
2020-04-13 15:39:38.122 Detail,
2020-04-13 15:39:38.122 Info, Node129, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:8, status=255
2020-04-13 15:39:38.122 Detail, Node129, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:38.122 Detail, Node129, Changes to this value are not verified
2020-04-13 15:39:38.122 Detail, Node129, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:38.122 Detail, Node129, Changes to this value are not verified
2020-04-13 15:39:38.122 Detail, Node129, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:38.122 Detail, Node129, Changes to this value are not verified
2020-04-13 15:39:38.122 Detail, Node129, Refreshed Value: old value=0, new value=8, type=byte
2020-04-13 15:39:38.122 Detail, Node129, Changes to this value are not verified
2020-04-13 15:39:38.122 Detail, Node129, Notification: ValueChanged
2020-04-13 15:39:38.137 Detail, Node129, Notification: ValueChanged
2020-04-13 15:39:38.158 Detail, Node129, Notification: ValueChanged
2020-04-13 15:39:38.174 Detail, Node129, Notification: ValueChanged
2020-04-13 15:39:38.209 Detail, Node129,   Received: 0x01, 0x09, 0x00, 0x04, 0x08, 0x81, 0x03, 0x30, 0x03, 0xff, 0xb4
2020-04-13 15:39:38.209 Detail,
2020-04-13 15:39:38.209 Info, Node129, Received SensorBinary report: Sensor:180 State=On
2020-04-13 15:39:38.209 Detail, Node129, Refreshed Value: old value=false, new value=true, type=bool
2020-04-13 15:39:38.209 Detail, Node129, Changes to this value are not verified
2020-04-13 15:39:38.209 Detail, Node129, Notification: ValueChanged
2020-04-13 15:39:38.241 Detail, Node129,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x81, 0x03, 0x30, 0x03, 0xff, 0xbc
2020-04-13 15:39:38.241 Detail,
2020-04-13 15:39:38.241 Info, Node129, Received SensorBinary report: Sensor:188 State=On
2020-04-13 15:39:38.242 Detail, Node129, Refreshed Value: old value=true, new value=true, type=bool
2020-04-13 15:39:38.242 Detail, Node129, Changes to this value are not verified
2020-04-13 15:39:38.242 Detail, Node129, Notification: ValueChanged
2020-04-13 15:39:41.673 Detail, Node106,   Received: 0x01, 0x0f, 0x00, 0x04, 0x00, 0x6a, 0x09, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0x08, 0x00, 0x13
2020-04-13 15:39:41.673 Detail,

Puis un scénario s’éxécute pour allumer la lumière

Ensuite, je ferme la porte, une communication avec le module de porte (Node056) commence

2020-04-13 15:39:41.719 Detail, Node056,   Received: 0x01, 0x08, 0x00, 0x04, 0x00, 0x38, 0x02, 0x98, 0x40, 0x11
2020-04-13 15:39:41.719 Info, Node056, Received SecurityCmd_NonceGet from node 56
2020-04-13 15:39:41.720 Info, NONCES: 0x97, 0xff, 0xcf, 0xce, 0x1a, 0xc4, 0x8f, 0x0e
2020-04-13 15:39:41.720 Info, NONCES: 0x52, 0xdb, 0x57, 0x92, 0x0b, 0xa9, 0x2b, 0x10
2020-04-13 15:39:41.720 Info, NONCES: 0x81, 0x5f, 0xac, 0x89, 0x48, 0x8b, 0x5d, 0x58
2020-04-13 15:39:41.720 Info, NONCES: 0xc4, 0xca, 0xdd, 0x15, 0xbb, 0x8d, 0xe2, 0x5a
2020-04-13 15:39:41.720 Info, NONCES: 0x39, 0x80, 0x69, 0x1c, 0xeb, 0x0b, 0xf0, 0xb6
2020-04-13 15:39:41.720 Info, NONCES: 0x30, 0xa3, 0x74, 0x09, 0xeb, 0x83, 0xa8, 0x92
2020-04-13 15:39:41.720 Info, NONCES: 0xb4, 0xa3, 0xf0, 0x97, 0x42, 0xc2, 0xd1, 0x3e
2020-04-13 15:39:41.720 Info, NONCES: 0x24, 0xc1, 0x5d, 0x8b, 0xd2, 0xf2, 0xcc, 0xe6
2020-04-13 15:39:41.721 Info, Node056, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0x52, 0xdb, 0x57, 0x92, 0x0b,$

Entre temps, le Fibaro Dimmer 2 non sécurisé (Node092) doit s’allumer, l’ordre commence à être envoyé

2020-04-13 15:39:41.730 Info, Node092, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - �
2020-04-13 15:39:41.730 Info, Node092, SwitchMultilevel::Set - Setting to level 255
2020-04-13 15:39:41.730 Info, Node092,   Duration: Default
2020-04-13 15:39:41.730 Detail, Node092, Queuing (Send) MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Set (Node=92): 0x01, 0x0f, 0x00, 0x13, 0x5c, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x$
2020-04-13 15:39:41.731 Detail, Node092, Queuing (Refresh) MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=92): 0x01, 0x0d, 0x00, 0x13, 0x5c, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26,$
2020-04-13 15:39:41.733 Detail,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-04-13 15:39:41.733 Detail,   ZW_SEND_DATA delivered to Z-Wave stack
2020-04-13 15:39:41.733 Detail,

Au même instant, la communication avec le module de porte (Node056) continue avec une erreur de Dropping command

2020-04-13 15:39:41.733 Info, NONCES: 0x97, 0xff, 0xcf, 0xce, 0x1a, 0xc4, 0x8f, 0x0e
2020-04-13 15:39:41.733 Info, NONCES: 0x52, 0xdb, 0x57, 0x92, 0x0b, 0xa9, 0x2b, 0x10
2020-04-13 15:39:41.733 Info, NONCES: 0x9d, 0x5f, 0xad, 0x01, 0x6b, 0x03, 0x99, 0xad
2020-04-13 15:39:41.733 Info, NONCES: 0xc4, 0xca, 0xdd, 0x15, 0xbb, 0x8d, 0xe2, 0x5a
2020-04-13 15:39:41.733 Info, NONCES: 0x39, 0x80, 0x69, 0x1c, 0xeb, 0x0b, 0xf0, 0xb6
2020-04-13 15:39:41.734 Info, NONCES: 0x30, 0xa3, 0x74, 0x09, 0xeb, 0x83, 0xa8, 0x92
2020-04-13 15:39:41.734 Info, NONCES: 0xb4, 0xa3, 0xf0, 0x97, 0x42, 0xc2, 0xd1, 0x3e
2020-04-13 15:39:41.734 Info, NONCES: 0x24, 0xc1, 0x5d, 0x8b, 0xd2, 0xf2, 0xcc, 0xe6
2020-04-13 15:39:41.734 Info, Node056, Sending (Send) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x38, 0x0a, 0x98, 0x80, 0x9d, 0x5f, 0xad, 0x01, 0x6b, 0x$
2020-04-13 15:39:41.734 Error, Node056, ERROR: Dropping command, expected response not received after 1 attempt(s)

Puis l’ordre d’allumer la lumière est supprimé

2020-04-13 15:39:41.734 Detail, Node092, Removing current message
2020-04-13 15:39:41.736 Detail,   Received: 0x01, 0x04, 0x01, 0x13, 0x00, 0xe9
2020-04-13 15:39:41.736 Error, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2020-04-13 15:39:41.980 Detail,   Received: 0x01, 0x07, 0x00, 0x13, 0x01, 0x00, 0x00, 0x19, 0xf3
2020-04-13 15:39:41.981 Detail,   ZW_SEND_DATA Request with callback ID 0x01 received (expected 0x01)

Le module de porte termine sa communication et la porte est bien fermée dans Jeedom.

2020-04-13 15:39:42.152 Detail, Node056,   Received: 0x01, 0x23, 0x00, 0x04, 0x00, 0x38, 0x1d, 0x98, 0x81, 0x09, 0x3e, 0x3c, 0x6d, 0x2a, 0x22, 0xe5, 0x1c, 0x1e, 0x1d, 0x4b, 0xc2, 0xf9, 0xb9, 0x58, 0x$
2020-04-13 15:39:42.152 Info, Raw: 0x98, 0x81, 0x09, 0x3e, 0x3c, 0x6d, 0x2a, 0x22, 0xe5, 0x1c, 0x1e, 0x1d, 0x4b, 0xc2, 0xf9, 0xb9, 0x58, 0x68, 0x9e, 0x59, 0x52, 0x99, 0x44, 0x84, 0x2e, 0x7e, 0xe8, 0x$
2020-04-13 15:39:42.153 Detail, Node056, Decrypted Packet: 0x00, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x06, 0x17, 0x00
2020-04-13 15:39:42.153 Detail,
2020-04-13 15:39:42.153 Info, Node056, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Access Control event:23, status=255
2020-04-13 15:39:42.153 Detail, Node056, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:42.153 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:42.153 Detail, Node056, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:42.153 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:42.153 Detail, Node056, Refreshed Value: old value=0, new value=0, type=byte
2020-04-13 15:39:42.153 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:42.153 Detail, Node056, Refreshed Value: old value=22, new value=23, type=byte
2020-04-13 15:39:42.153 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:42.153 Detail, Node056, Refreshed Value: old value=75, new value=28, type=byte
2020-04-13 15:39:42.153 Detail, Node056, Changes to this value are not verified
2020-04-13 15:39:42.153 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:42.158 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:42.163 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:42.167 Detail, Node056, Notification: ValueChanged
2020-04-13 15:39:42.172 Detail, Node056, Notification: ValueChanged

Tout s’est bien passé pour le capteur de porte sécurisé (Node056) mais pas pour le Dimmer 2 non sécurisé (Node 092), la lumière ne s’est pas allumée

Les 2 lignes Detail en plus avec le mode Debug, on apprend que le message est supprimé, pourquoi ?

2020-04-13 15:39:41.734 Error, Node056, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-13 15:39:41.734 Detail, Node092, Removing current message
2020-04-13 15:39:41.736 Detail,   Received: 0x01, 0x04, 0x01, 0x13, 0x00, 0xe9
2020-04-13 15:39:41.736 Error, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack

Ici, on voit qu’un ordre non sécurisé au milieu une communication sécurisée ne passe pas.
Et pourtant le module non sécurisé est sur secteur avec une excellente portée contrairement au module de porte sécurisé qui est collé au cadre de porte métallique avec une portée limitée (Il n’est pas en direct du contrôleur alors qu’il est à 3m).

[Domatizer]

Maintenant, je croule sous les fichiers log en Debug

Je remarque que les erreurs de collisions arrivent essentiellement avec les capteurs de portes Fibaro Door Sensor 2 inclus en sécurisé, lorsqu’ils communiquent pour un changement d’état ou un réveil.

Erreur sur le Door Sensor 2 sécurisé (Node022) et puis le Dimmer 2 sécurisé ou pas (Node074) se fait virer (Le mode Debug fait apparaître la 3ème ligne)

2020-04-13 21:24:27.525 Info, Node022, Sending (Send) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x16, 0x0a, 0$
2020-04-13 21:24:27.525 Error, Node022, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-13 21:24:27.525 Detail, Node074, Removing current message

Ah, c’est vraiment de la malchance qu’un Fibaro Door Sensor 2 est en train de se réveiller (1 fois toutes les 6 heures) pile au moment où un Fibaro Dimmer 2 (sécurisé ou pas) veut allumer la lumière. Comme j’ai une vingtaine de Fibaro Door Sensor 2, la probabilité de malchance augmente.

Alors oui un Fibaro Door Sensor 2 fonctionne bien en sécurisé mais tout seul !

Je pense que j’ai assez perdu de temps (ça fait des mois) à essayer de comprendre l’incompréhensible, alors hop tous capteurs de porte vont aussi passer en non sécurisé…

[PHB_fr]

Et quand tu auras fini on aura une nouvelle version de openzwave et croisons les doigts ça règlera le problème

[Domatizer]

Je ne pouvais pas attendre une nouvelle version d’openzwave. Avant la domotique n’était pas exploitable. J’ai bien progressé sur ces dernières semaines. Maintenant, j’ai de droit à : « ça marche mieux tes trucs ». J’aurais peut-être fini avant la nouvelle version d’openzwave ou craqué pour une Home Center 3

[mich0111]

@Domatizer

ou craqué pour une Home Center 3

Pas le même prix !!!

[Domatizer]

@mich0111

Pas le même prix !!!

Ça fait 10 modules Z-Wave ! Et si ça marche dès les premières inclusions, que de temps gagné !
Et si je compare vraiment le temps passé à debugger (soit je suis mauvais, soit il y a un lézard ou plutôt un caméléon dans le plugin), ce n’est plus une question de prix, il aurait été plus rentable de l’acheter, mais elle n’existait pas il y à 3 mois.

[Domatizer]

Bonjour,

J’ai ré inclus en non sécurisé les principaux modules de portes Fibaro Door Sensor 2 avec lesquels j’observais des collisions. Et bien, je n’ai plus de collisions avec ces modules en non sécurisé. Soit je suis vraiment chanceux, soit il y a un petit souci de gestion des collisions avec certains modules en mode sécurisé. Maintenant, le Nombre de messages non remis au réseau et le Nombre de messages jetés ou non délivrés ont drastiquement diminué. Je pense que les messages non remis au réseau restants vont être résolu lorsque tout mon réseau sera en mode non sécurisé…

Pour les messages jetés ou non délivrés, ils sont principalement dus à la commande AlarmCmd_Get mal supportée, comme je l’avais remarqué dans mes premiers posts sur ce fil. Ces erreurs sont moins critiques, mais je pense qu’il y a vraiment moyen de gagner un temps énorme lors du démarrage du réseau. J’ai donc ouvert un autre sujet ici

Optimisation du temps de démarrage du réseau Z-Wave

Bonjour, A force d’analyser les erreurs dans les fichiers log d’openzwave pour debugger mon réseau, je me suis rendu compte qu’il existe certaines requêtes qui ne semblent pas ou mal être supportées et qui nous font perdre vraiment du temps lors du redémarrage 4 secondes à chaque fois ! Compter le nombre de modules que vous avez et faites le calcul ! Ces erreurs sont toutes dans la catégorie Nombre de messages jetés ou non délivrés : Exemple avec la commande AlarmCmd_Get qui est mal suppor…

[Domatizer]

@Domatizer

Je pense que les messages non remis au réseau restants vont être résolu lorsque tout mon réseau sera en mode non sécurisé…

C’est fait, j’ai pris mon courage à 2 mains pour tout ré inclure en non sécurisé. De plus, j’ai modifié les fichiers de config de certains modules pour enlever les classes inutiles lorsque les requêtes finissent en timeout et bloquent la queue de plusieurs secondes à chaque fois. Explication dans l’autre sujet Optimisation du temps de démarrage du réseau Z-Wave

Avant, j’avais environ 10% des messages qui partaient je ne sais où !
Maintenant, à la fin du redémarrage, je n’ai plus du tout d’erreur et ça fonce

[Mips]

Et le temps de démarrage réseau du coup ?

[PHB_fr]

Bon maintenant plus qu’à remettre en sécurisé avec les XML de corrigé courage ! On va tous nous sortir de l’impasse !!

[m4dm4rtig4n]

Bonjour a tous,

Pour information suite aux divers soucis que je rencontre avec mon Z-Wave et l’ampleur que mon post initial à prit (150 messages oO), je me suis décidé à migrer la totalité de celui-ci sur du MQTT.

Avantage :

• Lib OpenZWave 1.6
• Aucune dépendance entre votre réseau Z-Wave & Jeedom (jeedom ne sais même pas qu’il pilote du z-wave)
• Il est possible d’ajouter de la QoS afin de s’assurer que les commandes arrive bien (retry).
• Outils de debug intégrée dans zwave2mqtt.
• Compatibilité multi-box

Inconvénient :

• Il faut récrée manuellement toutes les commandes des modules & widget.
• Besoin d’un broker et des compétences qui vont avec (Mosquitto dans mon cas).
• Besoin de dompter zwave2mqtt
• Besoin de plus de ressource système

Bref, j’essaie de vous faire un retour pour vous dire si ceci résoud la totalité des problèmes

Je vous met quelques screens de l’install :

Configuration des actions d’un FGD-212 de Fibaro :

Et ses widgets qui vont avec :

[Bison]

Salut,

Et aucun paquets ne part en dehors de ton réseau ? C’est du MQTT local ?

Il « suffit » d’installer un package zwave2mqtt sur Debian ?

[m4dm4rtig4n]

Yep, t’installes un Mosquitto, la lib openzwaze que tu souhaites, et zwave2mqtt en parallèle de jeedom.

Et tt est en local, rien ne sort.

Un peu d’explication :

ZWave2MQTT : Une passerelle IoT OpenSource pour vos objets ZWave

Dans mon cas j’ai remplacer Node-Red par Jeedom.

[Domatizer]

@Mips

Et le temps de démarrage réseau du coup ?

64-82 secondes. cf l’autre post

@PHB_fr

Bon maintenant plus qu’à remettre en sécurisé

Dans tout mon réseau, j’ai laissé un seul module en sécurisé pour l’étude qui ne sert pas pour la domotique. Et bien, dans mes stats, depuis mon précédent post (pas de redémarrage entre temps) , je n’ai eu qu’un seul message non remis au réseau due à Error, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack qui vient de ce seul module sécurisé.

Alors NON, pas de sécurisé pour moi !

Maintemant, si je fait le ratio entre le nombre des messages jetés ou non délivrés ou non remis au réseau et le nombre de messages correctement envoyés ou reçus, il n’y a pas photo !

@m4dm4rtig4n

Pour information suite aux divers soucis que je rencontre avec mon Z-Wave et l’ampleur que mon post initial à prit (150 messages oO), je me suis décidé à migrer la totalité de celui-ci sur du MQTT.

Tu t’es lancé dans un sacré chantier !

@m4dm4rtig4n

Inconvénient :

• Il faut récrée manuellement toutes les commandes des modules & widget.
• Besoin d’un broker et des compétences qui vont avec (Mosquitto dans mon cas).
• Besoin de dompter zwave2mqtt
• Besoin de plus de ressource système

Trop de boulot !!!

[Mips]

Merci j’ai vu.
L’info qu’on a pas encore ici (sauf si je l’ai raté désolé) c’est est-ce que c’est le passage en mode non-sécurisé ou la suppression des class_command qui a eu le plus d’effet?

[mich0111]

@Domatizer

Alors NON, pas de sécurisé pour moi !

Salut,
Ce qui me fait plaisir, c’est que tu as réussi à démontrer ce que je subodorais depuis longtemps et pour lequel je me faisais tailler régulièrement.
J’ai arrêté l’inclusion sécurisée depuis longtemps et je n’ai plus jamais eu de problème.
J’avais d’ailleurs arrêté de me battre pour ça.
Donc, oui, peut-être que je recommencerais à tenter le coup après le portage de la bibliothèque 1.6 mais sûrement pas avant.
Bonne journée

[Domatizer]

@Mips

est-ce que c’est le passage en mode non-sécurisé ou la suppression des class_command qui a eu le plus d’effet?

En sécurisé, j’observais souvent des erreurs type ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack.

• Soit les modules sécurisés déconnaient tous seuls
• Soit les collisions avec des modules sécurisés étaient mal gérées et donc les communications des autres modules sécurisés ou pas ne passaient pas : voir plus haut l’exemple avec un Fibaro Dimmer 2 sécurisé ou pas qui n’arrivait pas à envoyer l’ordre d’allumer la lumière si au même instant un module de porte Fibaro Door Sensor 2 se mettait à échanger.

La suppression des COMMAND_CLASS a un impact sur les erreurs type ERROR: Dropping command, expected response not received after 1 attempt(s). Elles ne sont pas forcement critiques, mais comme expliqué dans l’autre post, il y a un blocage de la queue sortante de 4 secondes pour rien à chaque fois. En conséquence d’une queue bloquée jusqu’au timeout, je me demande si cela ne génère pas aussi des problèmes en plus de timeout pour les requêtes supportées mais qui n’auraient malheureusement pas eu le temps d’être traitées ? En effet, j’avais fait un essai de mettre le timeout à 1 seconde, et bien de nombreuses requêtes normalement supportées non juste plus le temps d’être traitées correctement et ça part en timeout.

Mais c’est bien le passage en mode non-sécurisé qui m’a permis d’avoir un réseau fonctionnel et non plus aléatoire (avec les collisions).

@mich0111

Ce qui me fait plaisir, c’est que tu as réussi à démontrer ce que je subodorais depuis longtemps et pour lequel je me faisais taillé régulièrement.

Je comprends

@mich0111

J’ai arrêté l’inclusion sécurisée depuis longtemps et je ai plus jamais eu de problème.
J’avais d’ailleurs arrêté de me battre pour ça.
Donc, oui, peut-être que je recommencerais à tenter le coup après le portage de la bibliothèque 1.6 mais sûrement pas avant.

Pareil

Conclusion : on n’est donc pas sur des problèmes matériels !

[m4dm4rtig4n]

Bon suite à mon précédent message et le passage en zwave2mqtt, voici mes 1er retours :

La lib openzwave 1.6 :

• Ce n’est pas tout beau tout rose comme je l’avais imaginer…
  J’ai eu divers soucis qui m’ont obliger à inclure/relinclure une dizaine de fois certain modules.
  Bon l’avantage, c’est qu’on une interface zwave qui est bcp plus clair que ce qu’on peut avoir sur jeedom et me permet de comprendre plus en détail certaine choses

• Pour un bien (d’après ce que j’ai lu sur gitlab), il est conseiller de ré-inclure la totalité des modules directement en openzwave 1.6.
  => Ce qui va certainement rebuter pas mal de monde surtout si tu as 150 modules…

• Je recontre actuellement un soucis avec les modules sur batterie qui n’arrivent pas à charger le « cache » de configuration au démarage de zwave2mqtt et sont donc inutilisable jusqu’au prochain « wakeup ».
  => J’ai une issue en cours chez OpenZWave.

• Quand tu fouille un peu les différentes issue sur Githab, tu vois régulièrement des gens dire de repasser en 1.4 qui est considérer comme plus stable…
  Et ce qui est un peu contradictoire c’est que ttes issues créer pour du openzwave 1.4 sont automatiquement cloturer, le dev ne bosse plus que sur la 1.6…
  Donc en gros si ta un bug en 1.4, passe en 1.6 sinon tu n’aura pas de support.
  Si ta un bug en 1.6, repasse en 1.4 mais sans support/évolution.
  =>

MQTT ?

• ca marche du feux de dieux et j’ai 0 latence.
  J’ai eu quelques soucis de latence au début, mais c’était à cause des « Dropping command » qui lorsqu’elle ce produise génère une latence de quelques secondes juste avant de pop.

Et j’ai retrouver tt mes bébés zwave :

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

• Ce n’est qu’un au revoir !

• Alors j’ai rencontrer principalement ce soucis avec certain module récalcitrants qui avait du mal à s’inclure…
  Ma procédure pour les dégager à était de faire un hard reset des modules en questions et de les ré-inclure derrière jusqu’à tant de ne plus en avoir du tout…
  => Très long et fastidieux surtout chez Qubino qui demande une coupure électrique et de relié à la phase 5x de suite une sortie le tout sous 220v…
  Surtout qu’il y a un bouton sur le module mais que ne fonctionnement uniquement que sur de la basse tension 24v…

• Merci le « Replace failed node », qui m’a évité d’être à l’ID 150 et qui permet de remplacer le module défaillant sans en perdre l’id.

Création des modules sur jMQTT

• Alors soit je suis passer à coté d’un truc, soit ça manque clairement de doc…
  Il y a certain modules où la création à était très simple, et d’autre comme les volets où j’ai mit 2j à trouver la commande pour envoyer le « Stop ».

• Je me suis beaucoup aider du plugin zwave pour retrouver les commandes qui vont bien

Bref prochaine étape Enocean2MQTT

[Domatizer]

Merci @m4dm4rtig4n pour ce retour

@m4dm4rtig4n

La lib openzwave 1.6 :

• Ce n’est pas tout beau tout rose comme je l’avais imaginer…
  J’ai eu divers soucis qui m’ont obliger à inclure/relinclure une dizaine de fois certain modules.

Et bien, je ne vais pas me presser pour le changement

@m4dm4rtig4n

Pour un bien (d’après ce que j’ai lu sur gitlab), il est conseiller de ré-inclure la totalité des modules directement en openzwave 1.6.
=> Ce qui va certainement rebuter pas mal de monde surtout si tu as 150 modules…

C’est un des points noir du Z-Wave ces exclusions/inclusions, c’est vraiment chronophage.
La mise en place d’une installation filaire prendrait moins temps…

@m4dm4rtig4n

Et ce qui est un peu contradictoire c’est que ttes issues créer pour du openzwave 1.4 sont automatiquement cloturer, le dev ne bosse plus que sur la 1.6…
Donc en gros si ta un bug en 1.4, passe en 1.6 sinon tu n’aura pas de support.

Je voudrais désactiver certaines requêtes qui génère des timeout et donc Dropping command.
En 1.4, pas de support

@m4dm4rtig4n

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

• Ce n’est qu’un au revoir !

Ouais, c’est bien ce que pense, que des emmerdes de soft !

[Domatizer]

Remarque : j’ai transféré mon Jeedom sur un ancien PC portable. Bon, pas de chance, il est moins puissant que le RPi3 et il a toujours une charge de 2 à 3 fois le max sauf la nuit où il est juste limite : il souffre en continu le pauvre, en attendant une nouvelle machine.
Et bien, le Z-Wave n’a pas plus de problème de Dropping command, etc.
J’ai tous mes modules avec un %OK à 100% excepté pour les modules Flirs (>98%)
Donc, les pertes Z-Wave ne sont pas dues au manque de puissance de la machine !