Well, to me there is a clear distinction. A trigger is a single occurrence which is only true for that moment. A condition can be true for a long time. If you bunch them all together as triggers, it’s not clear which ‘condition’ starts the meshbot. It would even suggest that using a condition as a trigger could lead to repeated retriggering of the meshbot.
The lack of this distinction has already played tricks on my mind while configuring meshbots.
There is some difference in meshbot representation in the mobile apps and in the Ezlogic. We are gradually adding missing pieces to the mobile apps and Ezlogic in order to have the same UX for meshbots operations.
interesting thoughts…can you please expand on this by giving me some examples?
would you please give some examples of what kind of improvements you would like to see?
Also: do you think a new user would “seek for a Condition” statement (that they are not aware of) when building triggers? (my point is: does the confusion exist because of our past learning?)
As an example, I want to trigger a light by a motion sensor, but only till 1 hour before sunrise (and 1 hour after sunset). Now, as a condition, I want to state '1 hour after sunset and 1 hour before sunrise).
Probably this will work. But as it’s stated under ‘trigger’, in my head the state '1 hour after sunset) will only be true for a single second. The combined state ‘1 hour after sunset AND 1 hour before sunrise’ can be true for a condition, but not a trigger, unless you’re living in Iceland during the winter 
As I’ve only used reactor twice, circa 5 years ago, past learning would not apply to my case. I do have an IT background so I’m familiar with Boolean logic etc, which might influence how I think of meshbots.
so let me try to summarize here…there are 3 things you are looking at… (lets call them 3 different States of things…)
1-State of a Motion sensor (if there is a motion)
2-State of a time (one hour after sunset)
3-State of a time (one hour before sunrise)
Now, any of these 1, 2, 3 are interchanable…
eg: I can say my trigger is “one hour after sunset”…and put the rest by saying if there is a motion and one hour before sunrise…
Or
I can say: “One hour before sunrise”…if its “one hour after sunset” and " there is a motion"…
if you look at it, there is no technical differentiation of what could be called “condition” vs “Trigger”…
Trigger is a “state” (or collection of states using operators like and/or etc)…
Condition seems like a “subjective” determination of which “trigger” to call “condition”. There is no technical difference it seems to me, unless I am missing something?
Yes but folks shouldn’t be overly concerned about this. As the promise of meshbots becomes better understood/entrenched people will quickly realize the GUI interface via ezlogic.mios.com is a much better way to create and edit “scenes” than an iPhone/Android screen.
I don’t disagree but currently users can’t edit a scene in EZLogic that they created with the Vera App and that is a bug, plain and simple…
Hi @blacey
Thanks for spotting this one. We will add it into our next version hopefully.
“Selecting the house mode in which the meshbot should run” . You are right, That only exists in vera mobile app for now.
hi @jouked , @cw-kid , @blacey
Let me clarify the exceptions concept. Since there is no example of exceptions the way we use it in Meshbots , in the discussion.
We agree that the exceptions are basically same as triggers on comparison level. However the difference is
So in Meshbots the comparison blocks that you define in “TRIGGERS” are not exceptions. (or conditions as in MSR)
If you want to use an exception, you should define it in the “ACTIONS” “EXCEPTIONS” button:
so @jouked 's example would be :
The only missing part is that we don’t have grouping in “ACTION” part. But it can be easily achieved with creating another meshbot with an empty TRIGGER part and having the group of actions there to run them together.
You can just reference that meshbot to run as a single action in the triggering meshbot.
And for the Date&Time discussion :
The “Special Time of Day” Option works like this in our system :
It think the implemented logic is pretty powerful and adequate, it’s more a matter of guiding the user through a logical process in the UI. Taking a complex and powerful backend and presenting this in an easy to comprehend UI for the average user is hard.
Some little words might help. In the trigger section, for Node Type ‘Date and Time’, Node ‘Special Time of The Day’, ‘Sunrise’, Value type might be better expressed as ‘At least before’ instead of ‘Before’, as the ‘At least’ wording will indicate to the user that the trigger will evaluate as ‘true’ for a long time.
Furthermore, in your example with the graphs explaining before / after sunset, I think there is still a gap in applying this correctly. From the graph it’s implied that the ‘After sunset’ is ‘True’ from sunset till midnight. ‘Before sunrise’ is true from midnight till sunrise.
This would mean that ‘after sunset’ and ‘before sunrise’ will never be true at the same time. Thus in a trigger or exception they should be part of an ‘OR’ group instead of an ‘AND’ group. Which is way to fuzzy for an average user…
A ‘Between’ operator for times would make sense here.
@jouked yes you are right, we are working on improving the wording there, it will be updated in the next version.
Also you are right about the OR operator selection and for that we will introduce another option “During Day” or “During Night” into the Date&Time triggers. Hopefully in 1-2 months. It’s in the queue.
@osman, It will be interesting to see how this manifests in Meshbots because that was a contributing issue that spawned the lengthy discussion about trigger conditions and global exceptions.
That said, a good User Interaction design never overloads different semantics under the same UI element - while the underlying engine may not need to differentiate the different trigger semantics, from a usability standpoint it is not intuitive at all. There is a big difference between a Software Engineer and a User Interaction Design Engineer - I’m more of an engineer and will admit that I stink at UI design hence I always used the best of the best User-Interaction Design engineers for our products. If you want EZLogic to compete with the big players in the Matter space, then it behooves you to consider this…
This is getting even more confusing now.
So for my lounge lamps schedule rule above, where I had this.
I should now put all my “Conditions” in the Actions - Exceptions like this ?
Trigger:
Actions - with Exceptions “Conditions”.
This won’t work because I would need to add the same exceptions to both Actions ?
I then tried to do that, but I was unable to select Switch on the other two
If I’m confused there is no hope for Joe Bloggs.
Hence the original discussion about global/local exceptions within a Meshbot…
In my mind the “Exception(s)” on an Action was to be used to be able to add an additional “Condition” only on that particular action.
Like we can do using Groups on an Action in MSR.
So I might have 3 actions, 1 and 2 I want to run everytime the rule is triggered, but action 3 only runs if the exception is matched.
So this is what you are referring to as “Local”?
And “Global” exceptions would be “Conditions” that affect the entire rule.
So we dont have global Exceptions currently in Meshbots?
Just read this again, so we need global Exceptions that affect the entire rule and we dont seem to have that currenty.
And this:
This is what I’ve been saying for years now it seems.
But we have been told by Ezlo previously to just stick everything in to Triggers. And now Osman seems to be saying not to do that.
imagine it as two different periods…
Before MeshBot starts
After MeshBot starts…
Now, you can have many different states/data/trigger/condition to cause the MeshBot to start…No matter what you call them, you can put them in the “Trigger section”…
Now lets talk about “After MeshBot” starts…
A MeshBot could be running for a “Period of time”… (its not always a quick thing…)…
What if there is a “Dynamic state/condition/Trigger” that you want to use as exclusion “during when MeshBot is running” …that is the “Exception”…in the Action section…
In my example I only want one trigger to start the rule. A time trigger of 40 minutes before sunset.
I’m still confused you and Osman seem to be saying different things?
I don’t know where to put my “Conditions” or Exceptions or whatever you want to call them.
Do I put them in Triggers as well or do I put them in the Actions as Exceptions?
And as I pointed out I cannot put them in Action Exceptions anyway currently.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
