Pour moi, tu peux déjà mettre plusieurs déclencheurs qui agissent avec un OU (n’importe lequel qui se déclenche lance la scène).
Et ça n’a pas de sens de les mettre avec un ET car ce sont des événements et non des états. Tu ne peux pas dire « la porte s’ouvre et la température passe au dessus de 20°C » mais plutôt « la porte s’ouvre et la température est au dessus de 20°C ».
Du coup, c’est déjà possible avec la fonction Continuer seulement si.
Est-ce que tu as un exemple de cas d’usage ?
Dans ton exemple il faudrait faire :
un peu plus compliqué non ? Surtout si on souhaites avoir plusieurs conditions ET, là on pourrait faire cela juste avec un toggle !
Coté prog, un set à ‹ 1 › pour chaque déclencheur validé, ‹ 0 › dans le cas contraire, à la fin du parcours des déclencheurs on compte le nombre de déclencheurs et le total des valeurs de déclencheurs si les 2 sont égaux c’est un ET donc on continue et l’action est exécutée (dans un autre language c ou vb j’aurais codé mais en js non !) 
En fait ce n’est pas tellement plus compliqué c’est juste une autre logique.
Tu peux avoir plusieurs conditions ET facilement : tu mets plusieurs blocs côte à côte.
Pour reprendre mon exemple, on pourrait faire :
Déclencheur : quand tu quittes la maisonRécupérer l’état de ta prise, de la luminosité, de la températurecontinuer si et seulement si la prise est allumée / continuer si et seulement si luminosité > 150lumen / continuer si et seulement si température > 20°Dans ce cas là il faut que toutes les conditions soient réunies dans le bloc 3 pour lancer l’action. Et ce n’est pas beaucoup de configuration en plus.
Je pense que ce qui surprend pas mal les gens, c’est de devoir récupérer une valeur avant de pouvoir l’utiliser (moi le premier en fait).
Il doit forcément y avoir une raison technique à ça - @pierre-gilles si tu me lis ^^ - mais il est vrai que dans mon monde idéal, j’aimerai que ma scène puisse être :
Déclencheur : quand tu quittes la maisoncontinuer si et seulement si la prise est allumée / continuer si et seulement si luminosité > 150lumen / continuer si et seulement si température > 20°Beh justement a vos vote :
DAMN !!! J’étais passé à côté de ça !!!
Je pense en effet qu’il faudrait travailler là dessus, je reste persuadué que c’est un frein à l’adoption de Gladys.
On a déjà vu plusieurs fois sur le forum des gens se questionner sur le fonctionnement des scènes… voilà qui pourrait aider 
Pareil ! Je vote direct !
EDIT : En fait c’était suite à mes toutes premières remarques quand je suis arrivé 
Disons que l’avantage ici est de pouvoir passer d’un mode « au moins une des conditions remplies » à « toutes les conditions remplies » dans un seul bloc sans avoir à refaire la scène, ça me parait plus clair à l’usage et plus pratique à mettre en place (d’un coup d’oeil on voit toute les conditions) ! Après rien n’empêche d’avoir les 2 modes, dans le premier on met en avant le test de la condition primaire avant de passer au test des autres avec
continuer si et seulement si
, dans le cas que je propose on teste qu’au moins une des condition est réunie (fonctionnement actuel) OU on teste que toutes les conditions soient réunies
La je suis d’accord ce serait plus clair que récupérer des états pour les utiliser ensuite après comme tu dis si c’est une raison technique à cela…
Pour ajouter une raison à cette fonctionnalité et comme je viens de comprendre l’interêt d’un device virtuel (my god mais que m’arrives t-il ? 
)
Donc je crée un « Commutateur » Mqtt ici appelé virtuel1 mais qui dans mon exemple devrait s’appeler 'Tous les contact d’ouverture sont fermés"
Dans une scène je créé
Qui m’active/désactive mon device virtuel ici dans l’exemple si toutes mes prises NOUS ne consomment pas (à transposer avec les capteurs d’ouverture), le problème est de devoir faire une scène inverse "au moins une prise consomme = au moins un capteur est ouvert) pour inverser le device virtuel donc on l’a avec la possibilité de passer le coche à « Au moins un »
Ce device virtuel pourrait être utilisé par la suite dans mes scènes (c’est quand même plus pratique !)
Donc l’avantage de cette demande c’est j’ai 20 capteurs et je considére l’état 'tout les capteurs ok" si j’ai coché « tous »…plus simple à paramétrer non ?
L’idéal serait d’avoir la possibilité de créer un appareil « Appareil virtuel » dans la page intégration MQTT qui ferait ce rôle !!!
Et maintenant que @pierre-gilles a développé l’intégration « alarme » ca va de pair je pense !
Je ferais la requête en ce sens ce soir 
Est-ce qu’on peut fermer cette demande de fonctionnalité (ou juste la convertir en sujet dans Configuration?) ?
Sauf si j’ai mal compris tu peux déjà faire ça non ?
Tu peux créer la SCENE 1 qui :
Puis la SCENE 2 (pour pas t’embêter tu copies SCENE 1 et la modifie à ta guise) qui :
Ensuite tu peux récupérer où tu veux dans les scènes la valeur d’état de ton commutateur.
C’est bien ça le but ?
Oui c’est exactement cela de façon simplifiée ou plus claire, le fait de pouvoir mettre l’ensemble des capteurs dans le 1er bloc puis avoir le choix grâce à ce toggle que je proposait permet de pas avoir une liste de x conditions « continue si » etc !
Là en 2 blocs on fait le boulot
Dans le cas de l’alarme
1ere scene
dans le 1er bloc de déclencheurs, je met tous mes capteurs concernés avec l’état « on » je coche 'tous" et s’ils sont tous ok j’active l’alarme
2 ème scène
dans le 1er bloc de déclencheurs, je met tout mes capteurs concernés je coche 'au moins un" et si un capteur est "off, j’active pas l’alarme et j’envoie un message par exemple
Ca me parait tellement plus simple et logique…mais bon après s’ il y a pas d’adhésion tant pis…
Le problème de base dans ce que tu décris c’est qu’on pourra tourner le problème dans tous les sens, un Déclencheur ne peut pas être l’état d’un device, mais un événement.
Donc ta scène idéale ne peut pas exister en tant que telle.
Après je suis le premier à me dire qu’on peut améliorer la création des scènes, toute idée est bonne à étudier 
Le top à mon avis, c’est un visuel à la node-RED
Je suis plutôt d’accord avec ça, un bon exemple étant Homey (si je dis pas de bêtises) qui a dev un nodered-like pour créer des scènes.
Sauf que ce serait une refonte gigantesque, qui même si elle est probablement envisageable un jour, n’empêche pas de retoucher les scènes existantes pour améliorer l’UX, car je suis persuadé que les gens n’utilisent pas ses possibilités à 100%.
Oui et non pour moi c’est aussi l’activation de la scène l’événement
ma scène c’est je demande l’activation de l’alarme et le fait que tous les capteurs soient ok déclenchent la poursuite vers l’activation (ou pas si un capteur est ko) de cette alarme (c’est ma logique, peut-être n’est elle pas bonne)
Pour donner un aperçu de ce que j’ai actuellement avec ma centrale HC2 de Myfox qui a été rachetée par Somfy mais dont ils ne fournissent plus de matériel juste le maintien du site web, donc au fur et à mesure que mes équipements tombe/tomberont en panne bah c’est mort (problème des détecteurs fumée notamment obligatoirement à changer tous les 10 ans) il me faut donc me tourner vers une autre solution, j’ai regardé les principales solutions Domoticz, Jeedom, Home-assistant et je dois dire que de loin Gladys est la plus simple au niveau du paramétrage mais pour certains besoins elle est aussi la moins puissante car limitée dans ce paramétrage, le bon équilibre entre les deux est certainement pas la plus facile des taches pour les développeurs mais Gladys a pour avantage d’avoir un développement qui suit tant faire se peut les demandes des utilisateurs.
Pour donner un exemple de ce que j’ai actuellement
Mes capteurs d’effraction
Beau système bien concu mais fermé et comme il date de 2013 et n’est plus maintenu, il risque de pas tarder à être down que ce soit côté centrale ou des capteurs d’où mon orientation vers gladys…
L’avantage de Gladys est qu’il est ouvert au niveau du code (donc adaptable), au niveau des technologies qu’il supporte (donc perenne) , c’est pas une usine à gaz pour s’en servir ou le paramétrer, l’équipe de dev tente de répondre aux besoins des utilisateurs (même si parfois le dialogue est pas toujours simple car long par écrit et nécessite parfois la même approche de compréhension des choses, d’un coté les dev qui connaissent le code de Gladys donc savent ce qu’il est possible de faire et la complexité à le faire et de l’autre les utilisateurs qui demande des évolutions et dont la connaissance se situe entre néophyte qui découvre gladys et développeur de gladys, évolutions parfois justifiées et utiles à gladys avec une contrainte temporelle parfois impossible à réaliser techniquement parfois parce que la logique du fonctionnement de gladys n’est pas correctement comprise, mon cas parfois, mais pour moi si c’est pas compris cela peut aussi peut-être rebuter un futur utilisateur à l’adopter) .
Voilà j’ai été long mais espère avoir été clair (cette fois).
Pour moi tu peut fermer cette demande, je pensais qu’elle simplifierait la programmation des scènes (ici dans le cas d’une alarme) mais peut-être la demande est mal formulée.
Peu-être l’idéal aurait été de pouvoir créer un device virtuel qui réunissent l’ensemble des capteurs assignés à l’alarme permettant ainsi de simplifier la création de scène…mais je ne ferais pas de demande rassures toi ! 
Ps : un des avantages aussi de gladys c’est la simplicité du pilotage à distance il suffit de regarder comment faire sous HA ou jeedom pour s’en convaincre
C’est un atout pas toujours mis en avant, ce que peut faire gladys simplement qui est bien moins facile pour d’autres solution…
