Controlling profiles from other profiles in Tasker
The more stuff you have going on in Tasker, the greater the chance that profiles will start interfering with one another. I ran into a few issues this week with my profiles, following the addition of a calendar-based school profile.
Up until now, I’ve had an outside profile whose context is an inverted WiFi Connected state, meaning that the profile is active when I’m not connected to certain WiFi networks. The opposite of that profile, which would then be “home,” doesn’t actually exist- instead it’s simply the default that Tasker reverts to when the outside profile is not active. That setup has worked well since I’ve only needed those two states, as well as a few others that don’t interfere with the two base modes due to them not manipulating the same settings.
With the addition of a school profile, that changed. The school profile actually manipulates some of the same things as the outside profile, and as such it isn’t practical to have both active at the same time. In fact, it would be best if they were mutually exclusive. Since they’re triggered by different contexts, however, they’re not mutually exclusive by design.
There are several methods you can use to make them so, but the most apparent aren’t always the best. Perhaps the most straightforward method is to simply add an additional context, one that is the inverted context of the profile you don’t want to interfere with. As an example, I could give my outside profile another context that is an inverted calendar entry in the school calendar, which would basically mean that the outside profile’s trigger conditions wouldn’t be fulfilled when the school profile’s conditions are. The one potential issue you might run into with this approach is to have exit tasks interfere with entry tasks. As it happens, that was an issue with my profile setup.
An alternative way of doing it is to turn profiles on or off using the Profile Status action in the action category called Tasker. This enables or disables profiles completely, rather than just stopping their contexts from being met. It’s a great way of doing things, and its main issue is that you need one action per profile you want to enable or disable. For things like my sleep mode, whose status decides the status of multiple other profiles, it’s not an ideal method.
The final method, which I use for both my sleep mode and my school profile, is to use a variable as a state context and then write different values to that variable in order to control other profiles. When my school profile activates, it sets the variable %School to 1, and when it deactivates, it sets it to 0. In order for the outside profile to be activate, %School has to be 0. This is in many ways similar to just adding an inverted context like in the first method I mentioned, but it has several advantages.
First off, it allows you to combine several contexts into a single context. One example would be if one of the mutually exclusive profiles is using several contexts in itself, meaning that each of those contexts would have to be used in their inverted form in the other profile in other to make them mutually exclusive. If instead the multi-context profile sets a variable, you’ve reduced the number to one. Another example would be if you had both a work and a school profile, where those two themselves are by definition mutually exclusive, but not so when it comes to an outside profile. If the work profile is GPS location based and the school profile is calendar based, you would need both those two contexts in their inverted form as part of the outside context in order to have it work. Having both of them set the same variable, like %Notouside, would limit the number of contexts needed in the outside profile.
The variable method also allows for triggering profiles using different independent triggers. Adding more than one context to a profile means that both have to be true to trigger the profile, not one or the other. To create a profile that can be triggered in multiple ways, it’s easiest to simply make it trigger on a variable, and create multiple profiles which manipulate this variable. My sleepmode, for instance, is technically triggered by the value of the variable %Sleepmode. That variable is then manipulated by a second profile that triggers on AC charging, as well as a task (not a full profile) that’s part of my DIY voice assistant, Nelly. This allows me to control the sleep mode profile using both the voice assistant to manually toggle it, and using AC charging as an automatic trigger. Moreover, the value of %Sleepmode also controls other profiles which change their behavior when I’m sleeping.
Using the variable method also has one very nice advantage that the other two methods don’t: The ability to control actions as well as profiles. Since you can prevent actions from running by adding IF conditions to them, using variables to control profiles also allows you to use the same variables for controlling individual actions. As an example, let’s say you have an outside profile, a work profile, and a school profile. The exit task includes several actions that run when the outside profile is deactivated, however you want to differentiate between it exiting because you’re arriving at work and it exiting because you’re at school. You would then simply use variables for work and school, like %Work and %School, and limit which exit task actions run in the different situations by using the if condition. An action that shouldn’t run if you exit outside mode into work mode would for instance have the IF condition “%Work matches 0”.
Finally, the variable method allows you to let entry tasks run before exit tasks. If two profiles have the same context, but one being inverted, then one profile would activate as the other is deactivated. Normally, the exit task for the deactivated profile would then run before the entry task for the activated profile. By having one profile deactivate because the other profile sets a variable as part of activating, that profile’s entry task will run first by definition, since it’s the task that controls the other profile, not the context.
My location profiles now work quite differently from what they used to. There’s now a dedicated home profile, which is WiFi Connected-based. This one runs several actions on entry, including setting %Home to 1, and only sets %Home to 0 when exiting. The school profile is very much the same, being based on calendar entries, and setting %School to 1 on entry, 0 on exit. It does however have a second context, Variable Value %Home matches 0. The outside profile now has two Variable Value contexts, %Home matches 0 and %School matches 0.
The home profile is here absolute. When it’s active, none of the other two profiles are, as they’re both restricted by the %Home variable. This means that the school profile takes into account if I’m at home or not, meaning it adapts itself to situations where the calendar entry doesn’t match reality (short days, for instance). The outside profile is only active when the other two are not, making all three mutually exclusive.
As a final note, I want to elaborate on the use of 0/1 instead of on/off as variable values. In my current scenario, it doesn’t really matter, but using numerical values has the advantage of being compatible with math. If you have multiple variables that can be 0 or 1, it’s actually possible to control profiles and tasks using math. For instance, a profile that requires 500 other profiles to be off can be controlled with a simple context that requires the sum of those profile’s variable settings to be 0.
Dealing with profiles that work together can often be a problem in Tasker, and hopefully this article helps to give some idea of how to navigate the mess.
Make sure to check out the rest of our Tasker articles by clicking the Tasker tag below
