Utilisation de la télécommande HANK 4-key scene controller


#1

Bonjour à tous,

Voilà quelques jours que j’essaie de jouer un peu avec Gladys et ZWave. Je dispose d’une clé ZWave.Me connecté au RPi et à priori reconnu dans Gladys.

Je cherche maintenant à intégrer dans le système la télécommande HANK 4-Key Scene Controller (référence HANK HKZW-SCN04). Je cherche à faire un truc bête et méchant : à chaque appui sur un bouton, envoyer une notification. Mais impossible ! J’ai l’impression que les données ne sont jamais envoyées à Gladys. Dans les logs OZW je vois bien des infos au clic sur un des boutons de la télécommande, mais rien dans Gladys (enfin… rien concernant l’appui sur le bouton. Cette télécommande étant en mode “always off”, à chaque appui - ou presque - elle envoie également le status de sa batterie : et ça Gladys le reçoit bien).

J’ai également des soucis de connexion de la télécommande avec Gladys lorsque Gladys redémarre (coupure de courant) ou après une longue inactivité.

Ma question est donc : quelqu’un possède-t-il cette télécommande et a-t-il réussi à correctement la configurer / l’intégrer au sein de Gladys. Est-ce que potentiellement ce type de device n’est pas du tout pris en charge et nécessiterait d’éventuels dev’ pour fonctionner ? (je préfère poser la question avant de m’aventurer dans le code du module… complètement inconnu à date pour moi… mais j’ai l’impression que je ne vais pas y échapper :slight_smile: )

Merci pour toute aide,


#2

Re,

Je ne connais pas assez le principe du protocole ZWave (il faudrait que je commence par me renseigner de ce côté-là certainement). Mais en me baladant dans le code de OZW, je vois qu’il est question de “Scene” et d’association". Se pourrait-il que tout soit lié ? Et que finalement effectivement, à date, Gladys (et le module ZWave) ne sait pas gérer ce types de périphériques ?


#3

Bonjour,

J’ai pas mal creusé le sujet, mais je ne trouve pas de solution.

J’ai essayé différentes choses, récupéré un poste de Home Assistant qui semble énoncer le même soucis, mais je n’arrive malgré tout pas à faire envoyer les commandes de la télécommande à Gladys.

Quand j’affiche les logs OZW, lors d’un clic sur un bouton, j’ai ceci :

2019-02-05 23:10:52.712 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0xe5, 0x00, 0x03, 0xcf, 0x00, 0x84
2019-02-05 23:10:52.712 Detail, 
2019-02-05 23:10:52.712 Info, Node006, Received Central Scene set from node 6: scene id=3 in 0 seconds. Sending event notification.
2019-02-05 23:10:52.712 Warning, Node006, No ValueID created for Scene 3
2019-02-05 23:10:53.205 Detail, Node006,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x06, 0x03, 0x80, 0x03, 0x64, 0xca, 0x00, 0xd8
2019-02-05 23:10:53.205 Detail, 
2019-02-05 23:10:53.205 Info, Node006, Received Battery report from node 6: level=100
2019-02-05 23:10:53.205 Detail, Node006, Refreshed Value: old value=100, new value=100, type=byte
2019-02-05 23:10:53.205 Detail, Node006, Changes to this value are not verified
2019-02-05 23:10:53.205 Detail, Node006, Notification: ValueChanged

Dans les logs Gladys, je vois bien l’event value changed concernant le niveau de la batterie. Par contre, pour l’appui à proprement parler : je ne reçois rien !

J’ai tenté d’utiliser la librairie OpenZwave-Shared en direct (nodejs) pour voir un peu ce qu’il se passait. J’ai eu beau mettre des handler sur du scene event : mais je n’ai aucune trace supplémentaire (j’ai légèrement modifié le fichier test.js du repo pour ajouter des console.log et différents handlers).

Ce qui m’étonne c’est le Warning, Node006, No ValueID created for Scene 3 dans les logs OZW. Il y a certainement un point qui m’échappe… peut-être @MathieuA pourrait m’aider sur ce point à y voir plus clair ?

J’ai même tenté (je reconnais sans réellement comprendre ce que je faisais :D) de modifier le fichier /usr/local/etc/openzwave/hank/scenecontroller4.xml pour ajouter la section suivante comme proposé dans ce sujet… mais en vain :slight_smile:

<CommandClass id="91" name="COMMAND_CLASS_CENTRAL_SCENE" version="1" request_flags="4" issecured="true" innif="true" scenecount="0">
        <Instance index="1" />
        <Value type="int" genre="system" instance="1" index="0" label="Scene Count" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
        <Value type="int" genre="system" instance="1" index="1" label="Button One" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
        <Value type="int" genre="system" instance="1" index="2" label="Button Two" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
        <Value type="int" genre="system" instance="1" index="3" label="Button Three" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
        <Value type="int" genre="system" instance="1" index="4" label="Button Four" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
</CommandClass>

Il me manque certainement une configuration à envoyer à la télécomande ?

Merci !


#4

Salut @Bleys ! Excuse moi, j’ai pas vu ton post passé ^^

Alors déjà pour répondre a cette question :

C’est normal entre guillemets, les périphériques Zwave sur batterie passe en mode sommeil pour économiser leurs batteries donc il se peut que des fois ils peinent a rétablir la connexion car le controller zwave doit les bombarder pour les réveiller et avoir une réponse ^^
Mais ça c’est un comportement du réseau Zwave on n’y peut rien, on a eu le soucis avec @pierre-gilles et son capteur de mouvement aussi !

