Stabilité du zwave: c'était mieux avant ! (maj 2019-04-10 15:50:21)

[anto35]

Pour info, ces latences sont connues :

https://nechry-automation.ch/2018/01/17/securite-zwave/

Tu peux lire cet article si tu veux c'est assez intéréssant.

[romanais]

http://tutoriels.domotique-store.fr/con ... domus.html

En cliquant sur la petite flèche se trouvant à droite du bouton "Inclure un périphérique Z-Wave (non sécurisé)", il est possible de demander une inclusion en mode sécurisé, c'est-à-dire avec activation du cryptage des communications. Ce type d'inclusion ne doit être utilisé que pour des modules supportant l'inclusion sécurisée et dont l'usage est sensible en terme de sécurité. Le mieux étant l'ennemi du bien, le mode sécurisé peut poser des problèmes avec certains modules ainsi que des communications plus lente. À n'utiliser que si nécessaire, donc.

http://sarakha63-domotique.fr/z-wave-part1/

Alors que se passe-t-il lorsqu’un module est inclus en sécurisé :
Il échange avec la centrale domotique une clé de cryptage
Chaque trame échangée ensuite, le sera après avoir été crypté avec cette clé
Il y a cependant quelques points négatifs:
Il y aura une latence plus grande (oui il faut que les trames soient décryptées à chaque interaction)
Vous aurez deux sous réseaux de maillages.
Ce dernier point est important. En effet, un module qui parle en sécurisé ne pourra pas faire partie du maillage réseau non sécurisé et vice-versa :

[akenad]

Z-Wave+ S0 :
- Un noeud sécurisé est capable de router des paquets non sécurisés
- Un noeud non sécurisé est capable de router des paquets sécurisés

Z-Wave sécurisé Partie 1

Z-Wave sécurisé Partie 2

akenad

[dJuL]

Merci pour vos liens fort intéressants.

Mais rien de bien explicite non plus concernant mon problème.

