Catch-22-type problem involving Tasker waiting and sleeping

[Hippo Man]

I have hit a problem that seems to be unsolvable, but perhaps there is some knowledge that I'm missing which could suggest a solution.

I'm running the latest version of Tasker under Android 4.4.4, and I have a set of tasks and profiles which do the following:

If the cell signal level drops below a certain level, go into airplane mode, wait 5 minutes, leave airplane mode, test the signal level again, and then repeat if it's below a certain level.

I do this to conserve battery when I'm in places with no cell signal (the subway, my office, etc.)

This generally works fine. However, sometimes Tasker seems to get swapped out of a "running" state, and the 5-minute wait goes on forever.

Obviously, I can't write a task telling Tasker to wake itself if it's been swapped out for a while, since that task would never get triggered by any profile if Tasker isn't active.

Instead of simply doing a wait for 5 minutes, I have also written a task which performs a wait loop as follows: calculate the time 5 minutes in the future, wait one second, test the current %TIMES value to see if it's greater than this future value. If not, repeat this in a loop until that future time value is exceeded. This doesn't seem to help. The loop doesn't seem to iterate at all if Tasker is swapped out.

I know I could tell tasker to run in the foreground. However, this forces an icon into my notification area. I don't want to see that icon. I don't want any icons in the notification area unless I'm actually getting notified about some event or some error conditions.

Can anyone think of a way to prevent Tasker from getting swapped out without forcing an icon in the notification area, or to solve this problem in any other way?

Thank you very much.

.

[Robert Ryan]

Simply use the "empty icon" as the notification icon while running Tasker in the foreground. No icon will show in the status bar.

The "empty icon" is the first one in the list of choices, ie the one with no picture.

[Hippo Man]

On Monday, February 23, 2015 at 4:48:02 PM UTC-5, Robert Ryan wrote:

Simply use the "empty icon" as the notification icon while running Tasker in the foreground. No icon will show in the status bar.

The "empty icon" is the first one in the list of choices, ie the one with no picture.

Thank you.

Also, what about if I just go to App Ops, select Tasker, and uncheck "Show notifications"? Or will that also prevent the stay-in-foreground behavior?

.

[Robert Ryan]

On February 24, 2015 6:42:28 PM MST, Hippo Man <hippoma...@gmail.com> wrote:
>Also, what about if I just go to App Ops, select Tasker, and uncheck
>"Show
>notifications"? Or will that also prevent the stay-in-foreground
>behavior?
>.

That would also allow Tasker to run in the foreground with no notification.

[Hippo Man]

Thank you again, very much.

.

[bdanders]

To get around your problem with wait actions, I suggest you change your tactics just a bit. Try adding a time based component to your profile triggers. Set it up to run from 00:00 to 23:59 repeating every 5 minutes whenever the cell signal is low OR airplane mode is on. You'll want to come up with some way to disable the profile if you really want to stay in airplane mode, but that should be easy. Then you don't ever have to worry about whether the wait action worked or not.

[Hippo Man]

On Wednesday, February 25, 2015 at 11:05:11 AM UTC-5, bdanders wrote:

To get around your problem with wait actions, I suggest you change your tactics just a bit. Try adding a time based component to your profile triggers. Set it up to run from 00:00 to 23:59 repeating every 5 minutes whenever the cell signal is low OR airplane mode is on. You'll want to come up with some way to disable the profile if you really want to stay in airplane mode, but that should be easy. Then you don't ever have to worry about whether the wait action worked or not.

Thank you very much. I will try that. However, could you explain (or simply point me to appropriate docs or explanation of) how this approach differs from a "wait"?

Wouldn't the time-based profile fail to fire off if Tasker is swapped out, in the same way that the "wait" would fail? Or is there a difference between how Tasker functions when there are time-based profiles and when there aren't?

.

 

[Profajl Nejm]

Hi Hippo Man, i have very similar problems where I createad a loop just like yours that checks if %TIMES matches my time variable (which is calculated at the beginning of the task). I have a perform task action that is supposed to run every 3 hours but lately it has run about 3 times, then waits maybe 12 hours and then above mentioned "perfom task" action runs like 6 times in 2 minutes.

I think that the time context profiles are handled in a different way by the Tasker monitors, altho i don't know how - but i have a profile with a time context and it runs every time. then again it's only set to run once a day at 12.