Pour le reste j’ai regardé un peu, déjà ce que je trouve bizarre c’est qu’aucune config pour ton bouton n’existe dans OpenZwave mais tu reçois bien les infos quand même :thinking:

Tu peux me montrer les devicetypes qui ont été créé avec ton bouton dans Gladys ?
Pour le moment le module Zwave de Gladys ne gère pas les scène et de ce que je vois ton bouton n’utilise que ça donc la c’est le bordel ^^
Mais c’est justement l’occasion d’ajouter cette fonctionnalité au module Zwave !
Par contre si possible vire toutes tes modifs pour qu’on parte sur de bonnes bases, ensuite fait plusieurs appuis sur ton bouton et met moi les logs ici que je regarde à quoi ça ressemble :slight_smile:


#5

J’ai finit par comprendre ça oui. Et j’ai aussi trouvé le moyen de “réveiller” le device (enfin, surtout sa reconnaissance au niveau du controlleur). C’est une mani’p qu’il faut que je retienne… passons…

Si elle existe : elle est ici

C’est ce que j’ai cru comprendre oui… et justement, je suis prêt à mettre les mains dans le cambouis pour gérer cette partie là. Mais j’ai l’impression que j’attaque avec un device qui n’est déjà de base pas le mieux géré par OpenZwave en fait…

C’est fait !

Ca me donne ce que j’ai mis dans mon dernier post en boucle :

2019-02-05 23:10:52.712 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0xe5, 0x00, 0x03, 0xcf, 0x00, 0x84
2019-02-05 23:10:52.712 Detail, 
2019-02-05 23:10:52.712 Info, Node006, Received Central Scene set from node 6: scene id=3 in 0 seconds. Sending event notification.
2019-02-05 23:10:52.712 Warning, Node006, No ValueID created for Scene 3
2019-02-05 23:10:53.205 Detail, Node006,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x06, 0x03, 0x80, 0x03, 0x64, 0xca, 0x00, 0xd8
2019-02-05 23:10:53.205 Detail, 
2019-02-05 23:10:53.205 Info, Node006, Received Battery report from node 6: level=100
2019-02-05 23:10:53.205 Detail, Node006, Refreshed Value: old value=100, new value=100, type=byte
2019-02-05 23:10:53.205 Detail, Node006, Changes to this value are not verified
2019-02-05 23:10:53.205 Detail, Node006, Notification: ValueChanged

Je refais ceci ce soir et je posterai ce qui est visible.
J’en profiterai également pour montrer ce que montre le module quand je le “force” son réveil/sa reconnaissance dans le réseau.

Idem, je te montre ça ce soir.

Merci pour ton temps !


#6

Voici les différentes infos demandées :

Logs de OpenZWave quand le device n’est pas “réveillé / reconnu sur le controller” et que je fais différents appuis :

$> cat api/hooks/zwave/node_modules/openzwave-shared/OZW_Log.txt 
2019-02-06 21:02:51.368 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0xff, 0x00, 0x01, 0xcf, 0x00, 0x9c
2019-02-06 21:02:51.368 Detail, 
2019-02-06 21:02:51.368 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:02:51.842 Detail, Node006,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x06, 0x03, 0x80, 0x03, 0x64, 0xd0, 0x00, 0xc2
2019-02-06 21:02:51.842 Detail, 
2019-02-06 21:02:51.842 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x80
2019-02-06 21:02:53.487 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x00, 0x00, 0x01, 0xd0, 0x00, 0x7c
2019-02-06 21:02:53.487 Detail, 
2019-02-06 21:02:53.488 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:02:55.567 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x01, 0x00, 0x02, 0xd4, 0x00, 0x7a
2019-02-06 21:02:55.568 Detail, 
2019-02-06 21:02:55.568 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:02:57.527 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x02, 0x00, 0x04, 0xcf, 0x00, 0x64
2019-02-06 21:02:57.528 Detail, 
2019-02-06 21:02:57.528 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:02:59.228 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x03, 0x00, 0x03, 0xcf, 0x00, 0x62
2019-02-06 21:02:59.228 Detail, 
2019-02-06 21:02:59.228 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:03:00.848 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x04, 0x00, 0x01, 0xd2, 0x00, 0x7a
2019-02-06 21:03:00.848 Detail, 
2019-02-06 21:03:00.848 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:03:02.167 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x05, 0x00, 0x03, 0xd0, 0x00, 0x7b
2019-02-06 21:03:02.167 Detail, 
2019-02-06 21:03:02.167 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-06 21:03:03.307 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0x06, 0x00, 0x02, 0xca, 0x00, 0x63
2019-02-06 21:03:03.310 Detail, 
2019-02-06 21:03:03.313 Info, Node006, ApplicationCommandHandler - Unhandled Command Class 0x5b

Voici ce qu’il se passe quand je “force un réveil du device au controller ZWave” (je reste appuyé plusieurs secondes sur le bouton 1) :

Malheureusement le log est trop long… du coup, j’ai mis ça sur un Gist ici

Je ne suis pas certain de ma procédure de “forcer la ré-association”. Mais étant donné que les résultats sont plus verbeux et “logiques”, je me dis que la manipulation n’est pas mauvaise.

Au passage, une fois ce “forcing fait”, dans Gladys j’ai des logs qui apparaissent à l’appui sur des boutons (alors qu’avant le forcing non) :

