It would be nice to have this toggle as shown below in scenes
Depending on the choice, the next action
For me, you can already add multiple triggers that act with an OR (any one that triggers launches the scene).
And it doesn’t make sense to combine them with an AND because these are events and not states. You can’t say « the door opens and the temperature goes above 20°C » but rather « the door opens and the temperature is above 20°C ».
So, that’s already possible with the Continue only if function.
Do you have an example use case?
For example :
If I leave the house and the plug is plugged in the next action is activated
In this case it’s one of the 2 triggers that activates the next action
Unless I set up my scene incorrectly…
It could also be, if I leave the house and the light sensor is low, turn on the outdoor light etc
In your example you should do:
- Trigger: when you leave the house
- Retrieve the state of your plug
- continue if and only if the plug is on
- desired action
a bit more complicated, isn’t it? Especially if we want to have multiple AND conditions — there we could do that just with a toggle!
On the programming side, set to ‹ 1 › for each validated trigger, ‹ 0 › otherwise; at the end of iterating through the triggers we count the number of triggers and the total of the trigger values — if the two are equal it’s an AND so we continue and the action is executed (in another language C or VB I would have coded it but not in JS!) 
Actually it’s not that much more complicated, it’s just a different logic.
You can have several AND conditions easily: you put several blocks side by side.
To use my example, we could do:
Trigger: when you leave the houseGet the stateof your plug, the brightness, the temperaturecontinue only ifthe plug is on /continue only ifbrightness > 150 lumen /continue only iftemperature > 20°- desired action
In that case all conditions must be met in block 3 to trigger the action. And it’s not much extra configuration.
I think what surprises many people is having to retrieve a value before being able to use it (myself included, actually).
There must surely be a technical reason for that - @pierre-gilles if you’re reading this ^^ - but it’s true that in my ideal world, I’d like my scene to be:
Trigger: when you leave the housecontinue only ifthe plug is on /continue only ifbrightness > 150 lumen /continue only iftemperature > 20°- desired action
Well exactly — cast your vote:
DAMN!!! I completely missed that!!!
I do think we should work on that; I’m convinced it’s a barrier to the adoption of Gladys.
We’ve already seen several people on the forum question how scenes work… this could help 
Same here! I’m voting right away!
EDIT : Actually it was following my very first remarks when I arrived 
2 Likes
1 Like
Let’s say the advantage here is being able to switch from a mode « at least one of the conditions met » to « all the conditions met » in a single block without having to redo the scene, it seems clearer in use and more practical to set up (at a glance you can see all the conditions)! After that nothing prevents having both modes; in the first we emphasize testing the primary condition before moving on to test the others with
continue if and only if
, in the case I propose we test that at least one of the conditions is met (current behavior) OR we test that all the conditions are met
Here I agree it would be clearer than fetching states to use them later as you say if that’s a technical reason for it…
1 Like
To add a reason for this feature and since I’ve just understood the usefulness of a virtual device (my god what’s happening to me? 
)
So I create an MQTT « Switch » here called virtuel1 but which in my example should be called ‹ All contact sensors are closed ›
In a scene I create
Which activates/deactivates my virtual device here in the example if all my prises NOUS are not consuming (to transpose with the contact sensors), the problem is having to make an inverse scene « at least one plug consumes = at least one sensor is open » to invert the virtual device so we have it with the possibility to set the option to « At least one »
This virtual device could then be used in my scenes (it’s much more convenient!)
So the advantage of this request is: I have 20 sensors and I consider the state ‹ all sensors OK › if I’ve checked « all »…easier to configure, no?
Ideally it would be possible to create a device « Virtual device » on the MQTT integration page that would play this role!!!
And now that @pierre-gilles has developed the « alarm » integration it goes hand in hand I think!
I’ll make the request accordingly tonight 
Can we close this feature request (or just convert it into a topic in Configuration)?
1 Like
Unless I’m mistaken, you can already do that, right?
You can create SCENE 1 which:
- tests all your sensors
- sets your switch to ON if everything is at zero
Then SCENE 2 (to save yourself the trouble you copy SCENE 1 and modify it as you wish) which:
- tests all your sensors
- sets your switch to OFF if one or more sensors are different from zero
Then you can retrieve the state value of your switch anywhere you want within the scenes.
Is that the goal?
Yes, that’s exactly it in a simplified or clearer way: being able to put all the sensors in the 1st block and then have the choice thanks to that toggle I proposed avoids having a list of x « continue if » conditions etc!
There, in 2 blocks we get the job done
In the case of the alarm
1st scene
in the 1st triggers block, I put all my relevant sensors with the state « on », I check ‹ all › and if they’re all OK I activate the alarm
2nd scene
in the 1st triggers block, I put all my relevant sensors, I check ‹ at least one › and if one sensor is « off », I don’t activate the alarm and I send a message for example
It seems so much simpler and more logical to me… but oh well, if there’s no buy-in, too bad…
The basic problem in what you describe is that, however you turn the problem, a trigger cannot be the state of a device, but an event.
So your ideal scene cannot exist as such.
That said, I’m the first to say that we can improve the creation of scenes; any idea is worth studying 
In my opinion, the best is a Node-RED-style visual
1 Like
I pretty much agree with that, a good example being Homey (if I’m not mistaken) which developed a Node-RED-like interface to create scenes.
Except that would be a gigantic overhaul, which, even if it’s probably conceivable one day, doesn’t prevent tweaking existing scenes to improve the UX, because I’m convinced people aren’t using its capabilities 100%.
1 Like