Bonjour à tous (et toutes, s’il en existe)
j’ai fait l’acquisition d’un bouton SNZB-01 de Sonoff. Il est censé répondre au clic simple, au double-clic et au clic long.
Mais je ne vois pas comment tirer parti du clic long, car les valeurs que rend le bouton sont “1” pour clic unique, “2” pour double-clic, et “long” pour clic long (ce sont les valeurs que je vois apparaître sur la page qui affiche le tableau de bord).
Il me semble que les états des boutons dans les scènes ne peuvent être que des valeurs numériques [quand j’inscris “long”, la sauvegarde de scène est refusée, et toute autre valeur numérique autre que 1 et 2 est sans effet].
Alors comment faire comprendre à Gladys que “long” est une valeur numérique ?
Merci d’avance !
JPL
TL;DR
Gladys ne supporte pas encore le clic long à ma connaissance.
Explications
Gladys est encore relativement jeune et certaines fonctionnalités supportées dans les services utilisés ne le sont pas dans le cœur de Gladys. Dans ton cas, le service Zigbee (qui est une intégration avec le projet Zigbee2MQTT) permet de supporter énormément de périphériques différents, dont certains disposent de fonctionnalités pas encore prises en charge.
Notamment les clic long, les caractéristiques particulières à quelques équipements, les têtes thermostatiques de chauffage, etc.
Je crois que @cicoub13 avait proposé d’ajouter “3” pour le clic long dans un premier temps, mais qu’il fallait réellement réfléchir à une solution plus pérenne (et compréhensible?).
Yes mais il me semble qu’on avait décidé!
Bonjour,
merci pour vos réponses.
Une première question : à quoi physiquement pour le bouton correspond l’événement LONG_CLICK ?
Seconde question : je crois comprendre que les 3 fonctions du bouton Xiaomi WXKG06LM sont traitées par Gladys dès à présent ; est-ce valable aussi pour le Sonoff dorénavant, ou le sera-ce plus tard dans une prochaine mise à jour (quand ?).
Merci encore, bonne journée,
JPL
Là dessus je pense le manuel du fabricant sera plus clair que moi, je n’ai pas ce périphérique 
De ce que je viens de tester, Gladys gère le « click », « double-click » et « long_press », mais pas les autres.
Seul toi peut nous le dire vu que tu as le bouton chez toi 
Si il manque des choses, tu peux discuter avec les développeurs de cette intégration sur le forum ( tous les gens qui sont dans cette discussion: Zigbee2mqtt - Debug )
Concernant une date, on ne parle pas trop de date en général, Gladys est un projet communautaire gratuit géré par des bénévoles, donc ça dépend en général de la disponibilité des gens
Sachant que tout le monde n’a pas les appareils des autres, en général la meilleure façon d’apporter des compatibilités est de contribuer soit-même !
Dans le cas ici, il faudrait isoler tous les clés que renvoie ce capteur Sonoff, et les ajouter aux fichiers de constantes de l’intégration Zigbee2mqtt dans une PR. Idéalement, il faudrait adapter l’UI pour éviter d’afficher « 1 », « 2 », mais plutôt des mots traduits
Je confirme ce que j’ai écrit pour démarrer cette discussion.
1 - La notice du “wireless switch” SNZB-01 (dénomination chez Sonoff) est très succincte ; elle ne mentionne que clic-simple, double-clic et appui long (au moins 3 secondes de pression continue). Je suppose sans grand risque de me tromper que c’est ce dernier qui génère l’évènement LONG_CLICK.
Les LONG_CLICK_PRESS et LONG_CLICK_RELEASE ne sont peut-être pas générés (du tout, ou de façon exploitable) par le bouton.
2 - Or Gladys détecte bien les 3 événements attendus (1 clic, 2 clics, et clic-long), puisque la page de tableau de bord les affiche quand ils se produisent (résultats, respectivement : “1”, “2” et “long” [sans les guillemets, bien sûr]).
3 - Mais Gladys ne sait pas traiter le clic-long dans une scène, parce que le résultat semble ne pas être numérique (si j’en juge par la chaîne de caractères que le tableau de bord affiche, et par les tests numériques que j’ai essayés [<1, >2] pour définir ma scène). Dans une scène, on teste obligatoirement une valeur numérique (la const BUTTON_STATUS), et Gladys ne l’obtient pas lors d’un clic-long.
Je serais heureux de contribuer à Gladys en apportant quelques éléments, dans la mesure de mes faibles compétences (déjà, PR et UI ne signifient pas grand chose pour moi …).
JPL
Ok, donc effectivement il manque ces valeurs dans la constante côté Gladys.
Génial ! Tout s’apprend
Une PR c’est une « Pull Request », c’est une demande de modification de code. Dans le projet nous utilisons Github pour héberger le code, et c’est là bas que n’importe qui peut proposer des modifications de code dans Gladys, pour ajouter une nouvelle fonctionnalité, pour corriger un bug, etc…
Bien entendu, n’importe qui ne peut pas apporter ces changements directement sans approbation, toute « PR » passe par une review faite par des membres de la communauté.
Lors de la review, on peut demander des changements (style de code pas bon, changements dans l’interface, etc…), ou approuver directement si le code parait bon, et le code sera intégré à Gladys.
Pour en savoir plus sur les PR:
Le repo Gladys:
Je viens de m’inscrire sur Github (username : JPLalv), mais je n’ai pas su comment formuler une PR pour Gladys.
Mais peu importe, dans atrovato [Fix & clean NaN device state , j’ai trouvé ceci :
// Case for Button devices
case 'click': {
switch (value) {
case 'single':
result = BUTTON_STATUS.CLICK;
break;
case 'double':
result = BUTTON_STATUS.DOUBLE_CLICK;
break;
case 'hold':
result = BUTTON_STATUS.LONG_CLICK;
break;
default:
result = value;
}
break;
Le bouton Sonoff SNZH-01 envoie “single”, “double” et “long”.
Le module ci-dessus exploite “single”, “double” et “hold”
Ceci explique-t-il cela ?
Ce que je ferais : conserver le traitement de “hold”, puisqu’apparemment certains boutons envoient ce code, et ajouter le traitement de “long” avec le même résultat.
Je ne connais pas javascript, mais j’ajouterais quelque chose comme :
case ‘long’:
result = BUTTON_STATUS.LONG_CLICK;
J’ai bon 
?
JPL
Oui c’est ça, avec le break en plus.
En fait tu peux cloner les 3 lignes du hold et les modifier !
Merci lmilcent.
tu peux le faire à ma place ? Merci d’avance.
Maintenant, ma question précédente revient : quand sera-ce effectif dans Gladys, (faut-il attendre une nouvelle version) ? Ce n’est qu’une question ; ne pas y voir une volonté de ma part de titiller ceux qui y travaillent, et dont j’admire la production !.
En fait, j’aimerais bien que mon bouton Sonoff fonctionne complètement, ce qui pourra aussi servir à d’autres que moi : le dit bouton est encore en solde chez Domadoo à 8,93 €.
JPL
Pour moi c’est ça le code :
// Case for Button devices
case 'click': {
switch (value) {
case 'single':
result = BUTTON_STATUS.CLICK;
break;
case 'double':
result = BUTTON_STATUS.DOUBLE_CLICK;
break;
case 'hold':
result = BUTTON_STATUS.LONG_CLICK;
break;
case 'long':
result = BUTTON_STATUS.LONG_CLICK;
break;
default:
result = value;
}
break;
C’est fait
Pour le faire, voici comment je m’y suis pris (pour info) :
- Chercher le fichier que tu mentionnais
- Sélectionner la branche « master » pour ce fichier
- Cliquer sur « modifier le fichier »
- Faire la modification et valider
- Compléter la pull request automatiquement préremplie
- Valider et attendre qu’un développeur Gladys approuve la modification
C’est à chaque nouvelle version que ces modifications sont prises en comptes. Sachant qu’en moyenne il y a eu une mise à jour toutes les 2 semaines cette année je crois, ça peut rapidement être déployé
Un grand merci pour ton aide et tes explications.
Peut-être qu’à l’avenir, si le cas se produit, je serai capable de me débrouiller seul dans Github.
Quant à Javascript, je n’ai plus qu’à m’y plonger.
1 « J'aime »
Merci à tous les deux, beau travail d’équipe !
En revanche pour que cette PR soit intégrée, il manque 2 choses:
-
Des tests unitaires: Gladys 4 est stable sur le long terme justement parce qu’on test tout, c’est hyper important. Là ta PR ne passe pas parce que justement le code coverage n’est pas bon (pas de test écrits).
-
Des tests “réels”: Dans Gladys 4 on test pas en prod, on fait des tests réels avant merge. Pour cela il faut faire un build Docker de ta branche, build qui peut-être ensuite testé par quelqu’un qui a du matériel
Normalement quand tu créé une PR il y a une checklist qui est pré-remplie et qui doit être remplie avant merge, là j’ai l’impression que tu l’as retirée?
Exemple:
Oui je confirme, c’était bien présent. Vu la modification, de nouveaux tests ne devraient pas être nécessaires, on peut se reposer sur les tests actuels non ?
J’ai fait la modification depuis mon boulot, donc depuis l’interface web de GitHub et effectivement je n’ai pas testé le tout en local. C’est d’ailleurs pour ça que je n’ai pas laissé la liste, n’ayant pas passé tous les tests.
Oui mais du coup on n’a pas la checklist qui permet d’attester que tout est bon sur cette PR.
Et non, là dessus on est très strict, si il y a du nouveau code, il doit y avoir des nouveaux tests pour vérifier que le code fonctionne et fonctionnera dans le futur.
Si tu n’écris pas de test, potentiellement dans 4 mois quelqu’un retire la ligne, et ça posera aucun souci vu qu’il n’y a pas de test, et celui qui remarquera que ça ne fonctionne plus, c’est l’utilisateur final.
Dans Gladys 4 justement on essaie d’être rigoureux, c’est pas à l’utilisateur final de se rendre compte que Gladys est cassée à chaque nouvelle version, c’est nos process en place qui vérifient que le logiciel fait ce qu’on veut, maintenant et dans les 10 prochaines années
D’ailleurs tout ça c’est pas moi qui le vérifie, c’est l’intégration continue qui vérifie que chaque ligne écrite est bien couverte, via notre outil de code coverage.
Ta PR apparait comme « non valide » et le merge est bloquée:
1 « J'aime »
Ok c’est bien compris, je fais ça dès que possible 
1 « J'aime »
Génial ! Je ping @cicoub13 qui avait travaillé sur ces boutons clics, je voudrais être sûr que les valeurs choisies ici pour “long” sont bien les bonnes.
Est-ce que c’est normal de prendre la même valeur pour “hold” et “long” ? On veut pas différencier ces évènements ?
Je pense que c’est la même chose, mais deux constructeurs différents. @cicoub13 pourra peut être le confirmer ?
Le bouton Sonoff envoie “long”. Il ne peut pas envoyer LONG_CLICK_PRESS ni LONG_CLICK_RELEASE . Je ne vois personnellement aucun inconvénient à ce que la valeur prise par Button_status soit 5 lors d’un appui de longue durée.
Quels sont les boutons (marques ?) qui envoient long_click_press et long_click_release ?
Ces deux évènements me paraissent bizarres…