0|app  | Event : create : new Event with code : devicetype-new-value
0|app  | Event : create : new Event with code : devicetype-new-value
0|app  | Scenario : Trigger : New event : devicetype-new-value ["{ code: 'devicetype-new-value',\n  value: 14,\n  scope:\n   child {\n     value: 100,\n     devicetype: 14,\n     datetime: 2019-02-06T20:11:03.510Z,\n     createdAt: 2019-02-06T20:11:03.520Z,\n     updatedAt: 2019-02-06T20:11:03.520Z,\n     id: 119 } }"]
0|app  | Zwave module: State of node 6 created
0|app  | Scenario : Trigger : Found 1 launchers with code devicetype-new-value.
0|app  | Scenario : Trigger : New event : devicetype-new-value ["{ code: 'devicetype-new-value',\n  value: 12,\n  scope:\n   child {\n     value: 0,\n     devicetype: 12,\n     datetime: 2019-02-06T20:11:03.518Z,\n     createdAt: 2019-02-06T20:11:03.541Z,\n     updatedAt: 2019-02-06T20:11:03.541Z,\n     id: 120 } }"]
0|app  | Scenario : Trigger : Condition not verified.
0|app  | Zwave module: State of node 6 created
0|app  | Scenario : Trigger : Found 1 launchers with code devicetype-new-value.
0|app  | Scenario : Trigger : Condition not verified.
0|app  | House : checkUsersPresence
0|app  | House : checkUsersPresence
0|app  | Event : create : new Event with code : devicetype-new-value
0|app  | Scenario : Trigger : New event : devicetype-new-value ["{ code: 'devicetype-new-value',\n  value: 14,\n  scope:\n   child {\n     value: 100,\n     devicetype: 14,\n     datetime: 2019-02-06T20:23:23.469Z,\n     createdAt: 2019-02-06T20:23:23.471Z,\n     updatedAt: 2019-02-06T20:23:23.471Z,\n     id: 121 } }"]
0|app  | Zwave module: State of node 6 commclass 128 created
0|app  | Scenario : Trigger : Found 1 launchers with code devicetype-new-value.
0|app  | Scenario : Trigger : Condition not verified

On voit bien la réception du “Battery Level” (principe classique dans les device qui se mettent en veille automatiquement de ce que j’ai compris) mais pas du clic à proprement parler.

Voici le résultat d’un select sur la table devicetype :

+---------------+--------+----------+------------+--------+------+------+---------+-----------+------+
| name          | type   | category | identifier | sensor | min  | max  | display | lastValue | id   |
+---------------+--------+----------+------------+--------+------+------+---------+-----------+------+
| Basic         | byte   | NULL     | 1-32-0     |      0 |    0 |  255 |       0 |         0 |    1 |
| Level         | byte   | NULL     | 6-38-0     |      0 |    0 |  255 |       0 |         0 |    4 |
| Basic         | byte   | NULL     | 6-32-0     |      0 |    0 |  255 |       0 |         0 |    4 |
| Battery Level | byte   | NULL     | 6-128-0    |      1 |    0 |  100 |       0 |       100 |    4 |
| Bright        | button | NULL     | 6-38-1     |      0 |    0 |    0 |       0 |      NULL |    4 |
| Dim           | button | NULL     | 6-38-2     |      0 |    0 |    0 |       0 |      NULL |    4 |
+---------------+--------+----------+------------+--------+------+------+---------+-----------+------+

Enfin, pour finir sur ce que je peux dire pour aider, j’ai modifié le fichier test.js de openzwave-shared pour ajouter du console.log et un handler sur scene event. Voici le Gist avec le fichier modifié et les logs (en forçant une réassociation).

Dernière info, la documentation du device. Il y est question d’une notion de group et d’association. Mais je ne comprends pas si je dois faire quelque chose pour dire “je suis en mode groupe 1 et envoie tout au Controller”. D’ailleurs, dans la doc de openzwave-shared on voit qu’il est question de scene control & association group management. Je débute dans le ZWave et tout ce monde, peut-être que ça te parlera plus qu’à moi et que quelque chose te fera tilt (mais les fonctions du style addAssociation et/ou addSceneValue et le message d’erreur No ValueID dans les logs OZW me font dire qu’il manque une étape dans toute ça…).

N’hésite pas si tu as des questions.

Je continuerai bien sûr à creuser de mon côté (je vais m’intéresser au détail envoyé par le fichier de test et notamment la liste des class listées du device).

Merci encore une fois pour ton aide !


#7

Re,

Comme je le disais, j’ai creusé de mon côté également. Je commence à y voir plus clair dans tout ça, c’est déjà ça !

Le secret vient bien de la notion d’association. En croisant la doc de node-openzwave-shared et la doc du device, la notion d’association sont biens identiques. C’est peut-être évident pour vous, mais en tant que néophyte dans le domaine, j’apprends tous les jours toutes les notions (notamment ici scene et association mais pas association au sens attachement d’un device au réseau zwave…). J’ai donc écrit le petit bout de code suivant :

zwave.on('node added', function(nodeId) {
    if (nodeId != 6) { // id du device qui nous intéresse ici
    	return;
    }

    var groupsCount = zwave.getNumGroups(nodeId);
    console.log('Nombre de groupes %d', groupsCount);

    for(var i = 0; i<groupsCount; i++) {
    	var groupId = i+1;
    	var maxAssociationsCount = zwave.getMaxAssociations(nodeId, groupId);
    	var associations = zwave.getAssociations(nodeId, groupId)
    	console.log('Associations Group %d (%d/%d)', groupId, associations.length, maxAssociationsCount);
    	console.log("\t%o", associations)
    }
});

