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 :
- trigger : changement d’état : bouton simple clic
- action : continuer seulement si > lumière éteinte/allumée
- action : allumer / éteindre la lumière
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:
- Récupérer la valeur du capteur A (variable A.1)
- Attendre 10 minutes
- Récupérer la valeur du capteur A (Variable A.3)
- Si A.3 > A.1 ALORS dire « la température augmente »
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…
C’est plus simple si on a 20+ capteurs de lister seulement ceux qu’on souhaite récupérer … et plus long à faire quand on veut comparer plus de 5 capteurs.
J’ai certaines scènes où je veux récupérer la batterie de tous mes capteurs, c’est très, très long à faire !
Il y avait une proposition pour utiliser et afficher les anciennes valeurs des capteurs dans les scènes et le dashboard déjà ?
1 « J'aime »
Je comprends l’idée et en effet ça permet des choses bien plus puissantes.
Peut-être que des libellés ou boxes plus détaillées aideraient à avancer dans la création d’une scène.
Par exemple je trouverai plus judicieux de lire : “Récupérer l’état actuel” que le “dernier état”. Ce sont de petits détails mais c’est dans les détails que tout se joue je pense 
En fait pour moi ça ne me change pas la vie, j’aime bien tester / bidouiller… mais je pense à l’utilisateur qui ne veut pas se prendre la tête et utiliser un outil prêt à l’emploi (n’est-ce pas l’idée de Gladys assistant après tout ? ) il est toujours un peu rebutant de se confronter à ce paradoxe :
Je souhaite faire un truc simple (allumer une ampoule grâce à un interrupteur) VS je dois comprendre un système complexe pour y arriver.
Quand je dis complexe tout est relatif bien évidemment !
Elles font quoi ces scènes?
Si tu as des captures d’écrans complète de la page avec tout le scénario encore mieux 
Je comprend! Je suis d’accord qu’on pourrait améliorer le process actuel, j’essaie de récolter des retours comme ça on peut penser le besoin et voir comment faire mieux
Voilà (attention, c’est looooooong)
Comme tu pourra le constater, c’est un peu long et répétitif à faire. La place pour l’erreur est aussi très grande !
@Terdious tu va perdre ton titre 
1 « J'aime »
En fait, ce qui serait intéressant, c’est de créer un endroit où chacun liste ses exemples de scénarios !
1 « J'aime »
Je trouve que c’est une très bonne idée.
Moi qui utilises Tasker sur mon mobile, j’aime trouver ce genre de choses !
Il faut juste trouver une manière simple de proposer des scènes et de les classifier par catégories, pour qu’on puisse en proposer de plus en plus dans la documentation.
Ça serait intéressant de préciser quels types de capteurs sont utilisés par exemple, et renvoyer vers la liste des intégrations.
Mais ce genre de doc va forcément pousser en avant le besoin d’import export des scènes.
2 « J'aime »
Pas certain que ça pousse à l’import/export, d’autant que chacun aura un matos différent… trop le bazar !
Par contre un index classé c’est une bonne idée!
Waaa effectivement ! 
Ok je vois le truc !
Par contre, pour le cas des batteries, à mon avis il faudrait carrément coder ça en natif dans Gladys je pense, c’est un truc qui devrait même pas à être à faire dans les scènes, non? Mais sinon effectivement, je pense qu’on pourrait rajouter dans la box « continuer seulement si » la possibilité d’accéder à des valeurs de capteurs « en direct » en plus de la partie variable, comme ça on garde le meilleur des deux mondes
Etant donné que les scénarios sont pas encore complètement rodé à mon sens, pour moi on pourrait juste partager ça sur le forum dans un premier temps ? L’objectif serait justement de déceler des incohérences comme ça avant de mettre ça dans la doc (clairement, on a pas envie de montrer ce genre de scènes dans la doc, c’est pas user-friendly 
)
Comme on l’avait déjà évoqué oui, Gladys devrait vérifier d’elle même :
- Le niveau de batterie des capteurs
- Si un capteur est inactif depuis plus de X valeur de temps
Qu’est ce que tu entends par « en direct »?
Si je prends l’exemple du service zigbee2mqtt, ce sont généralement les capteurs qui envoient leurs données et pas l’inverse. La valeur en direct correspondra à la dernière valeur reçue dans certains cas.
Sinon c’est une bonne idée, mais j’irai plus loin :
- continuer seulement si + dernière valeur
- continuer seulement si + valeur dans les X dernières minutes
Ça permet de dire « si un mouvement à été détecté dans les 10 dernières minutes dans n’importe quelle de mes pièces, faire quelque chose ».
Scénario que je n’arrive pas du tout à faire actuellement.
Idem, c’est une des raisons pour laquelle je conserve HA chez moi.
- Si motion détecté
- Continuer seulement si c’est la nuit ( entre sunset et sunrise)
- Alors allumer la ou les lampes
PG je te rejoins pour les devices sur batteries, une option du core qui notifie le/les admins si plus de batterie ça serait simple et efficace.
La valeur actuelle du capteur!
ça c’est normal, on a pas du tout encore la fonctionnalité de comparaison sur les dates/time des capteurs. Je suis d’accord, c’est un truc primordial. C’est marrant c’est pas du tout dans les features requests, j’avais pas ça en tête en du coup
Ouep, c’est effectivement pas possible actuellement non plus. Je suis d’accord aussi, ça manque clairement!
On se fait une feature request pour ces 2 demandes de fonctionnalités + des specs fonctionnelles ?
1 « J'aime »