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:
?
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).
ç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.
Ça résoud ta problématique ?
A priori ça peut la résoudre oui, mais j’ai 2 remarques :
Dans cette partie je ne sais absolument pas quoi marquer :
select
Même si ça fonctionne, j’avoue que c’est pas tellement intuitif d’après moi.
J’aurais plutot vu un fonctionnement ET :
SI simple clic ET lumière éteinte > Allumer lumière / prise
Ah ah, c’était l’objet d’un échange avec @pierre-gilles il n’y a pas longtemps justement 
Avant chaque « continuer si », il faut utiliser une brique « récupérer la dernière valeur ».
Ensuite tu sélectionnes ta lumière, et 1 = allumé, 0 = éteint.
D’accord j’ai réussi 
Par contre je pense qu’il faudrait être guidé lors de la création des scènes. Soit avec des explications détaillées en fonction de ce que l’on souhaite faire, soit des liens vers la doc si elle est faite.
Top !
Hésite pas à lister les points importants pour un nouveau venu, qu’on écrive la doc associée (ou toi, vu que c’est publique ).
Ok je vais voir si je peux aider à ce niveau là !
Merci pour ton retour!
Effectivement peut-être que la box « continuer seulement si » n’est pas assez explicite 
Il faudrait expliquer le flow dans la box tu as raison.
Pour le trigger, pour moi ça n’a pas de sens d’avoir des comparaisons multiple dans un trigger, car un trigger c’est un « évènement », pas un état.
Un évènement c’est « la température vient de changer de 6 à 8°C » par exemple.
Mais je suis d’accord que le flow général est peut-être pas explicite
Oui tu as raison. En fait en explicitant le flow, on peut absolument se passer de ce fameux ET
Je ne sais pas comment cela pourrait être géré, mais dans mon cerveau d’humain je vois les choses ainsi :
SI la lumière est éteinte ALORS le simple clic ALLUME la lumière
Donc en fait c’est dans l’ordre condition > trigger > action
Soit il faut pouvoir intégrer cet ordre là dans la création d’une scène (pas judicieux je pense car cela manquerait d’homogénéité au final), soit il faut trouver comment passer de :
condition > trigger > action
à
trigger > condition > action de manière simple et compréhensible même par les plus nuls comme moi. Ce qui implique à mon avis de réduire au maximum les étapes (le nombre d’actions).
Dans mon exemple ci dessous, j’aurais volontiers regroupé les étapes 1 et 2 en une seule !
Alors je me suis dit un truc un peu con, peut-être infaisable techniquement mais :
Serait-il possible de déterminer pour chaque scène quel équipements vont être sollicités. Du genre au début de la création de la scène.
Pour moi c’est Aqara Mini Switch et Aqara Bulb Light
Gladys récupère alors les derniers états automatiquement et systématiquement.
Je n’ai donc plus à me soucier de créer une action de récupération du dernier état pour chaque équipement.
Je peux donc faire :
Qu’en dites-vous ?
En fait l’idée derrière cette double étape, c’était d’avoir un moteur de scène très très puissant, et de pouvoir faire des comparaisons de valeur d’un même capteur dans le temps.
Un exemple:
Sauf qu’effectivement, ça implique de devoir faire une double étape même pour les cas très simple comme le tiens. Je suis d’accord c’est un peu lourd de toujours devoir demander l’état…
