2

Allow multiple conditions of the same type, soecifically locations

The "location without tears" informs the user that low power conditions must be met before high power conditions are tested.

It would be great if the low power and high power conditions in the same context could be net based and gps based *location* conditions.

For example, two location geofences around the same center, a larger radius with net only, and a smaller radius with gps. The smaller gps radius would only be checked if the larger net only radius was already matching.

This would also be generally useful for any type of condition to relax the current restriction. Another example is for a time of day condition. One could say time of day between 0900-1700 AND time of day NOT (invert) between 1200-1300. Currently you can only add ONE time of day condition.

Follow

2 replies

Votes Newest Oldest

I'm upping this.

I 100% agree with OP's thought :

But creating 2 profiles to use 2 different time conditions (time range a excluding time range b) and designating one of those (or a 3rd) as "the profile that actually does the thing" is, well, cumbersome.

Basically, having multiple profiles to do actually only ONE "job" is not elegant (OP's wording: cumbersome), at least as per OP's use-case. Not only not elegant, it also makes user's Tasker's interface unorganized (e.g. in a long list of profiles, up to which profile do profiles for one "job" end, and from which profile does another semantically separate "job" start, etc.).

Also, having multiple contexts of the same type is already possible in some other contexts. What I personally use is the "Wifi connected" state. In there, user can define multiple Wi-Fis (via SSID or MAC) with OR relation. That way, the profile can become active, either when Wi-Fi A is connected, or Wi-Fi B, or Wi-Fi C, and so on. Why don't apply this concept generally, especially with the Location context?

Having multiple Location contexts in the same profile can also be useful in this use-case : When user semantically groups multiple different locations as one same entity. E.g. when user has multiple "homes". Elegantly, there should be only one Location context entity called "Home", but it contains multiple locations, e.g. in city A, city B, city C, and so on.

With me personally, checking locations can be done via "Wifi connected" state and via Location context. When I'm implementing with the "Wifi connected" state, I can elegantly define multiple locations with only one single context. BUT when implementing with Location context, I can't, and therefore need to create multiple profiles. I hope you can see the inconsistency. Now, I have a use-case where I need to have multiple Location contexts and can't do a workaround via the "Wifi connected" state. (I'm aware that other workarounds are possible, but they're not elegant, as already mentioned in the 3rd paragraph.)

I guess, actually quite everything can be done in Tasker with workarounds. But if many things can be done just easily (the mentality of "it just works"), then maybe Tasker can be even more appreciated by many new users, which in the end can only do good for Tasker. Peace.

Comment

That does help in a lot of cases. And it is *possible* in probably all cases using that method.

But creating 2 profiles to use 2 different time conditions (time range a excluding time range b) and designating one of those (or a 3rd) as "the profile that actually does the thing" is, well, cumbersome.

What is the reason for the limitation anyway?

I'm not sure since I wasn't the one to implement it :) But thanks for the suggestion.

Reply