Soucis sur mon réseau z-wave

Bison · Mars 15, 2020, 5:16

J’ai également des commandes qui parfois ne passent pas alors que j’ai des modules alimentés en permanence et disposé assez régulièrement sur les étages. Je n’ai jamais pu remarquer que c’était telle zone où tel module qui posait plus régulièrement problème.

Citation
A Message sent to 15 was dropped as the Controller rejected it. Please report to Developers

Il me paraît difficile que ce soit un problème lié au code car s’il « encodait » mal le message que le contrôleur doit envoyer j’ai le sentiment que ce serait un bug permanent et donc reproductible.
Dans nos cas c’est à vue de nez un ordre sur 20 qui passe pas. Après tout ce sont peut être les contrôleurs qui ne sont pas du grande fiabilité et qui de temps en temps n’accepte pas les ordres ?

Ou bien le passage par la virtualisation puisque ça rajoute une couche ?

Domatizer · Mars 15, 2020, 5:27

En détails, l’explication de l’erreur 4 http://openzwave.com/knowledge-base/senderror
Le message est rejeté par le contrôleur avant même qu’il ne soit envoyé, il ne l’envoi pas, c’est bien le problème.

Jeedom n’est pas virtualisé, il est installé sur un RPi

Quelles sont les alternatives ? Quel est le contrôleur le plus fiable ? Après avoir investi x000 € dans des modules Z-Wave, il faut trouver une solution afin que le réseau fonctionne…

PHB_fr · Mars 15, 2020, 6:00

Merci merci +10000 @Domatizer !!! Quel travail de fou pourquoi personne n’a communiqué ce truc d’analyseur et pourquoi il n’est pas inclus dans jeedom quand je disais qu’il y a un probleme et sur l’on avait aucun moyen d’analyse preuve que ce qui est présent dans jeedom « ne sert pas a grand chose »

Conclusion problème avec le développeur / développement ? Reste a voir si c’est côté core ou plugins …

Bison · Mars 15, 2020, 7:41

J’avais bien compris que le message n’était pas envoyé par le contrôleur car rejeté.

Si tu as un RPi alors c’est que les problèmes ne viennent pas des systèmes de virtualisation qui ajoutent une couche à la liaison USB vers le contrôleur.

J’ai été voir sur le site openzwave pour en voir un peu plus et j’y vois personnellement plus clair.

La liste des devices compatible est indiquée, elle est impressionnante et il y a énormément de stick indiqué.

Maintenant je n’avais pas compris la remarque concernant le fait de rapporter le problème au développeurs. Il s’agit de rapporter le problème aux développeurs de OpenZwave. Partant de là comme je présume que Jeedom utilise la librairie OpenZwave (le plugin) sans modification il y a beaucoup de chance pour que le problème ne soit pas en relation avec Jeedom et son code.

Il est donc fort possible qu’il existe un problème dans le code de OpenZwave et que ce soit à cause de cela que parfois l’instruction rentre en violation du protocole lorsqu’il est demandé au contrôleur zwave d’envoyer un message.

Ce que je n’avais pas fais attention c’est qu’il existe une version 1.6 datant de fin décembre 2019 alors que Jeedom utilise une version 1.4 datant de 2016.

Il me semble clairement possible qu’entre la 1.4 et la 1.6 un certain nombre de bug de communication avec différents matériels est pu être corrigés et qu’en conséquence le passage en 1.6 puisse être en mesure de régler nos problèmes. Est-ce possible ?

Domatizer · Mars 15, 2020, 8:53

De plus, les utilisateurs de Home Assistant / OpenHab qui utlisent aussi OopenZWav ont des problèmes du même genre. Donc, il y a des imperfections dans les librairies OpenZWave.

Je suis d’accord avec toi, le reverse engineering a ses limites, rien ne vaut le SDK officiel. Maintenant qu’il est passé dans le domaine publique, la situation devrait s’améliorer. C’est une question de temps. Pour l’instant, les modules Z-Wave semblent plus avancés en terme de fonctionnalités, ce qui leur donne encore l’avantage. Mais quand je vois le prix des prix des prises Wi-Fi, le choix pour de nombreuses personnes va être vite fait. Si on compare la fiabilité et la simplicité de la mise en œuvre d’un réseau Wi-Fi (ou Bluetooth), il n’y a pas photo. Le Wi-Fi sort vainqueur et pas besoin de contrôleur, tout le monde a une box internet.

La version 1.6 apporte plus de fonctionnalités pour certains modules et doit certainement corriger des défauts. Tant qu’on restera avec cette version 1.4, on va galérer. Actuellement, ce sont les fonctions de base qui posent souci, actionner une lumière, récupérer l’état d’un détecteur de mouvement. Pour gérer les scènes avancées, les alarmes générale, inondation, feu, CO, etc, en dehors de Fibaro, il ne doit pas y avoir grand monde pour gérer toutes ces subtilités.

