Request for Explanation/Clarification: Behavior in case of competing Profiles

[just-Nob]

Sorry for placing such a question here in the issues' section, but it came up to me when trying to program some automation with Easer, and I need that info for deciding if the fault it's on my or on Easer's side. Moreover, I think this may be interesting for other users as well.

So here we go: Imagine the following structure: If Condition A of Script I is fulfilled whereas Condition B of Script II isn't, it's totally clear that Profile 1 (associated to Script I) switches the Operation "a" to the value x (for example, this could be Bluetooth [→ a] switched to enabled [→ x]). If Condition A still stays true while Condition B (associated to Script II) turns true as well, Profile 2 will also be executed wich means that Operation "a" will now be switched to value y (e.g. Bluetooth [→ a] is now switched to disabled [→ y]). But on the other hand, Condition A is also still valid. So the question is about the current value of Operation "a":

1. Will Profile 2 simply overwrite x by y, i.e. the value latest being written will win? (This would be the behavior being closest to a state machine.)
2. Will the value of a toggle between x and y?
3. Will the value of a be undetermined?

For sure that question also rises up in case of the value of the same operation (Bluetooth, ringer mode, auto rotation etc.) being changed by two or more independent script branches.

[just-Nob]

One more question based on the scenario described above: Assuming that - caused by the activation of Script II - the value of operation a changed from x to y, (case 1. in the initial post), wich value will operation a just be set to if Condition B becomes false again, whereas Condition A still stays true? Will Profile 1 of Script A be activated one more time, i.e. will the value of operation a become x again, or will it stick at y?

[renyuneyun]

Hi :) Sorry for the long delay. Put the answer first: it is more like a (state) machine; but if Script I is using/checking an Event, then its value of "retriggerable/repeatable" also determines if Profile 1 can override Profile 2 (later).

I have to admit the name "Profile" is misleading. I wanted to rename it for a long time, but can't find a suitable one. The correct meaning of it should be "Operation Bundle" or "Operation Collection". It means that a Profile is simply a collection of operations to perform. It does not denote a long-lasting setting.

Therefore, the rule-of-thumb behaviour is: whoever gets executed the last, whose value the "current" value will be.

Condition is not repeatable, so it will not affect this behaviour. But a Script can use an Event and set itself to be repeatable, which means when the event happens the second time, the corresponding Profile should be triggered again, as explained on this wiki page for more information. Therefore, setting repeatable to true will allow Script I to get retriggered when its corresponding event happens again. Therefore, Profile 1 will override Profile 2 when that happens.

[just-Nob]

First my suggestion for renaming the "profile" data type: I think that a suitable naming may simply be "action(s)" or "action list".

Concerning the scripts' & profiles' behavior, I understood the following: By default (i.e. at Easer's startup), all "root" scripts are false (= "red dotted" in pivot) if they are currently evaluated but with their condition/event still unsatisfied. In that state, all their children are inactive (= neither red not green dotted), i.e. they're currently not evaluated. If now any script's condition becomes true (= "green dotted" in pivot), the script fires its profile one time ("single shot") and changes the state of its direct child(ren) from "inactive" to "false" or "true", depending on the status of the children's conditions/events. The script under consideration now stays true as long as a) it's not changed by the "control script node status" operation, b) at least one of its predecessors (if any) stay true and c) its associated condition stays true (not applicable to event-triggered scripts, see below). If a script changes to "inactive" or "false", it sets all its children into the "inactive" state. If a script is event-triggered, it may be retriggered by a second (third, fourth etc.) event occurrence as long as it's set to "repeatable", even if its own state is already true, and independent of its children's state.

Is that correct?