Beta - Ezlo Linux 2.0.32.2097.3 [production-146] for Ezlo Plus, Ezlo Secure controllers

‘Need’ isn’t really true. If you want a global exception then just add it as another trigger in the trigger group.

" * Exceptions however do NOT trigger the meshbot, they are just checked for their comparison to be valid."

This is just semantics if you think about it. ‘Meshbot’ in the sentence above really means ‘one or more meshbot actions’.

Actions that do not have exceptions will run as normal when the main trigger group goes true. Actions that do have exceptions will only run when the main trigger group goes true AND the exception trigger(s) go true… so they do trigger the “meshbot”.

The main (maybe only) unique benefit of exceptions is meshbot consolidation for complex/multi-condition tasks. They can let you achieve these tasks in one meshbot instead of multiple.

In the majority of cases, however, you can just put everything in your trigger group and be fine. It’s personal preference whether you add the triggers to the trigger group or go down the exceptions route. There’s no functional difference either way, and no one way you ‘should’ do it.

Personally, I’m fine with the current system. I think adding a third UI element called ‘conditions’ is more likely to confuse new users than help them. We’d also then have to explain the difference between a trigger’s conditions (the trigger’s drop-down menus/parameters) and the UI item called conditions.

Yes, local applies to a specific action…

Global would affect the entire scene in non-meshbot parlance.

And the name for these in the UI should be distinct and nemonic so it is intuitive and definitely not overloaded like we currently have for “trigger”. Like I said, the UX should speak the user’s language that EZLogic transforms to the engine’s language so to speak. So even if everything is a trigger at the engine level, the UX can express them in a more intuitive fashion and EZLogic will translates the user’s expression to the engine’s understanding.

That sums up my point exactly! Well said!

1 Like

So I can put my Global Exceptions “Conditions” in to a Triggers group OR I could potentially put them in Action Exceptions instead.

So should “Exceptions” button be added in to the Triggers area of the UI like what we have now in Actions, do you think? Or just leave it as it?

Its still fairly confusing to be honest. Maybe I’m having a blonde moment.

EDIT although as it stands right now, Id have to add my exceptions to each action which would be a ball ache and not something I would entertain doing.

Yes I agree with what you said there.

“So I can put my Global Exceptions “Conditions” in to a Triggers group OR I could potentially put them in Action Exceptions instead.”

Yes. If it’s a ‘global’ exception, then what’s the difference between that and just adding another ‘and’ trigger?

Implementing a ‘global’ exception in actions (currently) means you’d have to add the exact same exception to every action - a huge time-waster over just adding another trigger to your main group.

I’m not saying a group exception feature wouldn’t be a nice addition, it’s just that you can already achieve it by just adding another trigger. A ‘group’ exception feature would give you another way to skin the cat, but you can already skin it perfectly well under the current system.

hi @Paul_Whitehead , @blacey , @cw-kid

The Final Explanation : )
As I stated in the earlier post, there is a clear distinction between exceptions and triggers.
Any comparison put in triggers, MAY/CAN trigger meshbot execution. (Any broadcast about that comparison data source change)
Any comparison put in exceptions NEVER trigger meshbot execution.
So it depends on user requirement. you can put the comparison to either places according to meshbot execution differentiation.

The missing part is that we currently don’t have a “global” exception per your understanding which effects all of the actions. So it’s in our feature list and we will deliver it soon.

Osman and I just had a voice chat and he and I are in full agreement.

Exceptions (those specified device states) cannot ever make a rule re-trigger and start again. They are “Conditional Checks” only that have no affect on the triggering of the rule.

So in my rule example for my lounge lamps ON schedule, I should NOT be putting in any other additional triggers as “Conditions” in to the triggers area of the rule. I should only have the one trigger a time based trigger of 40 minutes before Sunset.

Instead these additional “Conditional Checks” should be put into “Global Exceptions”. This currently does not exist in Meshbots as of today, but the devs are going to look into implementing it.

Currently in Meshbots now we only have “Action Level Exceptions”. These additional further Exceptions only affect that one particular individual action.

Where as “Global Exceptions” would affect all of the Actions.

So for those using MSR

“Global Exceptions” would be the equivalent of “Contraints”.

And “Action Level Exceptions” would be the equivalent of “Groups” in MSR Actions.

I’d say they should be called the following but I dont really care what they call them as long as it can be implemented.

Exceptions that affect all actions should just be called “Exceptions”. And positioned in between Triggers and Actions sections in the UI.

Exceptions that are at the individual action level should be called “Action Level Exceptions” or just “Action Exceptions”.

Or what do you guys suggest they be called?

Personally if it was up to me I’d call them “Conditions” and “Action Conditions”. But dont want to push my luck here too much…