And in writing this message i am joining Hippo Man in trying to find some info about this :) I thought perhaps I should just set up time profiles, but my actions need to run at different times depending on when i launch the task, so it would be a lot less dynamic that way for me. Is there a way for a task to modify when a profile is supposed to run?

[Rich D]

> Hi Hippo Man, i have very similar problems

It sounds like separate issues. Unless you have tasker set to Not run in foreground in the tasker preferences.

where I createad a loop just like yours that checks if %TIMES matches my time variable (which is calculated at the beginning of the task). I have a perform task action that is supposed to run every 3 hours but lately it has run about 3 times, then waits maybe 12 hours and then above mentioned "perfom task" action runs like 6 times in 2 minutes.

This sounds a bit buggy but the only way to tell is to view the run log to what is running when.. menu  / more / run log

>
> I think that the time context profiles are handled in a different way

They are definitely handled different the  a wait action. 

but my actions need to run at different times depending on when i launch the task, so it would be a lot less dynamic that way for me. Is there a way for a task to modify when a profile is supposed to run?

You can dynamically set a Time context. Check the user guide.  You will need to have 'beginner mode' off in the tasker preferences.

[Hippo Man]

On Friday, February 27, 2015 at 3:03:22 PM UTC-5, Rich D wrote:

You can dynamically set a Time context. Check the user guide.  You will need to have 'beginner mode' off in the tasker preferences.

Yes, but the docs seem to indicate that only the From Time and To Time can be dynamic, not Repeat.

(From the User Guide):

 When not in Beginner Mode, it's possible to specify a global user variable as the source of the From Time or To Time by clicking on one of the rotating-arrow icons.

It would be nice to be able to dynamically change the Repeat value, as well. But I guess this isn't possible.

.

[Rich D]

_user guide.  You will need to have 'beginner mode' off in the tasker preferences.

>
> Yes, but the docs seem to indicate that only the From Time and To Time can be dynamic, not Repeat.

True.. but as usual with tasker there is a way.

I have done this with a few profiles.   Simply set the From: and Till:  to the same variable. Then within the task reset the variable to the next time you want it to fire.

[Hippo Man]

On Saturday, February 28, 2015 at 7:27:18 PM UTC-5, Rich D wrote:

>
> Yes, but the docs seem to indicate that only the From Time and To Time can be dynamic, not Repeat.

True.. but as usual with tasker there is a way.

I have done this with a few profiles.   Simply set the From: and Till:  to the same variable. Then within the task reset the variable to the next time you want it to fire.

Aha! That will work. Thank you.

Also, I'm wondering about the answer to my other question (in one of my earlier messages in this thread).

My original issue had to do with Tasker sometimes being swapped out by the OS, thereby causing my "wait" calls to wait forever. A time context was suggested as a possible solution for this, but if Tasker is swapped out, wouldn't the time contexts also fail to fire off?

Or is there something special about time contexts which make Tasker less likely to be swapped out, or perhaps which could cause it to be swapped back in at the appropriate times?

I'm just wondering if it's worth bothering to refactor my wait-loop based code to being time-context-based, if both would be affected by swap-outs in the same way.

Thank you.

.

[Rich D]

> My original issue had to do with Tasker sometimes being swapped out by the OS, thereby causing my "wait" calls to wait forever. A time context was suggested as a possible solution for this, but if Tasker is swapped out, wouldn't the time contexts also fail to fire off? 

Yes, they would still fail if tasker had not restarted by the time the context was set to fire.

I really do not think using a time context instead of a wait will make tasker any less likely to be killed by android, and i do not think that is what Blanders post was about.

I believe He was pointing out the fact that a time context will survive a tasker restart where a wait will not.

For example if I wanted to wait 10 min and flash "hello"
1. Wait 10 min
2.  Flash "hello"

If tasker is killed then restarted within the ten minutes the task is killed and it will never flash.

However If I set a time context to fire a profile which in turn starts a task that flashes "hello" in ten minutes, then if tasker is restarted within the ten minutes then you will still get the flash. 

[Hippo Man]

On Tuesday, March 3, 2015 at 8:14:09 AM UTC-5, Rich D wrote:

> My original issue had to do with Tasker sometimes being swapped out by the OS, thereby causing my "wait" calls to wait forever. A time context was suggested as a possible solution for this, but if Tasker is swapped out, wouldn't the time contexts also fail to fire off? 

