Salut à tous,
Quelqu’un sait-il comment créer une scène basé sur le retour d’un bouton poussoir ?
L’interface m’affiche bien les bonnes valeurs, mais dans les scènes je ne sais pas comment faire.
J’ai essayé :
Rien n’y fait !
Dans les logs Gladys, il est indiqué conditionVerified = false. C’est explicite !
Cette scène fonctionne chez moi avec un bouton xiaomi:
Par contre sur le dashboard je n’i pas comme toi, la valeur de mon bouton est une valeur entière:
Quel est le modèle de ton bouton ?
Peut-il faire des appuis long, simples ou doubles ?
Le mien est un WXKG06LM.
Oui je peux!
c’est le switch xiaomi aquara
@lmilcent c’est un bouton de quelle intégration ?
Si c’est l’intégration Zigbee2mqtt, encore une fois tout dépend de ce qui a été modifié dans cette PR…
C’est effectivement du zigbee, avec une feature button.
En fait il faudrait décrire comment Gladys réagit avec les différentes features pour éviter de poser à chaque fois la question (C’est peut être déjà fait ?).
Par exemple, de type switch → un bouton On / Off est proposé, et c’est détecté comme une prise.
Dans mon cas c’est de type button et les valeurs renvoyées sont cohérentes. Mais dans une scène je ne vois pas comment l’utiliser.
Dans le service Xiaomi, les valeurs litérales des boutons sont traduites en valeurs numériques.
const SWITCH_STATUS = {
NO_CLICK: 0,
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
};
Peut-être qu’il faut que je fasse la même chose dans le service Zigbee 
Par contre, il y a plein de types de button…
Mince, je pensais que c’était Gladys Core qui s’occupait de ça, basé sur les features.
C’est plus logique non ?
Surtout je me dis que ça évitera qu’un service interprète différemment un bouton par rapport à un autre, pour garder une cohérence et donc une certaine simplicité peu importe le protocole.
Dans mon cas, il y a :
Ce que je ne comprends pas, c’est que ces périphériques émettent des évènements et pas des valeurs.
Pour un thermomètre, la valeur est mise à jour à chaque fois qu’elle change.
Pour un bouton, si tu appuies dessus (en clic simple par exemple), on pourrait mettre à jour la valeur en 1, mais juste après, elle devrait revenir à 0 (pour refléter l’état du bouton) ?
C’est bien Gladys core qui définit le format des features.
C’est l’objectif dans la théorie 
On essaie au maximum d’avoir des formats de features partagées entre services (On/Off, couleur, luminosité, température, etc…)
Néanmoins dans la pratique, malheureusement parfois il est difficile de faire des généralités à partir de devices qui ont des spécificité très exotique. Dans l’exemple cité (Xiaomi), pour l’instant c’était le seul périphérique bouton avec plusieurs types de pressions (courte, longue, double, etc…), et du coup effectivement c’est le seul à implémenter ce genre de fonctionnement.
Maintenant qu’on a le cas dans 2 services, on peut réfléchir à voir ce qui se recoupe/recoupe pas
Il faut effectivement faire la même chose côté Zigbee (c’est le même bouton on est d’accord?)
Je pense que dans le cas d’un bouton il faut plus voir la valeur comme un événement plus qu’un état. C’est un évènement « le bouton a été pressé ».
Je vois peu d’intérêt de doubler chaque évènement d’un évènement qui remet l’état à 0 (« Le bouton n’a pas été pressé » ) … Tu en vois un ?
Edit: D’ailleurs, le NO_CLICK: 0, a été mis au début mais n’a pas été utilisé, je n’en vois pas l’intérêt. ça aurait du être retiré à la PR.
Je ne sais pas si c’est le cas actuellement, mais sur le dashboard mon bouton est bien affiché « single » puis quelques secondes plus tard « aucun evenement » (si je recharge la page)
Ça va être compliqué de gérer tous les cas.
Pour des périphériques comme celui-ci Xiaomi WS-USC02 control via MQTT | zigbee2mqtt.io ou celui-ci Xiaomi WXKG02LM_rev2 control via MQTT | zigbee2mqtt.io, on a :
@lmilcent Tu as essayé avec la valeur “single” dans les scènes ?
J’ai essayé oui, avec « 1 » et un seul appui court sur mon bouton.
@cicoub13 A mon avis il faut revoir le truc, il faut que ce genre de bouton soit géré nativement et fonctionne out of the box dans les scènes 
Tout comme on adapte l’UI lorsqu’il s’agit d’un bouton binaire par exemple :
Il faut qu’on ait pareil pour ces boutons.
Je verrais bien un dropdown avec les différentes valeurs:
L’utilisateur n’a pas a deviner comment ça se passe c’est l’enfer sinon ^^
Idem pour les détecteur de présence / contact non ?
Il faudrait afficher fermé / ouvert et mouvement / aucun mouvement plutôt ?
Effectivement idem ! A part pour des valeurs numériques de comparaison (température > XX), l’utilisateur ne doit pas avoir à taper quoi que ce soit, ça n’a pas de sens
@cicoub13 j’ai vu que tu avais proposé la PR zigbee2mqtt, du coup ça se passe comment pour les périphériques de type bouton avec plusieurs types de pressions? Qu’est ce qui est envoyé par le service ? C’est le même format que le service Xiaomi ?
Je n’ai rien fait pour le moment.
Je peux intégrer les mêmes valeurs que le service Xiaomi. Mais ce serait bien d’uniformiser ça pour tous les services (dans les constants) et de faire un bouton (comme le On/Off) dans une autre PR.
Et comme je le disais, il y a des périphériques qui ont beaucoup plus de cas : boutons gauche/milieu/droit qui peuvent tous avoir des pressions courtes/doubles/longues. Faut-il gérer ça comme des features différentes (ça va être chaud pour zigbee 
) ?
Moi je verrais bien :
court, double, longComme ça c’est plus simple
Je suis d’accord il faut uniformiser. Les mêmes constantes que le service Xiaomi ça me semble bien! On peut mettre ça dans les constantes du projet effectivement.
Je pense qu’il faut faire du cas par cas pour les périphériques exotiques, tout n’est pas factorisable et à mon sens ce n’est pas souhaitable de faire de « l’hyper généralisation »
Donc oui, ça me choque pas si on a certains périphériques exotiques qui sont défini en tant que feature « à part » tant que ça reste cohérent avec Gladys en général, il faut penser l’usage. Par exemple si c’est pour contrôler une lumière, le on/off, la brightness, et la couleur c’est vitale que ce soit des features « natives/générales » de Gladys pour que Gladys puisse contrôler ces périphériques dans le chat, les scènes, et autres.
Quand c’est des boutons très très exotique spécifique à une seule intégration et qui ne sera jamais utilisé autre part, il faut penser de bout en bout comment ça va être utile dans Gladys et faire au mieux, sans nécessairement essayer de faire rentrer ça dans un moule et que ça soit inutilisable