[V4][Intégration] Z-wave

Bonjour,

Long sujet ! Plein de bonnes initiatives.

Cela semble effectivement plein de bon sens d’aller vers l’implémentation full JS de zWave. Derrière c’est d’ailleurs la même personne que OZW. Donc même si OZW fait encore ses preuves (il est toujours à jour contrairement à ce qui a été dit il me semble), son créateur lui-même recommande de basculer sur la “nouvelle” version (projet initialisé en 2018). Bonne initiative donc :+1:

Je me permets par contre de poser la question de pourquoi zwavejs2mqtt plutôt que zwavejs directement ?

zwavejs2mqtt ressemble plus (en l’état) à un projet de démo / projet complet que d’une lib’ à utiliser dans ses projets.
En effet, zwavejs2mqtt embarque également toute une partie front (le panel) et toute une partie server pour communication en websocket qui n’est pas le cas d’utilisation dans un projet comme Gladys. Je me trompe ?
Qui plus est, ajouter le MQTT c’est ajouter une brique pas nécessairement utile. Oui l’implémentation Zigbee fonctionne ainsi. Oui, plusieurs Gladys peuvent être synchronisés via MQTT. Mais en soit MQTT n’est pas nécessaire à l’utilisation de zWave. Il va du coup également falloir gérer la “synchro” sur l’activation de MQTT entre zWave et Zigbee. C’est ajouter une couche pas forcément nécessaire non ?
A moins que le but justement soit d’intégrer toute la partie Control Panel dans Gladys… mais j’en doute :slight_smile:
Vous pensez sinon peut-être à un scénario que je n’ai même pas envisagé et je suis passé au travers de quelque chose ? Ou alors j’ai juste mal compris et vous souhaitez mimer le comportement de zigbee (passage par MQTT) mais en faisant l’implémentation vous-même (et donc en passant par zwavejs directement) ?

Sinon juste histoire d’avoir de la visibilité sur le sujet : est-ce que quelqu’un avance sur ce sujet ? Possible de bosser en PR histoire de voir un avancement / aider / autre ?

Bonne journée à tous,

Je suis ce topic mais je n’ai personnellement pas fait de tests entre zwavejs2mqtt et Zwavejs, après les avantages/inconvénients que je vois aux deux solutions:

Arguments pour zwavejs2mqtt :

  • Probablement moins de développement/maintenance sur la partie “UI administration z-wave” car il y a effectivement un front déjà inclus. Je sais qu’historiquement dans Gladys on a jamais géré la partie “Administration Zwave” (Changer les paramètres des nodes, etc…) et ça a toujours forcé les utilisateurs a passer par une autre box pour administrer le Zwave dans Gladys.
  • L’API MQTT est facile à consommer, il n’y a quasiment plus à penser au Z-Wave c’est juste du pub/sub.

Arguments contre zwavejs2mqtt :

  • Le fait qu’il y ait une interface externe à Gladys pour gérer le Z-Wave est confusant, pas super UX friendly et “démembre” le produit: on a plus un produit complet.
  • Grande dépendance à un projet externe qui ne va pas forcément être pérenne dans le temps.
  • Bug de lifecycle “mystique” moins facile à débugger: que se passe il si le container MQTT est en erreur? Comment gérer proprement les mises à jour ? Restart ? On voit déjà tous ces problèmes avec l’intégration Zigbee2mqtt, alors que les intégrations natives à Gladys sont stable dans le temps.

Arguments pour ZWaveJS :

  • On reste en natif dans Gladys. C’est plus facile à tester, c’est stable dans le temps.
  • Pas de dépendance externe, pas de lifecycle à gérer.

Arguments contre ZWaveJS:

  • Il faut tout coder: UI de gestion des nodes, administrations du réseau Zwave, etc… C’est plus de travail.

Ma conclusion c’est que dans l’idéal et si on avait des ressources illimitées, ZwaveJS ferait plus sens. Après ce n’est pas la réalité, donc tout dépend de celui qui développera l’intégration j’ai envie de dire :smiley:

@Sescandell si tu es motivé pour cloner l’intégration zwave actuelle et utiliser ZwaveJS à la place, carrément! Au niveau des développements je crois que @Romuald_Pochet s’était fait un POC mais rien de plus, donc tout reste à faire.

