Help: Cancel a branch of Easer's tree

[sphh]

My scenario is as follows:

1. At work I have WiFi and Bluetooth on.
2. When I leave my office, I want to switch off Bluetooth, but only my Bluetooth headset is not connected (because otherwise I would loose my telephone call, if I leave during an on-going phone call).

I have the following set-up (Pivot view):

            Service start
              |
            Script: Departure
            Condition: NOT cell location
              |
            Script: Departure 2
            Condition: NOT Bluetooth Headset connected
              |
            Profile: Switch off Bluetooth

When I start Easer, that works well when I leave the office for the first time. The problem I run into, happens when I have the headset connected and leave the office, returning with the headset still connected. Than the condition NOT Bluetooth Headset connected never became true and it looks like Easer is waiting for this condition to become true. Now I plug the headset in to charge and it switches off (or I get out of reach with the Bluetooth headset). The condition NOT Bluetooth Headset connected becomes true and Easer switches the Bluetooth off.

Is there a way to cancel a branch of Easer's tree? Or is there another way to get it to work as I want it to do?

Thanks for your help!

Easer version: v0.7.7.7

[renyuneyun]

To make it clear: do you expect Easer not listen to the NOT Bluetooth Headset connected condition under the circumstance (after returning with the headset still connected), because you are back to the office and the NOT cell location condition should be false?

If yes, I suggest you check the "cool down time" setting. Try decreasing it to see if it improves the situation.

[just-Nob]

As I understand @sphh 's problem, he wants to skip the 2nd script immediately if it's not true, because otherwise the state machines token stays between the two scripts "Departure" and "Departure 2" as long as "Departure 2" stays in state "false". Anyway, "Departure 2" becomes true sometimes later and will then activate profile "Switch off Bluetooth" , which is a point in time being much to late.

To say it in other words: The problem is the absence of a real "logical and" operation. In that case, the sequential processing doesn't lead to desired behavior. Alternatively, a real "conditional branch" would do its job in that situation as well: if Script_Departure_2 = true then Profile_Switch_off_Bluetooth := true; else break; end if;

Personally, I would also appreciate the availability of a "logical and" operation.

[sphh]

Thanks @just-Nob to rephrase it in a clearer language. That's exactly what I want.

@renyuneyun, if I understand you correctly, that's what I'd expect. Could you please tell me the unit of the "cool down time", so that I can make a more educated guess what I am aiming for.

What would be the side-effects of reducing the "cool down time"? Higher battery usage?

Well, I think, @just-Nob's suggestion of a real "logical and" would solve my problem by way of a work-around. In real life, the tree branches at script Departure and another profile switches off WiFi:

            Service start
              |
            Script: Departure
            Condition: NOT cell location
              |
  +–––––––––––+–––––––––––––––+
  |                           |
Profile: Switch off WiFi    Script: Departure 2
                            Condition: NOT Bluetooth Headset connected
                              |
                            Profile: Switch off Bluetooth

With a "logical and" I would need a two branches:

            Service start
              |
  +–––––––––––+––––––––––––––––––+
  |                              |
Script: Departure A            Script: Departure
Condition: NOT cell location   Condition: NOT cell location
  |                                       AND NOT BT Headset connected
  |                              |
Profile: Switch off WiFi       Profile: Switch off Bluetooth

If there were a Profile's action "Reset the state engine of branch below Script XXX", I could add new branch:

            Service start
              |
            Script: Arrival
            Condition: Cell location
              |
            Profile: Reset state engine of branch "Departure"

But maybe that's a stupid idea and there are better ways to achieve this …

[just-Nob]

Hi @sphh, just have a look at issue #268 - may that error be the reason for the problem described na you at the issue's start?

[sphh]

Thanks @just-Nob for pointing this out. I tried it, but this seems not be an issue with BT headsets. That is the condition is not reversed.

[renyuneyun]

Some update after the looong time...

@sphh I guess you are already aware of the unit of "cooldown time" is "second".

The downside of reducing "cooldown time" is sometimes an Event (well, actually two -- a true and a false) happens back and forth, without really knowning why (e.g. Wi-Fi connected (seen in an early issue)). Battery usage should not increase significantly as far as I'm concerned, because Easer listens to things passively.

(Is this still a problem now?)

Logical "or" is implemented (in a sense) and is being tested in v0.7.9-beta. Multiple predecessors (parents) is the graphical description.