Note ajoutée depuis : le texte d'origine était rédigé à la troisième personne, je l'ai remis au « je ». L'installation dont il est question est celle passée de Vera à Jeedom début 2016. Les URL données ici sont celles d'OpenZwave à ce moment-là : le moteur Z-Wave de Jeedom a changé plusieurs fois depuis, la démarche reste valable, les adresses non.
Vous voulez vérifier qu'un module Z-Wave bien précis de votre installation domotique est toujours vivant ? Savoir s'il est disponible à l'instant où vous lui parlez, et forcer une action s'il ne répond pas alors qu'on sait qu'il est bien sur le réseau ?
L'idée de ce billet est là : envoyer une espèce de « ping » à un module et s'en servir non pas pour mesurer quelque chose, mais pour le réveiller.
Avertissement, pour les plus pointilleux
Ce n'est pas un ping au sens réseau du terme, celui que tout le monde connaît sous Windows ou Unix. C'est une action qui demande au contrôleur d'aller tester un nœud du réseau Z-Wave. J'emploie le mot « ping » parce qu'il parle à tout le monde et qu'il décrit bien l'intention.
Autre précision qui a son importance : cette action ne réveillera pas un module sur pile qui dort tranquillement entre deux relevés. Elle sert à récupérer un module en échec sur le réseau, typiquement après une coupure de courant.
Qu'est-ce qu'un module Z-Wave « endormi » ?
Le mot recouvre deux situations très différentes :
- Un module sur pile, qui envoie ses informations toutes les X minutes et qui dort le reste du temps pour économiser sa batterie. L'intervalle de réveil est configurable selon le type et le modèle. Là, rien à faire : on ne le joint qu'à son réveil, c'est prévu comme ça.
- Un module qui a présenté un dysfonctionnement et qui ne répond plus sur le réseau Z-Wave. Le contrôleur a tenté de lui parler, n'a rien reçu en retour, et l'a marqué en échec. Il est pourtant toujours inclus dans le réseau : il est là, mais considéré comme mort. C'est le « zombie ».
Ce billet ne traite que du second cas. Un module en échec, mais toujours présent dans le réseau.
Le cas concret : la porte de garage
Chez moi, l'ouverture de la porte de garage repose sur deux modules distincts :
- un module Fibaro à contact sec, câblé sur le moteur de la porte, qui donne l'impulsion d'ouverture ;
- un second module, en amont, qui coupe l'alimentation électrique du premier après X minutes.
Pourquoi couper ? Pour que le contact sec ne reste pas sous tension en permanence. Sauf que le module à contact sec, une fois privé de courant, disparaît du réseau Z-Wave au bout d'un certain temps. Jeedom finit par se rendre compte qu'il ne répond plus et le marque en échec.
Et c'est là que ça se gâte : quand je demande ensuite à Jeedom d'ouvrir la porte, il envoie l'ordre à un module qu'il considère comme mort. L'ordre part, personne ne répond, la porte ne bouge pas. Parfois elle s'ouvrait, parfois non — complètement aléatoire. Je me retrouvais bête, coincé dans la voiture devant une porte fermée, un dimanche soir sous la pluie.
Je n'ai jamais étudié en profondeur le comportement de Jeedom là-dessus : au bout de combien de temps décide-t-il qu'un module est mort ? Combien de tentatives ? Aucune idée. Ce qui m'intéressait, c'était que la porte s'ouvre à chaque fois.
La solution : réalimenter, pinger, puis agir
Le scénario remet d'abord le courant, puis va taper sur le module pour le forcer à réapparaître, et seulement après lui donne l'ordre d'ouvrir. Tout ceci est parfaitement transparent pour celui qui appuie sur le bouton.
Résumé du scénario :
| # | Étape |
|---|---|
| 1 | Module d'alimentation coupé (état de repos) |
| 2 | Module d'alimentation rallumé |
| 3 | Pause 1 seconde |
| 4 | Jeedom envoie le « ping » vers le module réalimenté |
| 5 | Pause 1 seconde |
| 6 | Action d'ouverture, via le scénario ou via les events |
Les deux pauses d'une seconde ne sont pas décoratives : la première laisse au module le temps de démarrer et de se signaler, la seconde laisse au contrôleur le temps d'encaisser la réponse et de sortir le nœud de l'état « en échec ». Sans elles, on repart trop vite et on retombe sur le même problème.
Depuis, plus un seul raté à l'ouverture de la porte de garage. C'est un contournement, j'en conviens volontiers — mais un contournement redoutablement efficace.
Concrètement : la requête
On passe par l'API de Jeedom, avec une simple requête HTTP(S). Historiquement, pour tester un module précis :
http://ip:8083/ZWaveAPI/Run/devices[x].TestNode()La dernière mise à jour d'OpenZwave a complètement changé le moteur REST : l'URL ci-dessus ne répond plus. Il faut désormais passer par celle-ci :
http://127.0.0.1:8083/node?node_id=NodeID&type=action&action=testNode&apikey=cleapiAvec :
NodeID— le numéro du nœud Z-Wave du module, celui affiché sur sa page de configuration (attention, ce n'est pas l'ID d'équipement Jeedom) ;cleapi— la clé API du plugin, à récupérer dans les réglages.
Remarque importante : cette URL n'est plus accessible qu'en local. Il faut donc obligatoirement l'appeler sur 127.0.0.1, depuis la box elle-même — un appel depuis l'extérieur, ou même depuis une autre machine du réseau, se fera jeter.
Dans un scénario Jeedom, cela se glisse dans un bloc « code » ou dans une action de type requête HTTP :
file_get_contents('http://127.0.0.1:8083/node?node_id=12&type=action&action=testNode&apikey=VOTRECLEAPI');Contrairement à un vrai ping, on ne reçoit pas de réponse exploitable dans la foulée. On ne lit pas un résultat : on demande au contrôleur d'aller voir. C'est lui qui, derrière, saura si le module est en ligne ou non, et qui le sortira de l'état d'échec le cas échéant. D'où la pause juste après.
Pourquoi s'embêter avec ça ?
Imaginez une installation où un module n'est pas alimenté en permanence : un relais coupe le courant d'une partie du montage, et un second module, situé derrière ce relais, pilote la porte. Quand le relais coupe, il coupe aussi l'alimentation de celui qui ouvre et ferme la porte.
Vous voulez ouvrir votre garage. Le courant vient de revenir. Mais rien ne garantit que votre box a déjà compris que le module est de nouveau là. Le « ping » sert exactement à ça : forcer cette prise de conscience au moment où on en a besoin, plutôt que d'attendre que ça se fasse tout seul.
La même logique vaut pour tout module branché sur une prise commandée, une multiprise pilotée, ou une ligne qui saute régulièrement.
Trois remarques pour finir
- N'en abusez pas. Un test de nœud génère du trafic sur le réseau maillé. À la demande, dans un scénario précis, aucun souci ; en boucle toutes les dix secondes sur quinze modules, vous allez saturer votre Z-Wave et créer les pannes que vous cherchiez à éviter.
- Ça ne remplace pas une bonne inclusion. Si un module tombe en échec tous les deux jours sans qu'on lui coupe le courant, le problème est ailleurs : portée, routage, alimentation douteuse. Le ping masquerait le symptôme.
- Notez le NodeID quelque part. Le jour où vous réincluez le module, il change — et votre scénario continuera d'appeler gentiment un nœud qui n'existe plus, sans le moindre message d'erreur.