State Machines in Tasker

[Dave Disser]

After about a year of using Tasker and creating ever more complicated profiles, I seem to be constantly running in the issue of overlapping profiles and race conditions, for example:

* Make the phone quiet at night when I'm connected to my home wifi and the phone is plugged in

* Set the media volume when I dock in the car

These two profiles are triggered at the same time because I sometimes leave for work early, and I'm still connected to the wifi, and the phone is on AC in the car.  I probably have 6-8 more conflicts like this that I constantly have to arbitrate, which is a pain even with the runlog.

A solution I'm trying out is to implement a state machine in Tasker that will give me a sort of master context, so that I can have a controlled flow from NIGHT -> HOME -> CAR -> WORK -> CAR -> etc.

So far, I have set up a profile when %NEWSTATE is changed, then saves %STATE to %LASTSTATE, copies %NEWSTATE to %STATE, logs the change to a file for easy debugging.

My state transitions are implemented so that if %STATE="HOME" and BT connects to my car, then %NEWSTATE="CAR", etc.

I've already implemented my state transitions, and the next step will be to  change all of my profiles which actually change settings to make use of the new state.

Any thoughts?

[baudi]

I'll be interested to hear how this works out. Doesn't it depend on the predictability of your activities? For example, suppose you change your mind about going to work after getting in your car. Then the flow would be night > home > car > home. Would you have to anticipate every exception like that?

Also, some states could conceivably exist simultaneously: you could be near home and near grocery store at the same time.

[GermainZ]

I usually do the following:
All profiles that could potentially conflict start the same task, called "Event Handling", which then checks for active profiles (%PACTIVE) and acts accordingly.
Using the IF/ELSE IF statements, and adding some time counter to avoid repetitive calls, it's easy to make it prioritize actions (actions further up in the IF list will have a higher priority than those down).

[Richard Davis]

> I usually do the following:
> All profiles that could potentially conflict start the same task, called "Event Handling", which then checks for active profiles (%PACTIVE) and acts accordingly.
> Using the IF/ELSE IF statements, and adding some time counter to avoid repetitive calls, it's easy to make it prioritize actions (actions further up in the IF list will have a higher priority than those down).

That is how I handle it As well and it seems to work great. Dave fisher has a slightly different approach you might want to check out in the link below. You will notice in my example I set variables for my toggles but I have since switched to %PACTIVE as it is a far better approach.

Rich....

[Richard Davis]

Always helps to include the link... :)

https://groups.google.com/group/tasker/browse_thread/thread/c17f3eed34ff4ada/00b8b1c53293ed1d?hl=en&lnk=gst&q=Cascading+profile#00b8b1c53293ed1d

One of these days i will figure out how to make those links renamed into a cool one word link......

Rich...

[Cptnodegard]

I have multiple overlapping profiles and have no problems. I have each profile set a variable to 1, e.g. %Home to 1, and then the profile School uses %Home not 1 as one of the contexts. It's normally triggered by a calendar entry,while home is based on wifi, so even though the main triggers overlap all the time, I'm not at school if I'm home, so the system works brilliantly. In your case you car AC profile would simply have a variable value context for the variable that the wifi based profile controls, making it so that it won't become active until the other is inactive (which one is the master is up to you)

[Dave Disser]

Yes, you definitely need to think of all the states and transitions so that you don't get stranded...but I've done lots of firmware development where this is common practice. Also, some of my transitions are set up this way:

* state = car + BT not connected -> new state = left car
* state changed = left car + location work -> new state = work

This way, the "left car" state can still have meaningful settings and transitions, and I can do power wasting location operations, knowing that they will only run once.

Also, it's easy to do stuff like state = car + last state = work + time 1600-1800 -> navigate to home so I can see traffic.

[Cptnodegard]

You're right, being able to match it that way would be really useful. Hmm, might end up trying this myself, great idea!

[Richard Davis]

> I've already implemented my state transitions, and the next step will be to  change all of my profiles which actually change settings to make use of the new state.
>
> Any thoughts?

The one problem I found with letting different profiles change settings with multiple tasks was as baudi mentioned when they try to run at the same time. If one task is in the middle of changing settings and another profile becomes active then you need to anticipate this and try to control it with priorities or wait untill , and it just gets very complicated. Everything got much less complex when i had only one task allowed to change settings.

  Because profiles become active instantly when there contexts are met no matter what task is running when my settings task is flowing through the logic steps,  using the %PACTVE it can make choices based on what contexts are met at that exact point in time and not rely on a task to set a variable that could be interrupted by another task with a higher priority. (I hope that makes sense)

