Killing a task from another task

[Oliver G. Parker]

Hi, 

I'm a little new to Tasker and still getting to grips with it, so the answer to this question may be that I am misunderstanding something. However I'll shoot ... 

I have a task called "Make Data Mobile" that is intended to run when I am away from a WiFi network (i.e. only have mobile data) which will turn mobile data on for one minute in every ten, mainly to reduce battery use. 

The task does this (in pseudocode): 

Make Data Mobile

1- Turn on data (using command svc data enable)

2- Wait 1 minute

3- Turn off data (using command svc data disable) 

4- Wait 9 minutes

5- Go To Step 1

This task is called whenever I leave a WiFi network. 

I want to turn on mobile data whenever I turn the 'phone screen on, so I have another task called 'Data On', like this; 

Data On

1- Turn on data (using command svc data enable)

2- Stop task "Make Data Mobile"

I also have another task called 'Data Off' which runs when the screen is off, like this; 

Data Off

1- Turn off data (using command svc data disable)

2- Start task "Make Data Mobile"

All well and good, but the task "Data On" doesn't kill "Make Data Mobile", meaning the data still toggles on and off at the defined intervals. If you look at the Run Log you can see the task "Data On" is called and starts, and action 1 runs but action 2 doesn't. However if you run the task "Data On" manually (i.e. press the 'play button' at the bottom of the screen) it does run correctly and kills the "Make Data Mobile" task. 

What am I doing wrong? Given that the manually-run task runs with a higher priority than a called task then I am guessing it is doe to task priorities, which are all set at the default level (5, I think). If this is the case then a solution would be for the 'Data On' task to be called with a higher priority than the 'Make Data Mobile' task, but I don't think this is possible (both are called from the same profile which checks to see whether there is a WiFi connection and whether the screen is on, and calls 'Data On' as an entry task and 'Make Data Mobile' as an exit task and I don't think you can set a profile to call an entry task with a higher priority than an exit task). 

I have a workaround, but it's a little clumsy and this solution (above) would be more elegant if I can make it work. Can anyone help? 

Thanks, 

Oli. 

[Rich D]

I have a task called "Make Data Mobile"

To post your profile or task here...  Long press on the profile or task name / ( 3 dot menu with 4.0+ ) export / export "DESCRIPTION" to clipboard (not XML)

Any linked tasks will be exported with the profile they are linked to..

To be able to export, The beginner mode needs to be off and the profile needs to be named by you (Not the Tasker listed name.  Tasker will list your profile with the context name if you have not given it one).

Given that the manually-run task runs with a higher priority than a called task then I am guessing it is doe to task priorities,

Correct.

Without testing I my first thought would be to say you have 2 options.

1. Invert the profile context - reverse the enter and exit tasks - deselect the 'enforce task order' option in the profile properties.

2. Instead of running the actual exit task use a preform task action to set a lower priority on the exit task. 

I would pick option 2. 

Have a read of this thread. I 

https://groups.google.com/forum/m/#!topic/tasker/qInYbV1L2Jo

[Rich D]

Of course you could also use 2 separate profiles and use the display on / OFF 'Event' context. 

[Rich D]

Option #4 - have task stop itself.

> 1- Turn on data (using command svc data enable)
> 2- Wait 1 minute

Stop - if %PACTIVE ~ *,name off profile,*

> 3- Turn off data (using command svc data disable) 
> 4- Wait 9 minutes

Stop - if %PACTIVE ~ *,name off profile,*

[Oliver G. Parker]

RichD, 

Thanks for your answers - it looks like there are several ways to solve this one! I'm not entirely sure I fully understand any of them though. Would you mind if I ran through them with you? 

Posting a copy of the task is a good idea but I've made it work (really badly) using a variable; the variable is set depending upon whether there is a need for mobile data and this can cause the 'Make Data Mobile' task stop itself. But it's clumsy and doesn't work well and I think that posting the details on here wouldn't help, so I won't. 

Option 1 - "Invert the profile context - reverse the enter and exit tasks - deselect the 'enforce task order' option in the profile properties."

I don't understand this at all, sorry to be slow. What does deselecting "Enforce Task Order" achieve? 

Opt2 - "Instead of running the actual exit task use a preform task action to set a lower priority on the exit task."

Do you mean using a task to call another task of another priority? I thought about this to stop the "Make Data Mobile" task, but what happens in the following scenario?; 

- There is a 'Make Data Mobile' task of priority 5 running. 