Ce qui donne un résultat assez identique à la documentation du device :

Nombre de groupes 9
Associations Group 1 (1/5)
        [ 1, [length]: 1 ]
Associations Group 2 (0/5)
        [ [length]: 0 ]
Associations Group 3 (0/5)
        [ [length]: 0 ]
Associations Group 4 (0/5)
        [ [length]: 0 ]
Associations Group 5 (0/5)
        [ [length]: 0 ]
Associations Group 6 (0/5)
        [ [length]: 0 ]
Associations Group 7 (0/5)
        [ [length]: 0 ]
Associations Group 8 (0/5)
        [ [length]: 0 ]
Associations Group 9 (0/5)
        [ [length]: 0 ]

Ce qui est intéressant également, c’est que le groupe 1 est bien associé à 1 device. Celui d’ID 1 => le controller ZWave. Dans la doc du device il est dit que le groupe 1 reçoit toutes les Scene Notification. Ce qui semble effectivement être le cas du fait de l’affichage du message d’erreur dans OZW :

2019-02-05 23:10:52.712 Detail, Node006,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x06, 0x05, 0x5b, 0x03, 0xe5, 0x00, 0x03, 0xcf, 0x00, 0x84
2019-02-05 23:10:52.712 Detail, 
2019-02-05 23:10:52.712 Info, Node006, Received Central Scene set from node 6: scene id=3 in 0 seconds. Sending event notification.
2019-02-05 23:10:52.712 Warning, Node006, No ValueID created for Scene 3

En y réfléchissant bien, c’est bien que la télécommande communique comme il faut avec le contrôleur. Mais tout ceci se passe “côté zwave”. Juste, le contrôleur ne sait pas quoi en faire (et à priori j’ai malheureusement pas de moyen de capter cette information côté NodeJS…).

En guise de tests, j’ai également modifié le code précédent pour ajouter une association :

zwave.on('node added', function(nodeId) {
    if (nodeId != 6) { // id du device qui nous intéresse ici
    	return;
    }

    var groupsCount = zwave.getNumGroups(nodeId);
    console.log('Nombre de groupes %d', groupsCount);

    for(var i = 0; i<groupsCount; i++) {
    	var groupId = i+1;
    	var maxAssociationsCount = zwave.getMaxAssociations(nodeId, groupId);
    	var associations = zwave.getAssociations(nodeId, groupId)
    	console.log('Associations Group %d (%d/%d)', groupId, associations.length, maxAssociationsCount);
    	console.log("\t%o", associations)

    	if (!associations.length) {
    		zwave.addAssociation(nodeId, groupId, 1); // 1 étant le nodeId du contrôlleur ZWave
    	}
    }
});

Dès lors, à chaque appui sur un bouton, je reçois maintenant un node event. Je pourrais plus ou moins m’en sortir avec ça… mais je suis convaincu que ce n’est pas encore la bonne chose à faire.

Je pensais au début du coup que je pourrais créer une scene par code via les méthodes createScene et addSceneValue de OZW. Cela permettrait à priori de transmettre automatiquement des datas à un autre noeud. Il aurait simplement fallut faire toute l’interface dans Gladys (pourquoi pas, super projet). Finalement, Gladys n’aurait alors servi que de “configurateur” d’ordre mais sans que, à la réception d’un event, cela passe par Gladys.

Sauf que, de ce que je comprends, une scene est définie “dans le contexte de l’instance OZW courante”. Je me base sur le fait que la création d’une scene ne prend pas d’ID de noeud d’origine pour être créée. La méthode createScene ne prend qu’un label. La méthode addSceneValue a ce format-là : zwave.addSceneValue(sceneId, { node_id:5, class_id: 38, instance:1, index:0}, 50);… plutôt quelque chose qui ressemble à “lors de l’activation de la scène sceneId, envoie la valeur 50 au noeud 5 sur l’instance 1 pour l’index 0 du COMCLASS 38”.
Ce n’est donc pas une info “stockée côté device” et qui ne permet pas de “réagir à un déclencheur”, mais plutôt un ensemble de fonction pour rendre notre contrôleur générateur de scene (principe d’actions / trigger de Gladys mais niveau ZWave).

On en revient au problème que je ne suis pas capable de recevoir la Notification de Scene côté ZWave/NodeJS pour pouvoir l’envoyer dans Gladys et ainsi entrer dans les mécaniques “classiques” de Gladys (value changed et possibilités de trigger, de lancer des actions etc etc).

Ce qui me dérange, c’est que, d’après la doc Node OZW, c’est le handler scene event qui devrait me permettre de recevoir cette information de scene… mais comme dit, j’ai mis tous les handlers avec des console.log dans chacun d’eux : je ne vois rien passer…

Bref, j’avance… des infos en vrac certes, mais je pense que j’y vois de plus en plus clair… Mais il y a encore quelques recherches à faire et notamment sur le fait que l’event de scene ne soit pas reçu côté NodeJS ! :slight_smile:

Je continuerai le récit de mes découvertes ici ! (en fait même si tout le monde s’en fout, ça me permet d’avoir un historique de réflexion et découvertes :smile: )

Merci pour toute aide,


#8

Salut @Bleys !
je suis de près ton récit, crois moi il y a des gens qui te lise :wink:

