User creates great state switching system in Tasker
Many people who use Tasker end up creating different states with profiles that are active under certain circumstances, like at home, at work, in the car, etc. Making those profiles work together can be a pain, especially if they have the ability to overlap. I’ve talked a bit about this in my beginner’s guide to Tasker, and I myself use a system of such states which required a bit of tinkering to make work.
A user from the Tasker Google Group forum has come up with a rather brilliant system for handling states. It’s based around a system of current, previous, and next state variables, where it’s possible to trigger profiles based on a series of state changes instead of just individual changes. This allows you to for instance separate between cases where you’re in your car on the way to work and when you’re in your car on the way back from work, simply by creating scenarios that require a certain current state/previous state combination (current: in car + last: home, for instance).
The way this works is that you create profiles for different states, like being in the car – which could be Bluetooth connected. This then sets a variable like %%NEWSTATE to “Car”. You then have a profile that monitors any change in %%NEWSTATE, and runs through its own task. The creator’s version of this task currently looks like this:
- 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
This task includes a bunch of checks that are part of why this system is so powerful. There’s a state lock system that simply stops any state changes if enabled (using a variable). It also stops it if there’s no actual change in the state, which could happen if you reboot your phone, turn Tasker on and off, or simply leave and then reenter the state without another one being active in between.
There’s also a system to check if a state changes too quickly, which is possible because the task records the time that states changed. This is also logged to a file.
Like I said, this is the creator’s version of the state change task, but it shows what’s possible using this system. It adds a layer of intelligence to the whole thing, a layer you don’t have with less sophisticated state change methods (like the one I use myself).
The idea here is that, assuming that it’s a legit state change, %NEWSTATE is transferred into %STATE, and the current %STATE is moved to %LASTSTATE. %STATE can then be used to trigger the profiles that contain the actual settings and actions for each situation, either in itself or combined with %LASTSTATE or other contexts.
It’s really a brilliant system, and one I might have to start using myself. I have to think about whether there are any situations where this would be beneficial, which I’m sure there are. The creator did an awesome job coming up with this, and it’s so brilliant I wish I thought of it myself.