Si on arrive à se mettre d’accord sur des histoires de virgules et de point ça devrait le faire :smiley:

Je jète un oeil ce soir à ça pour “voir ce que ça pourrait donner”. Et on voit comment avancer.

2 Likes

Bonsoir,

J’ai en effet rajouter un service zwave2mqtt qui fonctionne en local chez moi. J’ai déjà effectué un fork du repo Gladys et je peux builder une image docker que je “déploie” dans mon docker (j’ai des soucis car l’image que je récupère semble ne pas être équivalent à celle que je teste dans vsc, avec le même zwave2mqtt). Il reste pas mal de travail sur la partie front que je ne maitrise pas du tout…

Un exemple (une piece regroupant tout):

Quelques petits souci avec par ex. la feature humidité (qui est fonctionnelle tout de même) et le nommage des devices feature (j’aimerais mettre le nom zwave en tant que tips (avec le nom actuel) et un nom plus parlant genre “Lampe/prise…” mais cela implique de mieux maîtriser le front et donc du temps…

Pour le pull request, je n’ai pas encore eu l’occasion de me documenter sur le sujet, ni de suivre les règles de bonnes pratiques de développement (je n’ai pas de tests par ex.)

Voilà pour l’etat d’avancement…

2 Likes

Si ça peut t’aider pour la création d’un pull request.

Bonjour,

Reçu ma nouvelle clé ZWave la semaine passée (je suis reparti du travail de @Sescandell). J’ai réussi à intégrer:

  • Le controlleur
  • Un switch FGS223
  • Un interrupteur CWS-3101

Malheureusement, je n’ai pas énormement de device disponible et je ne connais pas le comportement actuel du Zwave, voire de Gladys.

J’ai crée une scene, déclenchée par l’interrupteur pour controller le FGS223

  1. Le CWS-3101 utilise la classe 91 (Scene) et envoie un 0 (simple clic) lors de l’appui. Or la scene attend un 0 our Off et 1 pour On. Je penserais rajouter un ‘Click’ à coté du On / Off, mais a voir pour la condition a codée
  2. Le FGS223 utilise “currentValue” (read_only) pour la valeur actuelle et “targetValue” (writeable) pour la modifier “currentValue”. Je pense n’utiliser que “targetValue” comme feature (a tester pour le feedback qui doit etre réalisé via “currentValue”)
  3. Me reste quelque detail concernant les libellés mais je ne pense pas que cela soit lié aux devices ZWave mais plutôt aux categories

Génial! :slight_smile:

Quand tu dis “j’ai réussi à intégrer”, c’est via l’intégration ZWave actuelle avec OpenZwave ou via ton POC Zwavejs2mqtt ?

On a pas encore de vue “bouton” dans l’UI de déclenchement de scène, mais ça vaudrait le coup d’en développer un.

Par contre je pense qu’envoyer “1” ferait plus sens que “0” (comme on fait pour les capteurs de mouvement par exemple, qui envoient “1” à chaque détection), donc il faudrait faire un petit mapping dans l’intégration Z-Wave.

D’une manière générale, on aimerait passer à ZWaveJS, si tu veux aider sur cette partie là, on peut s’appeler si tu veux que je t’explique le fonctionnement actuel !

Bonjour,

Non, j’utilise bien ZwaveJS (je suis parti des travaux de @Sescandell). Le modèle est assez proche de celle de ZwaveJs2mqtt.

Pour le 0, c’est la valeur reçu par Zwave (c’est 3 pour un double-click) mais d’accord pour un mapping au niveau Gladys.

Pour le bouton, j’utilise actuellement la même categorie/type qu’un interrupteur binaire.

J’ai trouvé un detecteur de mouvement/temperature dans un tiroir, je suis occupé a l’intégrer. Apres cele, on devrait couvrir une bonne partie des fonctionnalités

Ah génial ! :slight_smile:

Top ! C’est ce qu’on fait en général dans toutes les intégrations, on essaie d’harmoniser les valeurs entre les différents services (vu que forcément c’est pas toujours pareil). Je pense que “1” pour dire “click” fait plus sens :slight_smile:

Génial

N’hésite pas si tu as d’autres questions, ou si tu as besoin d’un coup de main / ou si tu veux qu’on regarde spécifiquement certains points.

ça fait plaisir de voir un peu du développement sur le Z-Wave, ça va changer pas mal de chose si on arrive à dropper OpenZwave ^^

  • Les temps de build vont être grandement réduit, actuellement on perd beaucoup de temps à installer OpenZwave.
  • La stabilité générale de Gladys va être améliorée, car actuellement si OpenZwave crash, ça entraine Gladys vu que Open-Zwave est exécuté en temps que module C++

cc @VonOx

Hello,

C’est cool tout ce que tu annonces !

Tu aurais une PR à ouvrir / partager qu’on puisse voir l’évolution, avancer à plusieurs sur le point ?

Salut,

Pas encore de PR. J’ai travaillé sur une branche que je mergeait régulièrement avec mon master. Mais depuis quelques jours, les build échouent lors des tests. J’ai donc tenté de résoudre ce problème. Malheureusement, depuis quelques jours, mon fork est “instable”, plein d’erreurs 500 sur GitHub, impossible de faire un merge branch > master (il reste en status “Checking for ability to merge automatically…”)…

J’ai tenté un PR: Zwavejs by rpochet · Pull Request #1309 · GladysAssistant/Gladys · GitHub

J’ai tenté un déploiement sur mon environnement de Prod, il y a quelques devices qui sont mal/pas reconnu. J’ai aussi des soucis de device “en double”.

PS: je ne suis pas forcément fier de toutes les lignes de code :wink:

1 Like

@Romuald_Pochet Top pour ta PR! :slight_smile:

N’hésite pas si tu as es questions à un moment.

Bonjour,

J’ai peut-etre une question concernant les import des librairies externes. J’ai mis require(‘zwave-js’); dans le constructeur du manager, par contre pour le beginInclusion, il faut passer une objet de type .ZWaveJS.InclusionStrategy. Comment faire pour l’import ?

Tu peux passer la lib à ton constructeur, exemple dans Philips Hue:

Et ensuite tu auras accès dans toutes les fonctions à this.zwaveJs (par exemple)

C’est ce que j’avais fait mais je n’ai pas access aux valeurs: this.ZWaveJS.InclusionStrategy est undefined. Pas de soucis avec les méthodes. Dans zwavejs2mqtt, il utilise un import { InclusionStrategy } from ‘zwave-js’;

Tu es sûr de ton code?

Je me suis fais un fichier de 2 lignes ou j’affiche le contenu de InclusionStrategy et j’ai bien de la donnée:

A mon avis tu as du te tromper quelques part

My god, j’utilisais la version 7.11.0 de zwave-js… ca marche beaucoup mieux maintenant

3 Likes

Bonjour,

Je me lance sur les tests afin de pouvoir lancer un build. J’ai un soucis avec le code suivants:

this.driver = new this.ZWaveJS.Driver(driverPath, {
    logConfig: {
      level: 'info',
    },
  });

Pour les tests, ZWaveJS est du style:

const ZwaveMock = function ZwaveMock(options) {};

NEW: const ZwaveDriverMock = function ZwaveDriverMock(port, options) {};
NEW: ZwaveDriverMock.prototype = Object.create(new EventEmitter());
NEW: ZwaveDriverMock.prototype.start = fake.resolves(true);

ZwaveMock.prototype = Object.create(new EventEmitter());
NEW: ZwaveMock.prototype.Driver = fake.returns(ZwaveDriverMock); 
ZwaveMock.prototype.addNode = fake.returns(null);

L’execution du test renvoie:

TypeError: this.ZWaveJS.Driver is not a constructor

J’ai testé plusieurs solutions: fake, stub… mais rien n’y fait.
Une idée?

fake.returns créé une fonction qui retourne ZwaveDriverMock, or toi tu veux que ce soit une classe (pas une fonction), il faut donc que tu mettes directement je suppose:

ZwaveMock.prototype.Driver = ZwaveDriverMock;

(Après je me suis juste basé sur ton bout de code là et l’erreur, il y a peut-être plus à changer dans le reste des tests :D)

N’hésite pas si tu as d’autres questions :slight_smile: