Hello
A quick post to ask if you’re familiar with
I haven’t gone into the details but I have the feeling that it’s similar to Gladys, except that they sell the hardware and the software together in a bundle…
Hello
A quick post to ask if you’re familiar with
I haven’t gone into the details but I have the feeling that it’s similar to Gladys, except that they sell the hardware and the software together in a bundle…
I know
They ran a Kickstarter a long time ago!
But it’s not open-source ^^
Yes, I did see that…
It looks like the same logo, a colored version!
I just discovered it, it looks nice. Not open-source, so that’s a no for me ^^
However I have a confession to make… I’m a FAN of their scene creation (the FLOW): Advanced Flow | Homey
I find it both well thought-out and well presented. I say that if Gladys ever takes inspiration from it, I wouldn’t complain
@pierre-gilles haha
It looks like Node-RED.
Yes, absolutely, and I think it looks really great.
They’re still as trendy, very polished UI: https://www.lesalexiens.fr/actualites/homey-insights-est-desormais-disponible-sur-mobile/
For me it’s a no — I don’t want to relive my experience with Myfox, I’m done with closed systems! I prefer gladys and its remote access via gladys plus at €5 per month, which is reasonable if you consider that to do the same with Jeedom or HA or Domoticz you need a VPN and that also has a monthly cost but without the backup!
Par contre c’est vrai qu’il y a du bon a prendre dans leur philosophie pour les scènes
- WHEN : allows you to select the triggering event. It can be the change of state of a device, a defined event, a specific date, a time of day, etc. There is only one per Flow. If you want several, you’ll have to go through a flow calling another flow, we’ll come back to this in a future tutorial Homey…
- AND / OR : you can add one or more conditions and use the « AND » and « OR » operators. This is what our voice assistants lack and what allows you to go much further… Indeed we will be able to determine actions to perform if several conditions are met with « AND » but also alternatives with « OR ».
La il manque le ET dans gladys
- THEN / ELSE : it’s the action or actions to execute. You can obviously choose several, but also determine an action if the conditions are not met, and even call flows within your flows.
Là il manque le SINON dans gladys
On the other hand, the short videos that show how to do things are good (there was the same thing on Myfox for configuring sensors — much faster and more effective than a manual!)
The AND is not missing in Gladys.
If you put 2 conditions side by side in the same block, then it’s an AND.
There is confusion about this :
In the ‹ trigger › box of a scene, it’s an ‹ or ›
In the following boxes (actions/conditions) it’s an ‹ and ›.
@The community, did I understand correctly this time?
That’s how I understood it too. I should have specified that I meant the action blocks, not the Trigger block.
I really think that the « problem » we’re talking about in various places on the forum is an issue of translating our human thought into a scenario executable by Gladys.
When speaking, we say « if the door opens AND the temperature is > 20° », so we’d like to create a scene with these 2 elements in mind.
But in fact there is definitely only one TRIGGER here: the opening of the door.
The rest is an additional condition, which we only test once the door has been opened.
I don’t think this behavior needs to be revisited; it’s logically sound.
However, perhaps we should find a way to better guide the user, because I find we come back to the topic regularly… Which may indicate that there’s some ambiguity to clarify! ![]()
Wouldn’t it be possible to display :
I like this kind of proposal.
It doesn’t change how things currently work, but it makes it a bit clearer ![]()
Ok I understand there are some UX tasks to do on the scenes to improve the interface ![]()
However, I’m having a bit of trouble with the proposed solutions.
You all talk about « AND » and « OR », but in scenes there is no notion of AND or OR anywhere.
What you describe is merely a logical consequence of the data model of scenes in Gladys, and in my view it’s the act of wanting to put these words (AND/OR) on all of that which creates confusion and leads to requests for far-fetched features.
In triggers, thinking there are "OR"s between triggers is not correct. @guim31’s explanations are very accurate, each scene can be triggered by an « event ».
Events are independent; there is no comparison made between multiple triggers. They are events that occur spontaneously and trigger the scene.
Regarding actions, there is no « AND »; it’s simply that all actions are executed, that’s all.
Now imagine that we nevertheless add « AND » or « OR » as text between triggers/actions.
In my view, this will amplify the comprehension issues, because now the user believes there is a relationship between these elements that are actually independent.
At the trigger level, the user will think that if we are able to do an « OR », then why not do an « AND »? (and this request comes up regularly), except that precisely, this makes no sense.
Possible solutions
What I notice in the example here (Homey):
WHEN: allows you to select the triggering event. It can be a device state change, a defined event, a specific date, a time of day, etc. There is only one per Flow.
It means they only allow one trigger per scene.
I asked myself that many times while coding the triggers, and I wonder if I made a mistake by allowing the user to create multiple triggers per scene.
I have the impression we’re the only home automation platform doing that, and nobody seems to understand this feature.
What do you think about removing the multiple triggers feature?
Edit: Proposal:
Personally, I have lots of scenes with multiple triggers, so it would bother me a bit to have to redo my scenes.
That wouldn’t be the case, we can do an automatic migration ![]()
That means there will be many more scenes.
I have a scene with 8 triggers to check battery status. That means I would have 8 scenes that do the same thing but on different devices.
I like the ability to do that in a single, unique scene.
And when adding a trigger why not put it in another box instead of putting it in the same one? I don’t know if that will help with understanding.
Despite the explanation that is already present:
Each trigger is
I’m not in favor of limiting it to a single trigger either.
That will multiply the number of scenes and it will quickly become unmanageable.
Maybe we should make the indicated text clearer:
Each trigger is independent. When the conditions of one of these triggers are met, the scene executes.
into something like:
Each trigger is independent. When any one of these triggers is activated, the scene runs.