J’ai une wallmote d’aeotec qui fonctionne je pense de la même manière que ta Hank 4-key. Les actions sur les boutons peuvent être associées à d’autre objet zwave. J’ai configuré ma wallmote avec Jeedom; à titre d’exemple je contrôle des Fibaro 212 avec celle-ci. L’information ne passe pas par Jeedom, il m’a juste servi pour la configuration. Je n’ai pas regardé si Jeedom gère les scènes, peut-être que ca peut aider à comprendre comment faire, il me semble que le plugin zwave se base aussi sur Open Zwave.


#9

Salut,

Effectivement, de mes lectures et tests, c’est ce que j’ai compris du fonctionnement “de base” de ce type de devices. Mais aujourd’hui, Gladys ne gère pas (encore ?)la notion d’association (ce que tu as fait avec Jeedom). Mais, comme je l’ai montré dans mon précédent message, c’est gérable (OZW offre toutes les méthodes pour récupérer le nombre d’associations, lister les associations etc) : faut le coder pour intégrer ça avec l’interface maintenant :slight_smile: (pour me plonger dans le code de Gladys je me pencherai certainement sur cette évolution en proposant une PR à Mathieu sur son module ZWave).

Cela dit, j’aimerais aller un peu plus loin dans l’intégration et que Gladys ne serve pas uniquement de “configurateur”. J’aimerais vraiment avoir la possibilité que toutes les infos de la télécommande soient envoyées à Gladys pour que lui puisse prendre des décisions (envoyer une notification par exemple et outre-passer également les limites du nombre d’associations) et peut-être même gérer des scénarios plus poussés. Ce que je veux dire sur ce dernier point c’est, d’après la doc OZW, l’association d’une télécommande avec un autre noeud (ton Aeotec avec tes Fibaro 212 par exemple) ne permet pas de configurer la valeur à définir lors de l’utilisation de la télécommande. Exemple : supposons un Dimmer, avec un appui, via Gladys on pourrait envisager une demande d’allumage à 25 ou 30 ou 50% d’une lumière en fonction de l’heure de la journée. Chose que aujourd’hui, je pense que tu ne peux pas faire avec une association télécommande<=>device en direct.

Je n’ai pas eu l’occasion de me repencher sur ce point dernièrement. Dès que je peux, je m’y remets et je posterai mes découvertes ici puisque je ne suis pas seul :wink:

Merci pour les infos !


#10

C’est super si tu peux proposer une PR pour gérer les associations, ça m’éviterais de passer par Jeedom pour ça :wink:
Mais alors c’est encore plus généralissime si tu arrives à récupérer depuis Gladys les infos envoyées par la télécommande pour qu’on puisse lancer des scénarios !!! Car le zwave en association directe c’est bien, c’est rapide, et si la box domotique plante tu n’es pas pénalisé, mais impossible de communiquer avec un autre protocole et donc de jouer avec des équipements non zwave.

Bon courage pour les recherches et le dev. Je n’ai pas assez de connaissance pour t’aider mais si tu as besoin d’un testeur je suis là.


#11

[Poste Obsolète… voir post suivant…]


Salut,

J’ai passé pas mal de temps ce soir à essayer de comprendre tout ceci et essayer de faire en sorte de gérer le scénario décrit dans mon précédent post (recevoir les notifications côté Gladys dans le cas d’un device de type Scene Controller).

En version courte : j’ai trouvé un moyen de faire fonctionner tout ceci :partying_face:… mais il y a un “mais”.

Dans les détails :
je me suis plongé dans le code de OpenZwave à proprement parler (le code C++ pas le wrapper NodeJS). Sans entrer dans des détails inutiles, j’en suis arrivé à cet issue sur le repo : #1125 : Central Scene Support qui est une version updaté du #1124 qui est lui même une version updaté du #993 qui date du, accrochez-vous bien 27 Septembre 2016… Ça part mal… Les dernières activités date d’octobre 2018… je vous laisse imaginer ce que cela veut dire :slight_smile:

En résumé de cette longue discussion. Le point d’entré est un utilisateur qui propose un patch pour correctement gérer les scènes dans cette implémentation Zwave. Oui, le point de départ est là : la version de OpenZwave est bugguée et ne sait pas correctement gérer les Scenes. Pour autant, un développeur propose un patch. Ce patch a été implémenté dans différents fork de OpenZwave dont Domoticz (si je me souviens bien de ma lecture).

Le 1er Mai 2017, l’équipe qui maintient le repo OpenZwave a finalement appliqué ce patch sur leur repo… sur sa branche de Développement. Le commit est visible ici. Et c’est là tout le problème : il s’agit d’un correctif non déployé sur la branche master. En effet, le module ZWave Gladys recommande d’installer OpenZwave en se basant sur la branche master (ce n’est pas un blâme, c’est juste un simple constat, expliquant la situation, ni voyez aucune attaque). En se penchant un peu sur ce repo, on se rend compte que malheureusement, le code à proprement parler de la version master bouge très peu : excepté 1 commit, globalement, les derniers fix de code datent d’au moins il y a plus de 7 mois. La branche Dev semble légèrement plus active. Son gros inconvénient : c’est que c’est une branche de Dev, donc potentiellement instable…

J’ai tenté l’expérience de prendre la branche de dev, compiler et installer cette version sur mon RPi. Cela n’a pas fonctionné du premier coup. J’ai dû modifier le fichier config XML propre à mon device (cas à la marge qui ne concerne donc que le Hank 4-Key Scene Controller) pour qu’au final enfin, les valeurs soient envoyées au code JS (donc pouvant être transmis à Gladys). Petit bémol, ce n’est pas le handler scene event qui est déclenché, mais value changed.Ce fut un peu chaotique, mais l’essentiel est d’y être arrivé ! (avec la fatigue et en rédigeant ce post, j’ai un petit doute sur la nécessité de modification de ce fichier XML… ou bien carrément du patch en fait… je referai une passe de test en m’assurant de bien désassocier et l’état du repo que j’utilise… j’ai un doute après coup…).