Je me doute bien que le cryptage peut ajouter un poil de latence (et encore je peux prouver que ce n'est pas ou à peine perceptible côté module).
Mais là on parle du contrôleur qui déraille totalement et qui n'arrive plus à communiquer correctement avec les modules.

Ma conclusion est simple, au-delà de 3 commandes émises en simultané par le contrôleur sur des modules sécurisés, on a une latence aléatoire (pouvant aller parfois jusqu'à 5s si il y a pas mal de commandes envoyées), on a des commandes qui ne sont parfois pas envoyées et des retours d'état qui ne sont parfois pas reçus correctement et parfois tout un tas d'erreur dans les log openzwave.

Le problème vient donc de la clef z-wave ou d'open zwave (ou de jeedom mais cela m'étonnerai fort).
Avec une seule commande on n'a pas de latence et aucune erreur. c'est à partir de 3 ou 4 commandes que ça commence à chier.

Car oui j'ai testé les associations direct entre modules sécurisés, et là il n'y a aucun lag et aucune latence !
Cela prouve que côté module et côté réseau le cryptage ne ralenti pas (dans la réalité évidemment que si, probablement quelques ms, mais ce n'est pas perceptible).
Ce qui est logique, on est 2019, ça fait longtemps qu'on sait faire du cryptage en hard.
Longtemps que la puissance des chips permet de gérer du cryptage sans que ça lag.

De toutes façons la latence que j'avais était aléatoire, cela prouvait bien que cela était due au contrôleur qui déraille et non au protocole.
Vu la fréquence et le débit du réseau zwave, on ne va pas me faire croire que le cryptage peut créer un lag de plusieurs secondes.
Quand j'ai passé mes sites web en SSL, je n'ai pas changé de serveur, et les clients n'ont pas senti de ralentissements.
Sur certains outils il sont nombreux, beaucoup plus que mes pauvres 25 modules inclus en mode sécurisé.

Bref, je suis convaincu que ce n'est pas le CPU de la smart qui est trop light, pas le réseau maillé sans fil qui est trop lent, mais juste que soit la clef hardware, soit openzwave, soit les 2, ne sont pas capables de gérer le sécurisé correctement, notamment sur de l’exécution de commande en simultané sur plusieurs modules.

[anto35]

Le contrôleur n'arrive plus à gérer car il y a trop de communications sur le réseau et que les communications de tous tes périphériques sont chiffrées.

Pour les associations directes, c'est normal, elles n'impliquent que les noeuds concernés, qui eux sont beaucoup moins chargés que le contrôleur. Quand tu testes une association directe, tu testes juste les deux modules, pas le contrôleur ni le réseau.

Pour info le Zwave ce n'est que 40kbits/s. Comme le protocole est sécurisé (ack, rejeu), tu peux très facilement écrouler un réseau assez important si un ou plusieurs noeuds se mettent à flooder le réseau.

Pour moi, vu ton souci, je pencherais plutôt vers un ou des modules un peu verbeux. Tu as peut être réglé le souci en remettant les paramètres par défaut de tes modules.

[akenad]

Le plugin Z-Wave (jeedom/plugin-openzwave) fonctionnait plutôt bien depuis sa version du 17-03-2018.
Depuis sa version du 04-02-2019 (avec recompilation) j’ai constaté des anomalies de fonctionnement.
La branche master de openzwave a basculée en 1.6 le 3 mai 2019, mais le plugin Z-Wave utilise toujours actuellement un fork de openzwave 1.4.

akenad

[Jeandhom]

Je vais faire toute la maison et garder que les capteurs d'ouverture en sécurisés (car eux remontent juste l'info et ça semble marcher) et je préfère pour les utiliser dans ma future alarme les avoir en sécurisé.

Il me semble que la clé de cryptage est mise en dur dans le code du plugin.
Donc, sauf si tu l'a toi même changée, le mode sécurisé n'est pas si sécurisé que ça.

[dJuL]

Le contrôleur n'arrive plus à gérer car il y a trop de communications sur le réseau et que les communications de tous tes périphériques sont chiffrées.

Pour les associations directes, c'est normal, elles n'impliquent que les noeuds concernés, qui eux sont beaucoup moins chargés que le contrôleur. Quand tu testes une association directe, tu testes juste les deux modules, pas le contrôleur ni le réseau.

Pour info le Zwave ce n'est que 40kbits/s. Comme le protocole est sécurisé (ack, rejeu), tu peux très facilement écrouler un réseau assez important si un ou plusieurs noeuds se mettent à flooder le réseau.

Pour moi, vu ton souci, je pencherais plutôt vers un ou des modules un peu verbeux. Tu as peut être réglé le souci en remettant les paramètres par défaut de tes modules.

J'ai remis tous les paramètres exactement tels qu'ils étaient.
Comme j'ai tout au moins en double j'ai utilisé un module en tampon pour pouvoir lui copier les paramètres et ensuite les récupérer.
(car toutes mes lampes ont des seuils min et max réglée à la main, et des paramètres spécifiques, les relais des temps d'activation, des type de switchs connectés...)
De toutes façons j'ai quasi que des lumières et tout ce qui est sur pile est optimisé à mort pour communiquer le moins possible.
Donc ça écarte la thèse du module qui flood (sachant en plus que je ne rien re-inclus de tout ce qui est sur pile).

j'ai testé des assos directs avec 6 associations sur un switch, pas juste 1, ce qui revient bien à utiliser le réseau maillé, même si c'est moins de données que ce que brasse le contrôleur on est bien d'accord.
Et si avec 20 modules en sécurisé on arrive a saturer le réseau, c'est que le protocole est pourri...
C'est vrai que 5ko/s c'est pas folichon, mais au parle juste d'une vingtaine de module lampe.

Par contre j'ai peut être une thèse : c'est que quand le contrôleur déraille, il auto flood le réseau lui même, n'arrivant plus à lire les réponses il en redemande, revois des tentatives etc... Et le réseau se retrouve floodé.

Bref, l’essentiel c'est que pour l'instant tout remarche et c'est bien la sortie du mode sécurisé d'une vingtaine de modules lumière qui a réglé le problème.

Le plugin Z-Wave (jeedom/plugin-openzwave) fonctionnait plutôt bien depuis sa version du 17-03-2018.
Depuis sa version du 04-02-2019 (avec recompilation) j’ai constaté des anomalies de fonctionnement.
La branche master de openzwave a basculée en 1.6 le 3 mai 2019, mais le plugin Z-Wave utilise toujours actuellement un fork de openzwave 1.4.

akenad

Je n'ai jamais testé avant le sécurisé avec l’ancienne version, mon installe étant neuve.
Peut être que ça marchait mieux effectivement.

Il me semble que la clé de cryptage est mise en dur dans le plugin.
Donc, sauf si tu l'a toi même changée, le mode sécurisé n'est pas si sécurisé que ça.

Merci, oui oui j'avais vu ça sur le forum

[romanais]

J'avais lu sur le Telegram de Sarakha que le mode sécurisé générait 4x plus de trames.
Et que c'était clairement inutile pour des lampes par exemple (et je suis bien d'accord).

On va me dire : oui mais le "mode sécurisé c'est prévu par Z-wave, ça doit marcher", certes, mais clairement ce n'est pas le cas, à chaque fois que j'ai croisé des cas de lenteurs exaspérantes, c'était dû à ça.

Et sécurisé ou pas, si un gars veut se faire votre maison à tout prix, ce n'est pas ça qui le bloquera.

[romanais]

Sarakha avait posté ça sur Telegram (si ça pose souci je supprime bien sûr).

Pour que vous compreniez

Mode non sécurisé :
On demande un off le contrôleur envoie un off le module reçoit un off il renvoie son état

Mode « sécurisé «
On demande un off le contrôleur dit au module qu’il veut lui parler , le module reçoit la demande répond un tiens une clé parle moi, le contrôleur reçoit une clé , il envoie un off en utilisant cette clé , le module reçoit un off le « décrypte » et fait le off . Puis il envoie au contrôleur un je veux te parler. Le contrôleur reçoit la demande. Le contrôleur envoie une clé . Le module reçoit une clé . Le module envoie son status final. Le contrôleur reçoit. Le contrôleur « décrypte »
Et j’ai pas mis les accusé réception dans les schémas (il faut les rajouter)
Et à ça je rajoute qu’en zwave « c’est le protocole qui veut ça » si on a envoyé kkch et qu’on a pas d’accusé réception on ne fait rien d’autres (tout le reste est mis en attente) jusqu’à un timeout. Et ça que ce soit le module les contrôleurs etccc tout doit faire ça . Vous comprenez mieux pourquoi je dis *4 / saturation / etccc

[Jeandhom]

Et sécurisé ou pas, si un gars veut se faire votre maison à tout prix, ce n'est pas ça qui le bloquera.

C'est sûr, mais si tu lui donnes les clefs ...

[mortyre]

Malheureusement avec la version du plugin OpenZwave de Jeedom il faut utiliser le moins possible le mode sécurisé. Dès qu'il y en a plusieurs ça bugs rapidement, la queue zwave se remplie et ne fait que s'amplifier sans se vider. Il est clair que le mode sécurisé S0 sur Jeedom n'est pas exploitable correctement.

Et c'est dommage que le plugin ne permette pas de changer la clé dans la configuration. Bref, on est loin d'un réseau crypté sécurisé.

[BLRPERES]

Est-ce que du coup on est pas en train de ce dire qu’il y a une préconisation sur le nombre de modules maximum par contrôleur ?

Et si c’est le cas quel serait le chiffre clé ? 50? 60? 3000?


Envoyé de mon iPhone en utilisant Tapatalk

[Jeandhom]

Je crois que la limite est de 232 modules au niveau du protocole zwave par contrôleur.

[dJuL]

Sarakha avait posté ça sur Telegram (si ça pose souci je supprime bien sûr).

Pour que vous compreniez

Mode non sécurisé :
On demande un off le contrôleur envoie un off le module reçoit un off il renvoie son état

Mode « sécurisé «
On demande un off le contrôleur dit au module qu’il veut lui parler , le module reçoit la demande répond un tiens une clé parle moi, le contrôleur reçoit une clé , il envoie un off en utilisant cette clé , le module reçoit un off le « décrypte » et fait le off . Puis il envoie au contrôleur un je veux te parler. Le contrôleur reçoit la demande. Le contrôleur envoie une clé . Le module reçoit une clé . Le module envoie son status final. Le contrôleur reçoit. Le contrôleur « décrypte »
Et j’ai pas mis les accusé réception dans les schémas (il faut les rajouter)
Et à ça je rajoute qu’en zwave « c’est le protocole qui veut ça » si on a envoyé kkch et qu’on a pas d’accusé réception on ne fait rien d’autres (tout le reste est mis en attente) jusqu’à un timeout. Et ça que ce soit le module les contrôleurs etccc tout doit faire ça . Vous comprenez mieux pourquoi je dis *4 / saturation / etccc

Merci, la fin explique bien les grosses lenteurs parfois.
Quand le contrôleur par en cacahuète et rate la réponse du module (probablement car trop de modules répondent en même temps lors de commandes simultanées), il attend, et du coup ça lag...

Ça expliquerait peut être aussi le symptôme du ON/OFF très rapide que j'ai pu constater parfois, ou des retours incomplets si la communication n'a été que partielle entre le module et le contrôleur.

Perso je me moque que mes lampes soient en sécurisé ou non effectivement, juste j'ai vu des blogs et des posts ici qui recommandaient ce mode, et comme tout est neuf et que tout le supporte sur le papier, j'ai pas réfléchi plus que ça...
Mais il n'y a pas beaucoup de lecture disant de ne pas utiliser le mode sécurisé car cela ne marche pas, et tous les modules récents se vantent de supporter ce mode...
Maintenant je sais

[dJuL]

Malheureusement avec la version du plugin OpenZwave de Jeedom il faut utiliser le moins possible le mode sécurisé. Dès qu'il y en a plusieurs ça bugs rapidement, la queue zwave se remplie et ne fait que s'amplifier sans se vider. Il est clair que le mode sécurisé S0 sur Jeedom n'est pas exploitable correctement.

Et c'est dommage que le plugin ne permette pas de changer la clé dans la configuration. Bref, on est loin d'un réseau crypté sécurisé.

Tout à fait.
Et la question en suspend reste est-ce que ça vient de jeedom, d'openzwave, de la clef zwave ou des 2 ou des 3.
Ou bien c'est carrément le protocole zwave qui est naze en sécurisé.

Pour le savoir il faudrait faire le test avec une autre box (genre fibaro qui n'utilise pas openzwave) avec pas mal de modules en sécurisés pour voir si ça marche ou pas.

[mortyre]

je pense que c'est du au plugin OpenZwave qui gère mal ceci mais ce n'est que mon avis personnel... il faudra voir si le plugin sera mis à jour en 1.6 et s'il corrige ce point là mais je ne pense pas. Tant qu'on sera sur un Fork on aura des problèmes. Fibaro utilise le SDK officiel de Zwave donc pas de problème en sécurisé pour eux.

Et pour la future puce 700 ils (jeedom) devront écrire totalement le plugin en utilisant les librairies SDK officiels Zwave, ce qui devrait régler le problème, mais bon on parle d'un futur à deux ans. Et peut etre ainsi qu'on aura un S2 fonctionnel

[dJuL]

Est-ce que du coup on est pas en train de ce dire qu’il y a une préconisation sur le nombre de modules maximum par contrôleur ?

Et si c’est le cas quel serait le chiffre clé ? 50? 60? 3000?


Envoyé de mon iPhone en utilisant Tapatalk

Pour moi la réponse est simple (concernant le mode sécurisé ou non)
- Pour tous les modules susceptibles de communiquer en même temps à un instant T: (ex: j'allume 5 lampes dans un scénario, je baisse 3 volets roulants...) => AUCUN EN MODE SÉCURISÉ
- Pour tout le reste qui renvoi juste des valeurs de temps en temps cela ne semble pas poser de problème (car ça ne peut pas surcharger le contrôleur qui reçoit juste un état une fois par si par là).

je pense que c'est du au plugin OpenZwave qui gère mal ceci mais ce n'est que mon avis personnel...

Je pense aussi (même si ça reste qu'une supposition) car ceux qui sont sur HC avec que du Fibaro, j'imagine bien qu'ils sont beaucoup en sécurisé vu que c'est ce qui est préconisé par le fabricant...

[akenad]

... Et la question en suspend reste est-ce que ça vient de jeedom, d'openzwave, de la clef zwave ou des 2 ou des 3.
Ou bien c'est carrément le protocole zwave qui est naze en sécurisé.

La réponse est dans mon post précédent plus haut.

akenad

[mortyre]

Le pb c'est le fork, le mode sécurisé a toujours eu des problèmes des qu'on mets plusieurs devices. Si un plugin zwave utilisait le SDK de zwave on aurait pas de pb pour pouvoir utiliser le mode sécurisé.