Bien réussir son inclusion Z-Wave

Plugins Protocole domotique
1

Bonjour à toutes et à tous,

Voici une liste d’éléments à suivre pour s’assurer de réussir au mieux les intégrations des modules Z-Wave dans votre système. Puis de permettre à celui-ci d’être le plus stable possible, et éviter des déconvenues tel que des nœuds morts.
On peut voir ceci un peut comme todo list.

0 − Prérequis

Avoir un contrôleur Z-Wave relié à votre Jeedom, ainsi que le plugin-openzwave installé, activé, avec les dépendances installées et le démon démarré.
S’il s’agit d’une clé USB, il est recommandé de la déporter de quelques centimètres via une rallonge USB.
Aussi, éviter de la brancher sur un port USB 3.0, en général, les contrôleur supportent mal l’alimentation électrique délivrée par ces ports. Il faut donc privilégier les ports USB 2.0
Dans le cas d’une utilisation d’un Raspberry Pi, s’il y a plus d’une clé USB de brancher, il est préférable d’avoir une alimentation électrique d’au moins 3A. Si plus de 2 clés USB, il faut déporter les clés sur un hub USB auto-alimenté. Ceci afin d’avoir assez de puissance électrique pour alimenter correctement tous les éléments.

1 − Préparation

Utiliser un câble dédié de ce type pour réaliser les étapes suivantes au plus prêt du contrôleur primaire.

cable
cable1138×836 168 KB

:warning: – Attention à bien débrancher le câble avant de toucher aux fils.

2 − Exclure / réinitialiser le module

Avant de vouloir inclure le module, il est recommandé de l’exclure / faire une réinitialisation usine (selon ce qui est spécifié sur la documentation du module).
Ceci pour éviter tout problème de dédoublement du numéro d’ID lié à une précédente utilisation. (Le faire sur un matériel neuf est recommandé aussi).

3 − Inclure le module en mode non sécurisé

Le mode sécurisé proposé par OpenZwave ne doit être réservé que pour les éléments le nécessitant, tel que les serrures.
Pour tous les autres modules, il est préférable de choisir l’inclusion non-sécurisé, pour avoir des meilleurs temps de réponse du réseau, mais surtout une meilleure stabilité.

4 − Déplacer le module à son emplacement définitif

Une fois le module correctement inclus, il peut être déplacé à son emplacement définitif (plus besoin du câble).

5 − Soigner le nœud

Une fois le module installé à son nouvel emplacement, et alimenté (s’il est sur secteur), il faut soigner le nœud.
Pour ceci, sur Jeedom, aller dans ce nouveau module, puis cliquer sur le bouton bleu avec une clé nommée « Configuration ». Ensuite, dans l’onglet « Actions », lancé l’action « Mise à jour des nœuds voisins ». Puis lancer la seconde action « soigner le nœud ». Ces deux actions permettront de mettre à jour les routes pour ce module.
Ces actions peuvent prendre plusieurs heures si le réseau est composé d’une grande quantité de module, et surtout si certains sur pile ne se réveillent que ponctuellement.
Lors de ces actions, vu qu’elles peuvent prendre quelques minutes voir heures, il est recommandé de ne pas cliquer partout, au risque de surchargé le réseau.

6 − Etre notifié en cas de soucis

TBC

2

Inclusion non-sécurisée largement souhaitable

3

Bien vu, j’ai complétement oublié ce point, à mettre en n°1

4

Soigner régulièrement et automatiquement son réseau par l’emploi d’un bloc code de ce genre à mettre dans un scénario :

1 « J'aime »
5

Salut
Je rajoute 4. Reset le device avant inclusion ou a defaut l’exclure

J’ai récemment galéré avec un controleur de scène Hank d’occasion qui m´a écrasé un Qubino plusieurs fois avant que je realise qu’il n’avait jamais ete exclus. L’inclusion démarrait bien mais au lieu du controleur c’est le Qubino qui apparaissait avec tous ses paramètres remis a zero, je suppose que le no du noeud était le même.

Ca s’est réglé avec son exclusion: un device qui ne fait pas partie du reseau a été exclu

6

:+1:
Très juste, c’est un point essentiel, toujours exclure avant d’inclure.

7

Merci pour vos réponse.
Je viens de mettre à jour le 1er post en conséquence.

8

Tu peux aussi ajouter de déporter la clé Z-wave à une cinquantaine de cm de la box en utilisant un prolongateur ou, si nécessaire, par exemple si la puissance de l’alimentation de la box n’est pas suffisante, au moins 3A, de l’installer sur un hub autoalimenté.

9

Perso je ne recommanderais pas de soigner le réseau automatiquement:

  • soit le réseau est déjà stable, on n’y a pas rajouté de module récemment, les routes sont ok => aucun intérêt
  • soit il est déjà en peine et balancer des trames en automatique régulièrement risque juste de l’achever.
1 « J'aime »
10

Pour ma part, je le fais toutes les 6h et ça ne me génère aucune surcharge.
Ceci étant, mon réseau est très stable.
Et l’intérêt est quand même d’être informé automatiquement quand des noeuds sont morts.

11

Dans la doc, il est mentionné qu’il faut le faire 2 à 3 fois par semaine.
Après, de là à dire que ça a un effet positif/négatif, je ne suis pas assez callé

12

Mise à jour avec l’ajout d’un prérequis.

13

Pourrais-tu indiquer où cela est écrit?
Je viens de tout relire et je n’ai vu cela nulle part.

La seule phrase qui en parle est celle-ci:

L’option de soigner le réseau 2x par semaine permet de faire ce processus sans action de votre part, elle est utile lors de la mise en place de nouveaux modules et ou lorsqu’on les déplace.

Et cela ne veut pas dire qu’il faut le faire 2 à 3 fois par semaine.
Cela parle d’une option qui peut le faire automatiquement et qui est utile lors de la mise en place de nouveaux modules et ou lorsqu’on les déplace.
Pas en permanence.

D’ailleurs la doc n’est donc pas à jour car cette option n’existe plus car c’était probablement inutile.

14

Effectivement, je faisait référence à cette phrase. Et après relecture, je voie que j’avais oublié la fin de la phrase.

Dans tous les cas, tes remarques (sur la charge générée) étant justifiées, je pensais plus mettre en avant une notification grâce à ce que tu as pu indiquer ici : ZWave détection de noeud mort - #3 par Mips