Module Spirit - Thermostatic Valve

Oui çà fonctionne avec la clé S0 indiqué dans la doc et dans l’encart bleu depuis le panneau de paramétrage du plugin mais comme pour moi je n’avais pas fait d’inclusion sécurisé je n’avais pas changé la clé générée par le plugin.

Donc pas besoin de tt réinclure ?

Je ne veux pas d’inclusion sécurisée surtout pour des modules qui peuvent faire du routage donc nécessaire de faire de la ré-inclusion

Vous savez que cela n’a aucun rapport?
Sécurisé ou non sécurisé n’intervient pas dans la possibilité de faire du routage.

2 « J'aime »

Hello, intéressant.

Donc la phrase :

Un module ‘non sécurisé’ peut commander des modules ‘non sécurisés’. Un module ‘non sécurisé’ ne peut pas commander un module ‘sécurisé’. Un module ‘sécurisé’ pourra commander des modules ‘non sécurisés’ sous réserve que l’émetteur le supporte

n’inclus pas la notion de routage ?

Non, voici un article & test qui explique la situation: Noeuds sécurisés et effets sur le maillage - La domotique de Nechry
Et j’ai vécu longtemps avec la moitié de mes modules inclus en sécurisé sans jamais de problème de maillage (et donc de routage)

Mais je ne suis pas sur de ce qu’on entend par « commander » dans cette phrase de toute façon: très souvent ce n’est que le contrôleur qui commande les autres modules, et lui peut tout faire.

Une autre façon de commander c’est via une association directe et de mon expérience, je n’ai jamais réussi à faire des associations directes entre 2 modules inclus différemment: il fallait qu’ils soient soit tous les deux inclus en sécurisés soit tous les deux en non-sécurisés

Je ne vois pas d’autres façon de « commander » un module.

1 « J'aime »

Bonjour,

Je confirme que la citation concerne uniquement les associations directes entre modules.

Dans ce cas il suffit de réinclure le module sans effacer l’équipement original.
Puis simplement supprimer le nouvel équipement créé et modifier le nodeid dans l’équipement original (j’imagine que ça fonctionne même en passant de sécurisé vers non sécurisé).
Si ça ne fonctionne pas il suffit d’utiliser le nouvel outil de remplacement de commande.
Dans les 2 cas de figure c’est très rapide à faire.

Après à savoir que les modules en mode sécurisés semblent fonctionner très bien avec zwavejs (ce qui n’était pas du tout le cas avec openzawe qui perdait des trames, et pouvait rater des commandes ou des maj d’états, surtout lors de connexions et de messages en simultanés sur le réseau zwave).
Chez moi je n’ai plus aucun soucis avec les modules sécurisés depuis la migration.
Donc si il n’y a pas l’utilité d’associations directes avec des modules non sécurisé, pas forcément nécessaire de réinclure les modules…

1 « J'aime »

Hello, merci pour ce retour :ok_hand:

Hello, suite à un pb « bizarre » sur ma pile Zwave, je me suis remis à la migration ZwaveJS et j’ai un souci: j’ai intégré une de mes vannes sur mon nouveau contrôleur Z-Stick 7, les commandes de changement de mode échouent avec l’erreur suivante :

Erreur exécution de la commande [Entrée][5 - Vanne entrée][Mode-Eco] : {"state":"nok","result":"{\"code\":\"ERR_INVALID_ARG_TYPE\"}"}

Mais la commande passe bien si je la joue depuis l’onglet valeurs du noeud

[setNodeValue] 5-64-0-mode 11

Les commandes sont bien au bon format :

Une idée ?

Edit : résolu avec une ré-interview du noeud semble-t-il