Domatizer · Mars 25, 2020, 12:01

J’ai beaucoup lu et vu cette remarque à plusieurs reprises. J’ai donc craqué et fini par ré-inclure en mode non-sécurisé tous les détecteurs de mouvements Fibaro Motion Sensor. Là, c’est le jour et la nuit. Avant, je recevais des alertes tous les jours de plusieurs capteurs qui restaient bloqués à 1 ou à 0. Mouvement continu pendant 30min sachant que la durée de maintient est fixée à 30s après le dernier passage, il faudrait soit faire du sport ou un déménagement dans la pièce pour avoir une alerte.

Depuis le passage en non sécurisé des 12 détecteurs de mouvement, je n’ai pas eu un seul raté !

Pourquoi n’est-il pas dit officiellement que certains modules ne fonctionnement pas correctement en mode sécurisé avec OpenZWave tout simplement ?

Quand je vois la promotion du mode sécurisé sur certains blogs, je me pose des questions. Ils font comment ces gens ? Juste un réseau avec 2 modules le temps de faire un article !

Je suis prêt à accepter que tout ne soit pas au point mais qu’on me dise clairement ce qui fonctionne bien et ce qui est toujours expérimental : exemple, tel module fonctionne en sécurisé s’il est seul mais ne fonctionne pas bien en présence de tel autre module inclus de tel manière.

Statistiquement, le nombre d’erreur de ce type diminue.
Error, NodeXXX, ERROR: Dropping command, expected response not received after 1 attempt(s)
Mais ces erreurs sont toujours présentes même pour les nouveaux nœuds non sécurisés.
Toujours le souci avec AlarmCmd_Get comme décrit précédememnt

Encore une question, j’ai souvent des erreurs javascript qui reviennent régulièrement.

Est-ce grave ? À quoi est-ce dû ?

mortyre · Mars 25, 2020, 10:11

Le mode sécurisé en effet fonctionne uniquement si l’on a quelques capteurs. Sur pile si l’on met des capteurs en sécurisé le réseau ne fonctionne plus correctement. Pourquoi exactement je n’ai pas la réponse mais en tout cas c’est le cas. Donc oui il ne faut pas utiliser la sécurité S0 alors qu’on nous vends cela comme étant utilisable, la réalité est toute autre.

Bonne question il faudrait demander à l’équipe qui gère cela mais tu dois bien comprendre pourquoi il ne communique pas sur le sujet clairement.

De toute manière tant que Jeedom n’aura pas un plugin Zwave basé sur le SDK officiel de Silicon Labs cela ne pourra pas fonctionner correctement. On aura pas de S0 et encore moins de S2, Smart Start, …

Pour ton erreur Javascript fait un ticket j’en ai aucune idée.

Mips · Mars 25, 2020, 10:26

Hello,

Juste pour mitiger un peu cette pseudo « règle »

J’ai une cinquantaine de modules zwave, inclus en sécurisé pour ceux qui le supportent (sans défendre ou prétendre que cela était nécessaire) et mon réseau est globalement stable, tout fonctionne « normalement »…
Donc je ne sais pas d’où tu tires cette règle mais cela ressemble à de la spéculation

mortyre · Mars 25, 2020, 10:32

Heureux de l’entendre que cela fonctionne pour toi et tu as raison rien n’est écrit dans le marbre. Mais pour autant ce qui fonctionne pour une personne n’est pas le cas d’usage obligatoire pour les autres.

Par retour d’expériences de plusieurs utilisateurs ayant des problèmes sur leur réseaux zwave, cela vient souvent des modules inclus en mode sécurisé quand ils sont sur piles (détecteurs d’ouvertures, …) et de leurs ratios piles / courant. Apres il y a aussi les distances, les murs, le nombre de saut, …

En ce qui te concerne Mips, peux tu donner plus de détail sur ta configuration elle pourra peut etre d’y voir plus clair ? Tous tes modules sécurisés sont ils sur piles (sinon ratio piles/courant en mode sécurisé) ? quel est ton ratio pile sur courant au global ? Qu’utilise tu comme serveur hardware (puissance de calcul) ? Combien de saut as tu dans ton réseau ?

Phil56 · Mars 25, 2020, 10:49

Bonjour,

une chose est certaine ce n’est pas le coté sécurisé qui est la cause des problèmes. Je n’ai aucun module en mode sécurisé et je ne peux pas dire que j’ai un réseau stable (fiable).
Je pense de plus en plus à un problème de performance. C’est à dire que dans certaines circonstances, si les performances (host) ne sont pas au top le système (réseau, drivers plugin, clef ?? ) part au tas.

