[V4][Intégration] Z-wave

Génial! Tu as besoin d’aide pour avancer ? Qu’est ce qui bloque au niveau de la conversion de features ?

Pour les features, c’est juste determiner le type pour chaque commandClass (et donc le temps et le code commence a devenir trop dirty pour moi).

J’ai tenté de déployer dans mon docker mais je n’arrive pas a faire le build (j’ai déjà trouvé dans le forum qu’il fallait copier le repertoire static mais j’ai un soucis avec ENOENT: no such file or directory, open ‘/src/server/package.json’). Je dois encore étudier comment faire des pull request, donc beaucoup de boulot encore :wink:

Sinon, petite question a quoi sert le champ selector (je mets external_id pour l’instant) ?

Tu peux builder sur github directement il y’a une action toute prête

J’avais vu cette possibilité dans un autre post (qui permet de builder des image docker pour les nouveaux services). Je vais donc devoir m’atteler à lire la documentation sur tout cela… Je ne voudrais pas mettre le bazard. J’ai vu de nombreux posts sur le développement mais y a-t-il un endroit où tout est centralisée?

Y’a pas de doc la dessus

Il faut juste créer tes secrets sur github.

DOCKERHUB_USER
DOCKERHUB_PASSWORD
DOCKERHUB_REPO

Et dans l’onglet action sur ton repo tu lance un build dev sur ta branche

J’ai donc:

  1. Créé un fork du repo Gladys
  2. Crée une branche zwave2mqtt (dans mon repo)
  3. Lancer l’action ’ Build Gladys dev images’ sur la branche zwave2mqtt

J’ai une image docker créée dans mon repo docker que je peux déployer sur mon docker, on avance.

Plus qu’a regarder a faire un pull request

4 Likes

Tiens nous au courant !

Selector c’est un id unique utilisé en interne (dans l’API, dans les scènes). Il doit être lisible :slight_smile:

Dans le cas du Zwave actuel, on utilise une version slugify du nom du périphérique pour le selector

Exemple:

Après actuellement dans certaines intégrations le slug n’est pas assez unique, je me demande si le slugify + ajouter un entier random de quelques caractères à la fin ne ferait pas plus sens. Dans tous les cas il faut que ce soit unique et lisible !

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.
https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

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