[V4][Intégration] Z-wave

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:

Encore plus simple:

ZwaveMock.Driver = ZwaveDriverMock;

Dans le code, je fais:

this._driver = new this.ZWaveJS.Driver(port, options);
1 Like

Bonjour,

Maintenant que je peux créer des boutons, je tente une scene :wink:

Declencheur:
image
Difficile de choisir un des 4 boutons mais je choisis au hazard :grinning:

Action:
image
Mon binary switch (double), pas de choix possible

Je clique et erreur car il y a 2 features pour une sortie, tous les 2 avec category/type switch/binary (donc 4 pour le device en question):

  • currentValue = état de la sortie (ro)
  • targetValue = état demandé de la sortie (rw)

Or la scene lance le premier feature switch/binary associé au device et dans mon cas “currentValue” de la première sortie.
Autre soucis avec ces 2 feature liées, dans le dashboard, l’état du switch n’est pas synchronisé avec l’etat actuel
image

  1. Soit je supprime currentValue mais impossible de l’utiliser comme déclencheur.
  2. Soit je supprime targetValue mais impossible d’avoir un bouton sur le dashboard
  3. Je garde les 2 et on utilise par ex. le read/only pour différencier les 2 dans la scene
  4. Autre suggestion

PS: Le choix du bouton ainsi que le choix de la sortie:
Comment cela se passe avec le z-wave actuel? On pourrait imaginer faire un split du device en plusieurs device “virtuel” (je dirais que c’est l’intégration qui sait comment faire, dans le cas du z-wave c’est le nombre d’endpoint). On peut nommer chaque sous-device, l’associé à une pièce, changer le feature lampe/prise.

Tu mets le doigt sur un retour qu’on a souvent en ce moment, et qu’on va changer: l’affichage des fonctionnalités pour les device qui ont plein de fois la même feature ^^ On va changer ça :slight_smile:

Cf => On trigger "device state changed" in scene, it's hard to differentiate devices as it's not the device feature name that is used · Issue #1313 · GladysAssistant/Gladys · GitHub

De même, on a eu le retour par @Terdious récemment, cette box en fait prend en compte qu’un device de type “prise ou lumière” n’a qu’une seule feature binaire, ce qui n’est pas le cas avec certaines intégrations.

On va changer ça => In action "turn on/off the light/switch", it should be a device feature selector, not a device selector · Issue #1314 · GladysAssistant/Gladys · GitHub

En attendant, tu as une autre action qui peut être utile, “contrôler un appareil”:

De quel type d’appareil parle on et quel est le cas d’usage ? Pourquoi vouloir dupliquer la fonctionnalité ? Donne moi plus d’informations car c’est dur de statuer là :slight_smile:

ça se passe pas, actuellement ce genre d’appareil n’est pas bien géré car personne n’a travaillé sur ce cas :slight_smile: Donc tout est possible, tout est à définir !

Tu peux m’en dire plus sur le cas d’usage (sans parler technique) ? Pourquoi un appareil a autant de fonctionnalités ?

@Romuald_Pochet Je te confirme que j’ai corrigé l’affichage des device feature, désormais sur les intégrations: Z-Wave, MQTT, Zigbee2mqtt, Bluetooth, Tasmota et ewelink, on affiche le nom de la feature et plus le nom du device! :slight_smile:

C’est sur master, tu peux rebase si tu veux avoir le changement

1 Like

Pour chaque endpoint (endpoint=0 → toutes les sorties, endpoint > 0 → une sortie spécifique), on a les propriétés suivantes:

  1. currentValue: read-only feature - status de la sortie (“on” - “off”)
  2. targetValue: writeable feature - status attendu de la sortie (on veut “on” ou “off”)

Clairement, l’intégration pourrait gérer les 2 propriétés en une seule feature:

  1. event zwave currentValue → update Gladys feature
  2. event Gladys feature → send zwave targetValue

Je teste ce soir

Je ne veux pas dupliquer la feature, mais cloner le device en ne gardant qu’une seule des feature multiple:
A partir de:

  1. device x: switch binary 0, switch binary 1, switch binary 2 et temperature (ex. Qubino 2 relays)
    On crée 3 device “virtuel”:
  2. device x: switch binary 0 et température
  3. device x1: switch binary 1
  4. device x2: switch binary 2

On peut donc aussi assigner chacune des 3 devices à une pièce (il doit y avoir un fil de discussion a ce sujet), changer le type en lumière, par exemple.

Sur quel base tu décide quel appareil est splitté / pas splitté ? :slight_smile:

Effectivement ça résout ce problème pour ce genre d’appareil

On a la notion de endpoint, si il y a plusieurs fois la même feature, on a endpoint 1, 2… et toujours le endpoint 0 qui correspond à toutes les features

Ok!

Et donc l’idée ce serait:

Dès qu’un device a plus d’un endpoint, on split chaque feature dans un device avec une seule feature ?

Je serais intéressé de voir le résultat fonctionnellement pour l’utilisateur, pour voir si il arrive à comprendre ce qui se passe et à quoi va ressembler le nommage de tout ça :slight_smile:

Oui c’est l’idée…

Après il ne doit pas y avoir moulte device. A part, les switch avec plusieurs sorties.

Je dirais, c’est un “nice to have”, si les features sont correctement identifiés, on peut s’en sortir sans.

Il y a des périphériques plus compliqués comme mon clavier rfid Intégration Zipato "Mini Keypad"

J’attends beaucoup de vos travaux pour revenir sur Gladys car j’ai dû repasser sur Jeedom en attendant car aucun de mes appareils ne fonctionnent.

Je pense que c’est important, même juste pour les gens qui utilisent l’intégration Google Home dans Gladys, Google Home ne gère qu’un seul on/off par prise, donc ça marchera que si il y a plusieurs devices en fait !

Une possibilité (mais peut-être un peu fastidieuse si tu as beaucoup de device), c’est d’utiliser l’intégration Node-RED en attendant, @VonOx fait ça [NODE-RED] Zwavejs2mqtt et volet roulants ZMNHCD1.

Je n’ai pas de clavier RFID, après je pense que c’est un device assez complexe qui demande un flow propre au clavier (on est loin des simples boutons / prises / lumières / capteurs)

1 Like