Si par exemple il y a « beaucoup » de module en mode sécurisé la charge doit être plus importante quelque part et cela induit des délais qui à un moment ou l’autre conduis au « crash » du plugin.

Chez moi par exemple, je surveille depuis plusieurs semaines le nombre de message en attente dans la file d’attente et je n’arrive pas à expliquer pourquoi à certains moments elle augmente. J’ai mis en place quelques contres mesures pour éviter d’arriver à un crash. Par exemple pour certains modules, j’ai désactivé la mise à jour auto des états et je le fais « manuellement » par scénario. La première chose faites dans ces scénarios est de vérifier l’état de la file et si elle n’est pas vide reporter la demande de mise à jour.

Je touche du bois, mais depuis que j’ai généralisé cela je n’ai plus de crash, je vois la file monter au maximum à 10 messages puis aussitôt revenir à 0.

ken@vo
Phil

Mips · Mars 25, 2020, 10:58

On est bien d’accord, cela « semble » (à prendre vraiment avec de pincettes ce genre de supposition) lié.
Et beaucoup de personne ont un problème sur leur installation et comme toujours, beaucoup plus n’en ont pas et ne viennent pas l’écrire ; bref tout cela ne sert pas beaucoup car on n’a juste pas la vue complète et c’est impossible de tirer des conclusions.

Concernant mon install, j’ai pris l’habitude de toute inclure en mode sécurisé, sans trop savoir pourquoi au départ, on se dit forcément que c’est mieux
J’ai très peu de route avec plus qu’un saut mais j’en ai.
Les modules sont réparti sur 3 niveaux d’en moyenne une centaine de m² chacun (moins pour le 3eme, c’est le grenier)
Béton entre le rez et le 1er et plancher avec le grenier (2 prises connectées s’y trouvent)
la plupart des murs sont très épais au rez (>40cm, ancienne construction rénovée)

j’ai beaucoup de micro-modules (fibaro, est-ce qu’il y aurait différente qualité dans les marques?) dans les interrupteurs, quasi chaque pièce, cela doit aider pour le maillage.
et quelques prises connectés réparties un peu partout dans la maison.

Parmi les modules sur piles (une petite vingtaine au total), je n’ai que deux détecteurs de porte qui ne sont pas en sécurisé (ils ne le supportaient pas); sinon y a des oeils fibaro, des détecteurs philio et des têtes de vannes thermostatiques eurotronnic (tout cela en « sécurisé »)
Donc 8 « détecteurs », 7 vannes et le reste de types interrupteurs/télécommandes

Je tournait sur une smart a début, une vm proxmox sur un nuc maintenant et effectivement j’ai eu des soucis de maillage, d’ordre qui ne passait pas au début (j’avais les remarques de la famille qui « ca ne marchait pas »), j’ai eu plusieurs fois le problème de queue qui augmentait, le démon qui ne répondait plus avec l’erreur sur le buffer (je ne me rappelle plus très bien)

Depuis que je suis sur nuc plus aucun soucis majeur, mais je ne peux pas être sur que cela soit la seule raison…
Cela arrive encore parfois qu’une lampe ne s’allume pas ou que le retour d’état ne se fasse pas (jeedom voit toujours la lampe comme allumée alors qu’elle est éteinte), genre 1 cas toutes les 2 semaines.

Si j’avais le courage (et le temps), je pense que ré-inclurait le tout en non-sécurisé pour tester si cela règlerait les derniers cas mais vu la surface à couvrir et le placement des modules je devrait monter un jeedom temporaire sur un pi que je peux déplacer pour faire les inclusions sans tout débrancher et cela sans être sur que le « sécurisé » soit la cause de ces drops

mortyre · Mars 25, 2020, 11:49

Merci pour ton retour.

Tu as mis le doigt sur plusieurs choses essentielles à mon avis sur un réseau Zwave sous jeedom et pour résumer voici mon avis :

la puissance de calcul nécessaire au décryptage et l’encodage du mode sécurisé est importante. J’ai pu constater que la puissance joue un rôle et notamment au passage à l’odroid C2 qui a aidé avec le surplus de puissance. Pourtant je n’étais pas sur de cela au départ ne sachant pas ou ce faisait l’encodage et le décodage, c’est une déduction pas une démonstration
le type de module en mode sécurisé : les détecteurs sur piles sont les pires il y a qu’à voir la difficulté à finir un interview lors de l’inclusion en sécurisé. A partir d’un certains nombres ils te ralentissent fortement les réseaux jusqu’à le bloquer. Dans ton cas Mips il semble que tu en est très peux par rapport au nombres total de modules wave et notamment ceux sur courant. Quand aux têtes thermostatiques elles sont en modes FLIPRS et ne sont pas comme des détecteurs sur pile (présence ou ouverture), elles influencent moins les problèmes
il faut un bon maillage sur courant c’est la base de toute installation sur Zwave, et aussi respecter un certain ratios piles / courant
faire bien ses routes, il faut pendant les deux premières semaines faire des réparations des routes pour les optimiser jusqu’à obtenir un bon maillage
la marque ne joue en rien