Mais alors que faire ? Et là, ça va plus être peut-être à @MathieuA et/ou @pierre-gilles de décider :

  • Solution 1 : tant pis pour toi Steph’, si OpenZwave gère pas correctement, on peut rien faire d’autre, c’est pas le problème de Gladys… Tu te débrouilles avec les groupes en envoyant toutes les infos d’appui à ton contrôleur sans passer par la notion de Scene (finalement ça doit pouvoir marcher… j’ai peut-être un doute sur du coup la simplicité de définir des actions d’un point de vu interface…)
  • Solution 2 : on prend le risque ! On modifie les instructions d’installation du module ZWave Gladys pour ajouter, après le git clone, un git checkout sur la branche Dev (voire même sur un commit précis ?). Le risque : c’est que ça reste une version de dev’…
  • Solution 3 : on fork OpenZwave sous le repo Gladys en appliquant ce patch, et le module ZWave Gladys se base sur ce repo dans la procédure d’installation. L’avantage c’est que la version de OpenZwave est connue, maîtrisée, “testée”. L’inconvénient, c’est qu’il faut suivre le repo d’origine pour faire les mises à jour…
  • Solution 4 : on parie un peu sur l’avenir, et on se contente de modifier le script d’installation du module ZWave Gladys pour ajouter dynamiquement le patch dans la procédure d’installation (ça se fait en deux lignes bash en plus). C’est en gros ce que fait Domoticz à priori. L’avantage, c’est qu’on fait confiance à la branche master de OpenZwave. L’inconvénient, c’est que le jour où ils mergent Dev dans master, la procédure d’installation devra être mise à jour.
  • Solution 5 : je me suis raté sur mes tests, et la simple modif’ du fichier XML + désassociation du noeud + ré-association ça fonctionne (ce serait le mieux :slight_smile:)

Voilà un peu mes recherches et tests de la soirée.
Bien que la discussion puisse être ouverte sur ces 4 solutions, je préfère bien retester les différents cas et vous dire ce qu’il en est vraiment (en m’assurant de bien désassocier le noeud à chaque fois). En détails, voici ce que je prévois de tester (demain ?) :

  • Branche master, avec fichier XML d’origine : ça ça marche pas, c’est mon point de départ ;
  • Branche master, avec fichier XML modifié
  • Branche Dev sans fichier XML modifié
  • Branche Dev avec fichier XML modifié (ça ça marche c’est ma conf’ actuelle)
  • Modifier le patch OpenZwave pour que cela déclenche le handler scene event au lieu de value changed (ça c’est pur bonus, mais ça faciliterait l’intégration dans Gladys d’un point de vu interface)

Bref, un ou deux tests à bien reformaliser, et on pourra clairement aller de l’avant et avoir un plan d’action.

Au passage @link39 as-tu déjà constaté dans les logs OZW ce message d’erreur apparaître lors de l’appui sur un bouton de ton WallController (celui contenant No ValueID) ?

Merci !


#12

super boulot de recherche !!!
Le message dont tu parles ne me dit rien, je viens de faire un tour dans le fichier de log et je n’ai pas ce message quand j’appuie sur des boutons.


#13

Salut,

Les nouvelles sont bonnes : tout fonctionne sans trop de magouille.

Je suis revenu sur une version OpenZwave “master”. J’ai simplement dû modifier le fichier de configuration de mon device (dans /usr/local/etc/openzwave/hank/scenecontrolle4.xml) pour lui ajouter les infos suivantes :

 <CommandClass id="91" name="COMMAND_CLASS_CENTRAL_SCENE" version="1" request_flags="5" innif="true" scenecount="0">
    <Instance index="1" />
    <Value type="int" genre="system" instance="1" index="0" label="Scene Count" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
    <Value type="int" genre="system" instance="1" index="1" label="Button One" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
    <Value type="int" genre="system" instance="1" index="2" label="Button Two" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="1" />
    <Value type="int" genre="system" instance="1" index="3" label="Button Three" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="1" />
    <Value type="int" genre="system" instance="1" index="4" label="Button Four" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="1" />
    <Value type="int" genre="system" instance="1" index="5" label="Other" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />
</CommandClass>

et cela fonctionne. Mon erreur lors de la création de ce sujet c’est de ne pas avoir exclu le noeud du réseau après avoir fait la modif’ du fichier de configuration pour le ré-inclure ensuite. Je m’en souviendrai :slight_smile:

J’aurai beaucoup appris pour autant grâce à tout ceci. Quelques pistes possibles maintenant tout de même :

  1. Quidd dans la procédure d’installation du module ZWave sur Gladys de ne pas utiliser une version “connue” / “testée”. La procédure mentionne simplement (je résume) “faire un git clone et lance le make / make install”. Le risque, c’est que le projet Open-ZWave bouge / évolue (bien que son activité soit assez limitée) et apporte des changements non rétro-compatibles. A l’inverse, “figer une version”, veut dire suivre le projet pour régulièrement augmenter cette dernière… c’est à @MathieuA de plus trancher sur ce point je pense… rien de grave en soit. C’est juste que sur deux installations, malgré la même procédure, on ne peut pas s’assurer d’avoir le même “code”.
  2. La version actuelle du module ZWave de @MathieuA ne transmet l’information d’un value changed que si le type de value n’est ni system ni config. Or, dans ce cas-là je reçois une value system. Voici dans des logs custom du module en question ce que je reçois { value_id: '10-91-1-1',\n node_id: 10,\n class_id: 91,\n type: 'int',\n genre: 'system',\n instance: 1,\n index: 1,\n label: 'Button One',\n units: '',\n help: '',\n read_only: true,\n write_only: false,\n min: -2147483648,\n max: 2147483647,\n is_polled: false,\n value: 0 }. Plusieurs choses ici :
    • Ce contrôle de “genre” de value qui bloque et n’envoie pas l’info à Gladys. Je n’ai pas assez de recul sur pourquoi cette contrainte (@MathieuA saurait préciser je pense)
    • L’identifier qui nécessite 4 “valeurs” contre 3 utilisées aujourd’hui
    • A l’ajout du node, les devicetype 91 n’ont pas été ajoutés dans la base de Gladys

      Concrètement donc, le module ZWave doit évoluer pour pouvoir gérer la notion de scene. Je pense pouvoir me lancer dans ces dev’, mais d’abord, je pense traiter le point suivant (@MathieuA je suis ouvert à discussion sur tout ceci… n’hésite pas à me dire si je me trompe, si je m’enflamme ou si tu vois très bien de quoi je parle et que du coup tu peux le prendre à charge beaucoup plus rapidement que moi le temps que je me plonge dans tout ça)
  3. Il est possible d’ajouter dans Gladys la fonctionnalité de gestion des associations pour les devices de type Scene Controller. Je vais tenter de me lancer dans ces dev’ là sur ton projet @MathieuA si tu le veux bien. J’ouvrirai une PR pour voir les modif’ / évol’ au fil de l’eau. Je ne me suis pas encore penché sur le modèle de Gladys ou le principe d’association à proprement parler côté ZWave, j’ai encore quelques inconnues. Une fois dans le code ça devrait aller mieux, sinon, je referai appel à vous :slight_smile: (directement sur Github pour le coup, car là c’est purement technique maintenant)
  4. Je vais ouvrir une PR chez OpenZWave pour modifier le fichier de config’ pour ne pas avoir à faire le hackdu fichier de config à la mano dans le cas de mon device

Merci pour ton retour !

Comme dit plus haut, pour le moment (en tout cas si ta télécommande a le même fonctionne que la mienne), tu ne peux effectivement pas recevoir les événements d’appui (sauf si tu as associé ton controlleur sur tous les groupes de ton device : ça peut être une “solution”). Pour autant, je suis preneur des logs lorsque tu appuies sur tes boutons. Idéalement, il faudrait ceux de Gladys (via pm2 log) et ceux de OZW (via un tail -f api/hooks/zwave/node_modules/openzwave-shared/OZW_Log.txt).

Voici par exemple ce que je vois :

#### Fichier OZW_Log.txt
2019-02-13 23:12:49.456 Detail, Node010,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x0a, 0x05, 0x5b, 0x03, 0x1a, 0x00, 0x01, 0xcf, 0x00, 0x75
2019-02-13 23:12:49.456 Detail, 
2019-02-13 23:12:49.456 Info, Node010, Received Central Scene set from node 10: scene id=1 in 0 seconds. Sending event notification.
2019-02-13 23:12:49.456 Detail, Node010, Refreshed Value: old value=0, new value=0, type=int
2019-02-13 23:12:49.456 Detail, Node010, Changes to this value are not verified
2019-02-13 23:12:49.457 Detail, Node010, Notification: ValueChanged
#### Logs Gladys
0|app      | value changed 10 91 "{ 
  value_id: '10-91-1-1',
  node_id: 10,
  class_id: 91,
  type: 'int',
  genre: 'system',
  instance: 1,
  index: 1,
  label: 'Button One',
  units: '',
  help: '',
  read_only: true,
  write_only: false,
  min: -2147483648,
  max: 2147483647,
  is_polled: false,
  value: 0 }"

Théoriquement tu ne devrais rien voir côté Gladys. J’ai ce log car j’ai modifié le plugin de Mathieu pour ajouter un log supplémentaire à chaque value changed. Mais ça serait bon signe car ça voudrait bien dire que le problème est clairement identifié et qu’il n’y a plus qu’à :slight_smile:

Voilà tout !

Merci


#14

Salut @Bleys,

Effectivement je n’ai rien vu passer côté Gladys hier à l’appuie sur les boutons. Côté logs OZW j’avais le même genre de messages que toi. Je te partage mes logs ce soir en rentrant.

Edit : les logs ci-dessous

Bouton 1 associé à un fibaro dimmer 212

2019-02-14 18:10:07.259 Detail, Node014, Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x0e, 0x05, 0x5b, 0x03, 0x53, 0x00, 0x01, 0xf1
2019-02-14 18:10:07.260 Detail,
2019-02-14 18:10:07.260 Info, Node014, ApplicationCommandHandler - Unhandled Command Class 0x5b
2019-02-14 18:10:07.348 Detail, Node003, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x03, 0x03, 0x25, 0x03, 0xff, 0x2b
2019-02-14 18:10:07.348 Detail,
2019-02-14 18:10:07.348 Info, Node003, Received SwitchBinary report from node 3: level=On
2019-02-14 18:10:07.349 Detail, Node003, Refreshed Value: old value=false, new value=true, type=bool
2019-02-14 18:10:07.349 Detail, Node003, Changes to this value are not verified
2019-02-14 18:10:07.349 Detail, Node003, Notification: ValueChanged