Yes, they would still fail if tasker had not restarted by the time the context was set to fire.

I really do not think using a time context instead of a wait will make tasker any less likely to be killed by android, and i do not think that is what Blanders post was about.

I believe He was pointing out the fact that a time context will survive a tasker restart where a wait will not.

...

OK, I understand. Thank you.

So, the key is indeed simply to keep Tasker from getting killed by the OS.

In my case, the exact times are not important, so the wait-based methodology is good enough for me.

.

 

[Hippo Man]

Follow-up:

I have noticed that even if I keep Tasker in the foreground by means of using its notification icon, I often find my Wait calls taking much, much longer than specified. It appears as if the device is sleeping and preventing Tasker from running, even when it is in the foreground.

This raises the following question: is there a way that I can run something on my device which is not, itself, affected by device sleeps and which which will force my device to wake up periodically?

For example, it might be a shell script that I initiate during device start-up, something like this:

while true
do
     /invoke/some/command/which/forces/my/device/to/wake/up
     sleep 300  # ... assuming that this is not inhibited by the device sleeping
done

This would theoretically cause Tasker (and everything else) to come to life again, and for Tasker's Wait calls to continue, if the device had previously gone to sleep during a Wait.

Any ideas?

.

[Rich D]

> I have noticed that even if I keep Tasker in the foreground by means of using its notification icon, I often find my Wait calls taking much, much longer than specified. It appears as if the device is sleeping and preventing Tasker from running, even when it is in the foreground.

Can you provide a example?  A exported task description with a copy of the run log?

[Scott Miller]

I'm not sure this is exactly what you are looking for, but I used to run this simple profile to keep my device from going into deep sleep. I had a requirement to be able to receive email overnight because of being on call. Before doing this, I wouldn't get the critical email until I woke up the next morning and looked at my phone. This simple profile using secure settings solved the problem for me.

Profile: Prevent Deep Sleep (58)
Enforce: no Notification: no
Time: From 23:00 every 30m Till 06:00
State: Power [ Source:Any ]
Enter: Prevent Deep Sleep Enter (55)
A1: Secure Settings [ Configuration:Screen Dim
1 Second Package:com.intangibleobject.securesettings.plugin Name:Secure Settings Timeout (Seconds):0 ]

You'll notice this doesn't use a wait to make the loop.It's a repeating context and was very reliable. Perhaps something similar might help you.

Scott

On Apr 15, 2015 9:35 PM, "Rich D" <ricp...@gmail.com> wrote:

> I have noticed that even if I keep Tasker in the foreground by means of using its notification icon, I often find my Wait calls taking much, much longer than specified. It appears as if the device is sleeping and preventing Tasker from running, even when it is in the foreground.

Can you provide a example?  A exported task description with a copy of the run log?

--
You received this message because you are subscribed to the Google Groups "Tasker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/d/optout.

[Hippo Man]

On Wednesday, April 15, 2015 at 9:36:00 PM UTC-4, Rich D wrote:

Can you provide a example?  A exported task description with a copy of the run log?

Such an example is not easy for me. I have a dozen or so cooperating contexts which make use of an even larger number of tasks.

What I do notice, however, is that there are long periods where nothing gets written into Tasker's logs, and this seems to correspond to my device being asleep. This is why I'm looking for some sort of "external" method (i.e., not involving Tasker) to periodically wake up my device for a short time, so my tasks can continue to do their thing.

.

[Hippo Man]

Thank you!

I will try this, with a repeat time of 5 minutes.

Question: do you think I need a "Power" context or something other than simply the "Time" context, or would this work equally well if it only makes use of a "Time" context?

Anyway, I'll check it out, and I'll report my results in a day or so.

On Wednesday, April 15, 2015 at 10:04:19 PM UTC-4, Scott Miller wrote:

... This simple profile using secure settings solved the problem for me.

[Scott Miller]

I only included the power context because I didn't want it running if I took my phone and responded to a call, hence it would be on battery. In that situation it wasn't necessary to be running.

Scott M.

--

[Hippo Man]

On Thursday, April 16, 2015 at 1:32:18 PM UTC-4, Scott Miller wrote:

I only included the power context because I didn't want it running if I took my phone and responded to a call, hence it would be on battery. In that situation it wasn't necessary to be running.

OK. Thank you.

I have put something like this in place on my device, and so far, it's working fine. I'll report back with an update after a day or so.

.