Quand à la taille du nombre de module, elle peut être grande (sans problème avec une centaine de module) si l’on respecte les règles précédentes.

Et si vous avez du temps (merci le confinement) je vous conseil en effet pour ceux qui ont des problèmes de passer les modules sur piles en priorité en mode non sécurisé, ça permettra à votre réseau d’allez beaucoup plus vite et d’éliminer un certains nombres d’erreurs.

Mips pour le dernier cas que tu cites avec la lampe qui ne remonte pas le bon état, il faudrait regarder dans ce cas là les logs précis, et voir si a ce moment là il y eu une erreur de communication et voir si cela se produit sur les mêmes modules, et donc ensuite regarder leur route.

Mips · Mars 25, 2020, 11:57

J’ai compléter mon poste avec le ratio pile/secteur: 17/18 modules sur piles

Mips · Mars 25, 2020, 12:04

Je n’ai pas précisé mais c’est effectivement toujours les mêmes 2, 3 modules (surtout 1 dans le garage) qui ont ce problème et effectivement ils se trouvent chacun respectivement à une « extrémité » du bâtiment.

et donc oui, j’essaierai de regarder plus en détails, mais de nouveau, vu que c’est la lampe du garage qui reste soit disant « allumée » une fois toutes les deux semaines, c’est pas urgent pour moi.

Domatizer · Mars 25, 2020, 3:42

Merci beaucoup @mortyre

Eh bien, rien n’empêche ce soit pire en mode sécurisé.

Oui, certainement, mais beaucoup ne sont pas forcément exigeant et/ou ont des petites installations ou utilise la domotique en mode télécommande, c’est-a-dire avec peu de scenarii (l’ordre n’est pas passé, hop je rappuis sur le bouton comme avec une télécommande pour TV). Lorsqu’il y a peu d’automatisme, il y a peu de conséquences derrière en cas, donc beaucoup ne voient pas les soucis. Je suis convaincu qu’ils en ont mais qu’ils ne s’en rendent pas compte, tout dépend des conséquences au niveau des actions. Un exemple bien vicieux ici Door/Window Sensor 2 se ferme tout seul lors du 1er réveil où je parie que tout le monde (enfin pas seulement moi) est confronté au problème, mais en fonction de l’utilisation du module, il y a des conséquences graves ou rien du tout et beaucoup diront : « moi, je n’ai pas de souci ».

Je me considère comme utilisateur exigeant, j’ai choisi Jeedom pour avoir le moins de limite possible. J’ai décidé de tout faire en automatique, donc beaucoup de modules avec surtout beaucoup de scenarii dernière, je m’attends a rencontrer des limites. Pour certaines, je peux y remédier, pour d’autres comme la galère du Z-wave, je me sens vraiment démuni.

La Smart est pourtant officielle avec le Z-Wave intégré. Tu n’aurait pas dû avoir de souci comparé à tout ceux (moi avec) qui bricolent avec un RPi ou autre.
Il y a bien la Jeedom Pro, mais elle n’existe pas pour les particuliers. Et pas certains que nos problèmes soient résolus.

C’est problématique car c’est très chronophage ces exclusions/inclusions.
Existe-il une solution pour désactiver les modules temporairement lors d’un debug ?
Exemple, pour tester un réseau avec seulement quelques modules sans exclure puis ré inclure tous les autres. Ça permettrait de voir ce qui et ce qui va pas.

mortyre · Mars 25, 2020, 4:13

La SMART et la JEEDOM PRO partage le même hardware carte mère ODROID C2, seul la taille de la emmc change (8 vs 16go). Je confirme que l’on peut avoir une 100 de modules avec ce type de carte

Les routes resteront et ce n’est pas la solution. Il faut regarder si un module ne crée pas une instabilité ou flood le réseau

Domatizer · Mars 25, 2020, 4:31

Je vois.

Un module qui flood le réseau, ça peut se voir dans le log. Et dans les statistiques, on peut voir les infos suivantes

Nombre de messages d'échec dus au réseau occupé :
Nombre de messages reçus avec statut de routage occupé :

Si le réseau est vraiment saturé, il devrait y avoir des messages pour ces 2 catégories, ce n’est pas le cas.
De façon générale, il faut se méfier des modules qui remontent un peu trop souvent leur puissance. Pour mieux voir, il faudrait un script qui compte le nombre de lignes de log pour chaque module pour en extraire un pourcentage de communication.

Mais, je pense que le problème est ailleurs et que ce n’est pas la saturation du réseau.

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.