Bouton 3 non associé :

2019-02-14 18:11:46.772 Detail, Node014,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x0e, 0x05, 0x5b, 0x03, 0x54, 0x00, 0x03, 0xf4
2019-02-14 18:11:46.773 Detail,
2019-02-14 18:11:46.773 Info, Node014, ApplicationCommandHandler - Unhandled Command Class 0x5b

#15

Salut @Bleys et bravo pour ta recherche détaillée!

On est au courant de ce sujet depuis pas mal de temps avec @MathieuA, moi j’avais tenté d’utiliser un bouton Fibaro ( le fameux gros bouton bleu ), il y a 2 ans peut-être, et la PR était effectivement créée, à l’époque j’avais l’impression qu’ils allaient la merger rapidement donc j’étais en standby mais comme tu l’as remarqué ça n’a pas beaucoup avancé.

Mon avis là dessus: Proposer d’installer une version de dev, c’est risqué: on ne sait pas ce qu’ils mettent sur dev, si du jour au lendemain ils mergent une PR “cassante” et qu’au même moment quelqu’un install open-zwave avec Gladys, on est marron on ne sait pas ce que ça va donner.

En revanche, il faut être pragmatique: la version actuelle de open-zwave n’avance pas beaucoup, et les autres projets domotique ont tous fait du custom pour que le sujet avance.

Dans Gladys 4 (qui est en cours de développement), le module Zwave sera intégré au core, et je compte distribuer Gladys via Docker (même sur Raspberry Pi), donc on installera OpenZwave dans l’image Docker. Cela veut dire que ce n’est plus à l’utilisateur d’installer open-zwave, c’est à nous. Donc on peut tout à fait installer des versions de dev, du moment qu’on ajoute suffisamment de testing pour être sur qu’on envoie pas une image pétée :slight_smile:

La raison à cela est très simple: Le Z-wave envoie différents types de valeurs: des config/system (quand par exemple tu changes les paramètres de ton noeud Zwave), et des valeurs qui sont des changements d’états de tes capteurs/actionneurs. A l’époque, on enregistrerait tout dans Gladys, mais ça créait des tonnes de données inutiles car cela enregistrait des DeviceStates pour les configs, ce qui est inutile.

On avait donc décidé avec Mathieu de n’enregistrer que les changements d’états et pas les changements de configuration.

Dans ton cas, je pense qu’il faut juste que tu adapte le XML!

<Value type="int" genre="system" instance="1" index="1" label="Button One" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0" />

Change genre="system" par genre="user", ça devrait marcher je pense… (dis moi)

Je suis allé voir la doc de la lib qu’on utilise, et visiblement ça n’a pas l’air si compliqué! Quand tu lis cette partie

Il y a l’air d’avoir tout le matos pour gérer les scènes :slight_smile:

Quand à la gestion des associations, il y a tout pour aussi (voir API doc)

zwave.getNumGroups(nodeid);
zwave.getGroupLabel(nodeid, group);
zwave.getAssociations(nodeid, group);
zwave.getMaxAssociations(nodeid, group);
zwave.addAssociation(nodeid, group, target_nodeid);
zwave.removeAssociation(nodeid, group, target_nodeid);

#16

Maintenant niveau développement:

1/ Tente de faire la modification du XML et dis moi ce que ça donne :slight_smile:

2/ Si tu te sens de développer la gestion des associations/scène, n’hésite pas à le faire sur le module actuel, de toute façon ça partira dans Gladys 4 derrière donc ce n’est pas du travail perdu. C’est l’occasion de voir si la dépendance qu’on utilise fonctionne bien avec les associations, ça nous donne un peu d’expérience sur le sujet. Je serais ravi de suivre ce développement et de t’aider là dessus.


#17

Bonjour,

Malheureusement, ce type de log se produit en fait quand ton contrôleur ne “reconnaît pas” ton device sur le réseau ZWave. J’imagine que ta télécommande fonctionne un peu comme celle que j’ai et se met en mode “sleep” automatiquement. Sur un reboot (start/stop de Gladys, coupure de courant ou autre), à son lancement le contrôleur ne trouve pas la télécommande et ne l’enregistre pas dans son registre des devices actifs. Tout appui sur un bouton donne alors ce message de ApplicationCommandHandler Unhandled (enfin… de ce que j’ai vu de tous mes tests). Pour autant tes actions fonctionnent car tu as associé directement ta télécommande à d’autres devices (via les associations ; et ton contrôleur n’a plus besoin “d’être là” pour que tout fonctionne). Ne t’embêtes pas plus, tu m’as déjà bien aidé. Je ferai quelques tests supplémentaires de mon côté et on verra ensuite (je suis étonné sur ma télécommande que l’association 1 ne transmette pas toutes les infos à mon contrôleur ZWave…). Merci encore pour ton aide !

Je savais qu’il fallait que je m’attarde un peu plus sur ce XML. Je regarde ça ce soir ! Bien vu & merci !

Je vais revérifier cette partie. Je suis également surpris de base que, en ayant pourtant associé mon device à mon contrôleur, je ne reçoive rien d’intéressant. Je vais rejeter un oeil à tout ça ce soir.

J’ai, en mode quick and dirty non intégré dans Gladys, testé les fonctionnalités d’association : ça semble fonctionner comme attendu. Je me remets sur ce sujet ce soir avec quelques nouveaux tests et je me lancerai sur cette PR ensuite pas de soucis.

J’vous tiens informé !