Note I did not use any Action Exceptions in my tests at all, I was just switching the two Actions order around.
With regard to using Action Exceptions I have tried them in the past and they seemed to work OK then, perhaps I need to try them again now.
Exceptions isn’t the best wording they should be called “Conditions” like PLEG and MSR.
Also note Ezlo plan to add what they are calling “Global Exceptions” basically whole rule based Conditions again like PLEG and MSR have.
A “Global Exception” will affect all Actions of a rule.
An Action level “Exception” will only affect that one particular Action itself but not affect any other Actions.
Exceptions isn’t the best wording they should be called “Conditions” like PLEG and MSR.
Agree 100% its confusing since it implies these conditions will block execution when rather they are actually a condition required for execution. I’ll forgive the ambiguity of this in favor for the logic working though.
So for example you could have a rule with some “Global Exceptions” when they arrive in the software that is.
Trigger - Is something happens to trigger the rule and set things going
Global Exceptions (Conditions)
Switch A must be ON (If it isn’t then none of the Actions would run at all, if Switch A is turned on then the actions will be run)
Actions
Turn on Light A (Only conforms to any “Global Exceptions” / conditions)
Turn on Light B (Only conforms to any “Global Exceptions” / conditions)
Send a HTTP request for a TTS announcement (But this also has an Action Level Exception as well)
Perhaps that Exception is the Ezlo controller must be in HOME mode. So that means Action 3 will only run if its in Home mode, if the controller is in any other mode then Action 3 is NOT run. But actions 1 and 2 would run.
All three actions will only run if Switch A in the “Global Exception” is ON but Action 3 also has an additional condition that must be met i.e. the Home mode being true, before it can be run.
That’s correct an action level exception means that its a condition that must be met in order for that particular action to be run.
This is how rules work in Reactor / MSR currently and presumably how they will also work in Meshbot’s also when they release the new “Global Exceptions” feature.
You have
Triggers
Conditions (Affect all Actions)
Actions
And also you can have further additional conditions on one particular Action (Action Level Condition), used as an additional check that must be past in order for that one particular action to be run.
… This is how rules work in Reactor / MSR currently and presumably how they will also work in Meshbot’s also when they release the new “Global Exceptions” feature…
Ezlo should contract to Rigpapa to port MSR to Ezlo. I have used it a little with Vera. Its meshbots without all the gotchas.
As @cw-kid mentioned we will have the same “Global Exceptions” aka Conditions as you know shortly on our platform as well.
Also the problem on Exceptions is already being investigated. We will try to expedite the process and get back to you as soon as possible.
MSR and Ezlo are different platforms in some sense as we needed to have different infrastructure to allow execution on our hub not on a standalone computer, also access from cloud - without port forwarding etc… We are always listening your feedback and improving our platform. We really appreciate your contribution to this process.
Virtual Switch 3 should only be turned ON if Virtual Switch 2 is already ON.
However if Virtual Switch 2 is currently OFF and I then trigger the rule then Virtual Switch 3 is turned ON anyway regardless and the Action Exception seems to be ignored.
This did work OK at one point in the past however.
Also note “True” text on the exception value and “true” text on the regular actions values, which is just cosmetic. “switch” vs “Switch” text also on the capability.
Try editing that meshbot to remove the exception. I found there were issues that remained after only the exception was removed. That is how I stumbled onto my simple swap the order of two actions (with no exception) and they didn’t work. I am thinking the rules aren’t being correctly published to the place they are executed.
p.s. It might be a nice feature to allow for a “notes” field alongside each row of triggers and actions for the author to document his logic in the meshbot. It wouldn’t have any executable impact but would make more complicated meshbots more readable.
