Moi je verrais bien :
- Gladys gère les appuis de type
court,double,long - Les multi-boutons sont détectés comme un 3-en-1 (ou 2-en-1, bref)
Comme ç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
1 « J'aime »
OK partons sur ça 
1 « J'aime »
Ah bah bravo, moi qui pensais que ça bossait dur 
2 « J'aime »
Juste un petit retour, du coup l’issue a été fixée sur la PR Zigbee2mqtt?
@lmilcent tu as réussi à faire tes scènes? 
Non, jai deux problèmes :
1- mon interrupteur de cuisine est reconnu par Gladys comme une prise de courant.
2- mon interrupteur sans fil est toujours impossible à contrôler pour le moment, même si j’utilise 1 comme valeur par défaut
Je me souviens du problème : la feature “Switch” permet de contrôler la lumière depuis le dashboard avec un bouton.
Mais dans les scènes c’est reconnu comme une prise.
La feature “light” permet de contrôler dans les scènes pour allumer les lumières mais pas d’avoir le bouton sur le dashboard.
Quelle est la bonne feature a utiliser dans ce cas ?
Pas d’avoir le bouton sur le dashboard? Vous êtes sur que vous avez bien défini un feature type avec les caractéristiques suivantes:
- category: light
- type: binary
?
Toutes les autres intégrations qui gèrent des lampes (Philips Hue, MQTT, etc…) sont contrôlable aussi bien dans les scènes que sur le dashboard.
@cicoub13 je ne me souviens plus du fichier qui gère l’association, mais ça doit être ça l’erreur !
Au niveau des modèles il faudra aussi faire une vérification. Typiquement mon interrupteur est mal déclaré (Switch au lieu de light).
Je pense qu’on a déjà eu ce débat mais un interrupteur est un interrupteur On ne peut pas savoir qu’est-ce qu’il contrôle (une lampe ou autre chose).
Si on parle bien du modèle WXKG06LM, il est déclaré avec :
category: DEVICE_FEATURE_CATEGORIES.BUTTON,
type: DEVICE_FEATURE_TYPES.BUTTON.CLICK,
Je vais unifier le comportement pour les valeurs et proposer un UX plus simple dans les scènes.
C’est vraiment le cas pour ce modèle ?
Je suis d’accord que dans le cas d’une prise télécommandée ça peut être n’importe quoi derrière, mais dans ce cas là est ce que des gens utilisent ça pour autre chose qu’une lampe ?
Idéalement il faudrait pouvoir re catégoriser dans l’UI si c’est si tu estime que l’usage est si “varié” que ça.
Je suis du même avis que @cicoub13, un interrupteur devrait automatiquement proposer un bouton dédié dans l’interface, comme les switch.
Même s’il ne contrôle pas une lumière directement.
Pour l’instant, j’ai ajouté la gestion de la récupération de la valeur dans la PR Zigbee.
Au lieu d’avoir les valeurs single, double et long, l’état sera 1,2 ou 5.
Ce qui te permet de les utiliser dans les scènes 
@lmilcent Est-ce que tu peux tester la nouvelle image ?
Comme dit précédemment, je veux bien travailler sur l’UX et proposer un bouton plus facile à utiliser dans les scènes (et pour l’affichage dans les box) + uniformiser entre le service Xiaomi et Zigbee2Mqtt (seuls services utilisant ce type de device button).
Mais je pense que c’est mieux de faire ça dans une autre PR et surtout, j’aimerais partager des spécifications ici avant de me lancer 
Pour ajouter une feature Lumière à la place d’un bouton, cela me semble trop complexe pour le moment. Il faudrait que je conserve le type réel Zigbee et le type Gladys de chaque feature pour pouvoir convertir les valeurs ET émettre des actions vers Zigbee (ce qui est impossible pour ces devices).
1 « J'aime »
ça fonctionne nickel !!
Pourquoi 1,2 ou 5 ?
Il me semblait qu’on voulait comme au niveau du Xiaomi ?
const SWITCH_STATUS = {
NO_CLICK: 0,
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
};
Je suis d’accord! Je pense c’est une autre PR et effectivement il faut en discuter !
J’ai supprimé le NO_CLICK (qui n’avait pas de sens) et l’interrupteur WXKG06LM envoie un évènement hold dans Zigbee (équivalent à un LONG_CLICK). Il ne gère pas l’appui (press) et le relâchement de l’appui (release)
J’ai donc gardé les valeurs 3 et 4 pour ne pas casser le service Xiaomi (cas d’autres interrupteurs) et j’ai :
const BUTTON_STATUS = {
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
LONG_CLICK: 5,
};
Est-ce que ces derniers developpements peuvent répondre à ma problématique ?
Je souhaite utiliser mon switch Aqara pour allumer / éteindre une ampoule avec un clic simple.
Je crée une scène du type
Declencheur : changement d'état > switch = 1
Action : allumer lumière (reconnue comme un interrupteur pour le moment )
J’arrive donc à allumer ma lumière avec un simple clic… mais je ne peux pas utiliser un simple clic pour éteindre , ou alors j’ai pas compris.
J’ai un bouton Aqara et une prise connectée.
- scène 1 : si simple clic, continuer si c’est éteint, allumer la prise.
- scène 2 : si simple clic, continuier si cest allumer, éteindre.
Ça résoud ta problématique ?