Got it, I succeeded ![]()
However, I think we should be guided when creating scenes. Either with detailed explanations depending on what we want to do, or links to the documentation if it’s available.
Got it, I succeeded ![]()
However, I think we should be guided when creating scenes. Either with detailed explanations depending on what we want to do, or links to the documentation if it’s available.
Top!
Don’t hesitate to list the important points for a newcomer, so we can write the associated documentation (or you, since it’s public
).
Okay, I’ll see if I can help with that!
Thanks for your feedback!
Indeed, maybe the « continue only if » box isn’t explicit enough
You’re right, we should explain the flow in the box.
For the trigger, in my opinion, it doesn’t make sense to have multiple comparisons in a trigger, because a trigger is an « event, » not a state.
An event is, for example, « the temperature just changed from 6 to 8°C. »
But I agree that the overall flow might not be explicit.
Yes, you’re right. In fact, by explicitly explaining the flow, we can absolutely do without that famous AND
I don’t know how this could be managed, but in my human brain, I see things this way:
IF the light is off THEN a simple click TURNS the light ON
So in fact, it’s in the order condition > trigger > action
Either we need to be able to integrate this order into the creation of a scene (I don’t think this is a good idea as it would lack homogeneity in the end), or we need to find a way to go from:
condition > trigger > action
to
trigger > condition > action in a simple and understandable way even for the most clueless people like me. This, in my opinion, implies reducing the steps (the number of actions) to a minimum.
In my example below, I would have gladly grouped steps 1 and 2 into one!
So I thought of something a bit silly, maybe technically unfeasible but:
Would it be possible to determine for each scene which equipment will be solicited. For example, at the beginning of the scene creation.
For me, it’s Aqara Mini Switch and Aqara Bulb Light
Gladys then automatically and systematically retrieves the last states.
I therefore no longer have to worry about creating an action to retrieve the last state for each piece of equipment.
I can therefore do:
What do you think?
Actually, the idea behind this double step was to have a very powerful scene engine, and to be able to compare the values of the same sensor over time.
An example:
However, this does indeed imply having to perform a double step even for very simple cases like yours. I agree, it’s a bit heavy always having to ask for the state…
It’s simpler if you have 20+ sensors to list only those you want to retrieve … and longer to do when you want to compare more than 5 sensors.
I have some scenes where I want to retrieve the battery of all my sensors, it’s very, very long to do!
Was there a proposal to use and display the old values of the sensors in the scenes and the dashboard already?
I understand the idea and indeed it allows for much more powerful things.
Perhaps more detailed labels or boxes would help advance the creation of a scene.
For example, I would find it more judicious to read: « Retrieve the current state » rather than the « last state ». These are small details but I think it’s in the details that everything plays out ![]()
In fact, for me, it doesn’t change my life, I like to test / tinker… but I think of the user who doesn’t want to overcomplicate things and use a ready-to-use tool (isn’t that the idea of Gladys assistant after all?) it is always a bit off-putting to confront this paradox:
I want to do something simple (turn on a light bulb with a switch) VS I have to understand a complex system to achieve it.
When I say complex, everything is relative of course!
What do these scenes do? ![]()
If you have complete screenshots of the page with the entire scenario, that would be even better ![]()
I understand! I agree that we could improve the current process, I’m trying to gather feedback so we can think about the need and see how to do better
@Terdious you’re going to lose your title ![]()
![]()
Actually, what would be interesting is to create a place where everyone lists their examples of scenarios!
I think that’s a great idea.
I, who use Tasker on my mobile, love to find things like this!
It’s just a matter of finding a simple way to propose scenes and classify them by categories, so that we can propose more and more of them in the documentation.
It would be interesting to specify, for example, what types of sensors are used, and to refer to the list of integrations.
But this kind of documentation will inevitably push forward the need for scene import/export.
Not sure that this will help with import/export, especially since everyone will have different equipment… too messy!
On the other hand, a sorted index is a good idea!
Waaa indeed!
Ok, I see the point!
On the other hand, for the case of batteries, in my opinion, it would be better to code this natively in Gladys, I think, it’s something that shouldn’t even be done in the scenes, right? But otherwise, indeed, I think we could add in the box « continue only if » the possibility to access sensor values « live » in addition to the variable part, so we keep the best of both worlds
![]()
Given that the scenarios are not yet completely refined in my opinion, for me we could just share this on the forum first? The goal would indeed be to identify inconsistencies like this before putting it in the documentation (clearly, we don’t want to show this kind of scenes in the documentation, it’s not user-friendly
)
As we had already mentioned, yes, Gladys should check on her own:
What do you mean by « live »?
If I take the example of the zigbee2mqtt service, it is usually the sensors that send their data and not the other way around. The live value will correspond to the last value received in some cases.
Otherwise, it’s a good idea, but I would go further:
This allows you to say « if movement has been detected in the last 10 minutes in any of my rooms, do something ».
A scenario that I cannot do at all right now.
Same here, it’s one of the reasons I keep HA at home.
PG I agree with you about battery-powered devices, a core option that notifies the admin(s) if the battery is low would be simple and effective.
The current sensor value!
This is normal, we don’t have the sensor date/time comparison functionality yet. I agree, it’s essential. Funny, it’s not at all in the feature requests, I didn’t have that in mind so ![]()
Yep, this is also not possible right now. I agree too, it’s clearly missing!
Should we make a feature request for these 2 feature requests + functional specs?