The way I control the settings task is simply when a profile becomes active like 'Home' it will first do a wait until %TRUN not match 'settings ' to make sure it waits its turn then a perform task 'settings'  and pass the profile name 'Home' through %par1 so 'settings' knows which profile would like to change the settings. 

I could be totally missing the bigger picture of the way your state variables will work and would be very interested in how it works out, please let us know....

Just thought I would add my two cents...   Rich....

[Dave Disser]

As an update, I've been having a lot of success with the state machine approach.  The "new state" profile has become more complex, and now does the following:

• Stop if %STATELOCK is set (allow tasks to inhibit transitions temporarily)
• Stop if %NEWSTATE ~ %STATE (non-transitions are no-ops)
• Set %LSTIME To %TIMES - %TSTART (record the time spent in the previous state)
• If %NEWSTATE ~ %LASTSTATE -> If %LSTIME < 3 -> stop (detect thrashing between states too quickly)
• Set %LASTSTATE to %STATE
• Set %STATE to %NEWSTATE
• Log %TIME, %LASTSTATE, %STATE, %LSTIME to the state change file
• Clear %NEWSTATE
• Set %TSTART to %TIMES

And the state machine currently has a bunch of state, with some settings based on the current state only and other dependent on the current and last state.  I'm pretty happy with the way it's turning out.

[TomL]

how is the execution performance? what hardware are you running on?

[Dave Disser]

Performance is good enough.  Right now I have a bunch of logging and notifications on every state change, so it takes 1-2 seconds to change states.  I'm on a Samsung i777.

[Cptnodegard]

This looks great! Mind if I post it as an article on pocketables.com? With full credits and source to you, obviously

[Dave Disser]

I don't mind at all, but let me get together some screen shots and profile exports for you.

[Cptnodegard]

Thanks, but just posting the idea and the simple rundown should do it. Got a bunch of tutorials there already where something very similar to this has been shown off. I don't like providing downloads because if you haven't made it from scratch, you don't know how it works, and then you don't know how to fix it. 

[Dan]

that is a very interesting approach. I would be very interested in it as well...

just for the fun of it. same diagram in yUML.

Edit that diagram here: http://yuml.me/diagram/scruffy;dir:TB;/class/

dan

[Dan]

sorry... here: http://yuml.me/edit/bfc63e25

[Dave Disser]

Go on then.  I'd rather not be attributed by name... people can find this list if they really want to, but I don't necessarily want people coming to me for support :)

[Cptnodegard]

I posted it a few min ago with a link and name, changed to blank out the name now. There's still a link though, want that gone too?

[Dave Disser]

I think it's fine as it is now... thanks.

[easiuser]

I am interested in implementing something like this but there are a couple of scenarios that I would like to know how you might handle.  I will use your diagram as an example.

While driving, I may enter an leave my CellNear Home several times (errands, picking up car poolers, etc) before leaving the area.  Per your diagram, I would go back to the Near Home State and stay there all day, until I returned home and connected to my WIFI).

I thought about forcing it to enter the left car state prior to entering the near home state but that presents another problem that is even more likely to occur.  Conditions can happen where you might cascade through multiple states immediately.  Consider coming home and parking the car in the garage.  You have Cell Near, WIFI connected and BT connected.  When you turn off the BT it will want to transition from Car->Left Car->Near Home->Home instantaneously.  Because you have the 3 second (no thrashing) rule it will not transition from Left Car->NearHome.  How will the "new state" profile get triggered again?

[Dave Disser]

Oops, you've found an error in my diagram.  The only exit from Car state is when bluetooth disconnects.  I have it correct in the state machine, but I documented incorrectly in the diagram.

Also, the no thrashing rule is a nesting of "if new state is the same the previous state" and "last state time < 3" seconds.  Note that "new state," "previous state," and "current state" are discrete values, so what this is detecting is that I went from state A -> state B for less than three seconds -> state A again.  When I get home, I do transition from Car -> Left Car -> Near Home -> Home in just a couple seconds.

[Jared Isch]

Did this ever get posted on pocketables.com?  I can't seem to find any mention of state machine on the site.  I'm really interested in using this idea to create my profiles.

[Cptnodegard]

http://www.pocketables.com/2012/11/user-creates-great-state-switching-system-in-tasker.html

[Jared Isch]

:) i just found it and came to post....thanks again!

[Jared Isch]

Dave, was wondering if you could provide a couple screenshots.  Most of the profiles I have created past, or I'm sure I can create.  However I'm having some problems understanding how some of the profiles are put together.  I.E you have a profile for "left car" etc that calls another profile to create all the changes? If you aren't up for it, totally get, it, especially since it's been like a year :)