- You call another task called 'Data On', with the same priority (5), which calls another task called 'Data On2' of priority 6 which stops 'Make Data Mobile'. 

Does 'Data On2' run at priority 5 (the same as that of the calling task) or at priority 6? If it does then this would be a solution. Was this what you were suggesting? 

Opt3 - "Of course you could also use 2 separate profiles and use the display on / OFF 'Event' context."

Not sure I follow this but it occurred to me that you could use two profiles with the same criteria (i.e. display on and no WiFi connected) and use one of them to call the 'Data On' task at priority 5 as an entry task with no exit task, and use the other one to call the 'Make Data Mobile' task at a lower priority (4). Would this work? Is this what you are suggesting? 

Opt4 - "Option #4 - have task stop itself ... Stop - if %PACTIVE ~ *,name off profile,*"

This looks elegant and explores bits of Tasker I don't know about - I think I need to do some research. 

Thanks very much for your help. I think I have some more playing around to do! 

Oli. 

[Rich D]

. 

Option 1 - "Invert the profile context - reverse the enter and exit tasks - deselect the 'enforce task order' option in the profile properties."

I don't understand this at all, sorry to be slow. What does deselecting "Enforce Task Order" achieve? 

I do not care for this one and I am not even sure it would work given your contexts. But in theory inverting the contexts would allow you to reverse the enter and exit task so now you would be killing the enter task with the exit task. The advantage to this by default a exit task has a higher priority then a enter task. But to allow this to work you need to deselect the 'enforce task order'. The link I posted explains the 'enforce task order' and why your original approach was failing. If there are parts of that post you do not understand feel free to reply to it and I will try to answer them on that post. Understanding this is key to understanding how priorities work in a state context profile. 

Opt2 - "Instead of running the actual exit task use a preform task action to set a lower priority on the exit task."

Do you mean using a task to call another task of another priority?

I thought about this to stop the "Make Data Mobile" task, but what happens in the following scenario?; 

- There is a 'Make Data Mobile' task of priority 5 running. 

- You call another task called 'Data On', with the same priority (5), which calls another task called 'Data On2' of priority 6 which stops 'Make Data Mobile'. 

Does 'Data On2' run at priority 5 (the same as that of the calling task) or at priority 6? If it does then this would be a solution. Was this what you were suggesting? 

No, I was suggesting doing a preform task action in your exit task, this would start your Make Data Mobile loop task at a priority 4 so now your Data On enter task wich is at priority 5 will run and stop the Make Data Mobile task

Opt3 - "Of course you could also use 2 separate profiles and use the display on / OFF 'Event' context."

Not sure I follow this but it occurred to me that you could use two profiles with the same criteria (i.e. display on and no WiFi connected) and use one of them to call the 'Data On' task at priority 5 as an entry task with no exit task, and use the other one to call the 'Make Data Mobile' task at a lower priority (4). Would this work?

I do not think so, This could start 'Make Data Mobile'  while your display was on.

Is this what you are suggesting? 

No. In the 'State' category of the contexts under 'Display' and there is a 'display on' and a 'display off' context. So you would use a (display off)+(no WiFi connected) profile to start the 'Make Data Mobile' task at priority 4 and a (display on) profile to start the 'Data On' task at priority 5

Opt4 - "Option #4 - have task stop itself ... Stop - if %PACTIVE ~ *,name off profile,*"

This looks elegant and explores bits of Tasker I don't know about - I think I need to do some research. 

Thanks very much for your help. I think I have some more playing around to do! 

This would be the best option as it does not rely on properties to stop the task. Let me know if you have any more questions. 

[Oliver G. Parker]

Rich, 

Thanks again for your help. I'm a little short of time lately to poke around with this so haven't experimented much with it but I did try the set-up I suggested in my last post, to wit I have two profiles with the same criteria (i.e. display on and no WiFi connected) and one of them calls the 'Make Data Mobile' task at priority 5 as an exit task with no entry task, and the other calls the 'Data On' task at priority 6 as an entry task with no exit task, and it seems to work. I have another profile that calls the 'Make Data Mobile' task when WiFi connection is dropped and all is well. I need to give a little more thought to how it will handle data connections when it connects to BlueTooth (as it does in a car) but that's another problem to be sorted out another day. 

I think that the solutions you have suggested as more elegant and I'll hopefully find time to have a look at them in more detail next week (and may well have more questions then) but many thanks for your help in the meantime. 

Oli. 

On Thursday, 6 April 2017 08:54:42 UTC+1, Oliver G. Parker wrote: