Tasker Hangs at Wifi Action, When Another Wifi Action was Previously Carried Out in Another Task

taskerproject://H4sIAAAAAAAAALVTy27DIBA8J19hca4CS2wgEkZq1UtvVZUfQDaK3IdtYervL4tplaSOeurFjHdW88CyPtrpzflHG2wx+ZqQop27mgApwlwTsWM7YMRsN/rZD6+uCWlpjJiRYnY14UhudNPa4AwIWSkhJVcMpKbLEOnefjjz8HkqXtw4+KBpGiATunYywKs74ELT9BbNaHZDjAGTa4ggbq4ZlpxX/NzQndPqAIopTd0P3bXoqWk8U7wY5ggxVQ41+s4AY5oiwMF9E7qhTylsE3J1mZLEKEPrTIlyCaXZU7/clPUn3LbvNWGEJi26iKWa2G2lo1jriI/bHQ+lUJj4qqO47Mj/uSP86nitCyu6IOEP3VgtX98FDd+26zTPdLVG7jO5v/lZlnP5N8z2C9zqUkYpAwAA

This "hanging bug" also happens here :

- After invoking action Status Bar - set collapsed.

- When, after invoking action Alert Menu for the 1st time, then directly invoke that action Alert Menu again for the 2nd time with Collision Handling - Abort Existing Task.

Also, this helprace website isn't usable in my phone: I can't log in, can't reply / comment.

Also, whilst somewhat functional, isn't that data URI format kinda weird? Wouldn't the good old XML format for example be more favorable?

Also, Tasker's Stop All Tasks under Monitoring - Running Tasks often doesn't work. When user self-creates Stop action though (so-to-say a "DIY Stop All Tasks"), it can always successfully stop other tasks.

Also, action Perform Task behaves like it stops with error, if the task that is to be performed is aborted by Collision Handling. BUT, action Perform Task doesn't have the option Continue Task After Error. The task, in which an action Perform Task is located, then can't continue. This is impractical. It of course can be mitigated with IF, but whatever.

Feel free to put those in backlog.

Hi. The URI format is very handy for me. Makes it very easy to import it from my PC without having to create additional files. :)

About the project you provided: how are you running the tasks exactly? Just going into T1, running it, then going into T2 and running it too?

Or do you have another task that runs both? Thanks in advance.

"About the project you provided: how are you running the tasks exactly? Just going into T1, running it, then going into T2 and running it too?

Or do you have another task that runs both?"

This: Just going into T1, running it, then going into T2 and running it too.

Having another task that runs both (sequentially via the action Perform Task) would also yield the same behavior.

Peace.

Hi again Randy. I've tried reproducing this many times but unfortunately it does work normally for me so I can't reproduce the issue...

What Android version/device are you using exactly? Did you already install the latest version of the Tasker Settings app?

Thanks in advance

Hello. Also with me, once in a while the hanging problem doesn't come. But this "hanging bug", so I mention it throughout my Tasker documentations, very well exists and is the most often cause of my automation not working. Frustrating because it can be unpredictable. I've googled around and apparently some other people also have this issue. As I've mentioned earlier, there are also some other things/actions that can trigger the hanging bug, but the Wifi action is seemingly the most prominent with me. The hanging bug has also happened with the actions of setting NFC on/off, setting airplane mode on/off, inquiring bluetooth connection information (paired devices), and the Tasker function to inquire whether music is playing.

I've observed once or twice, that Tasker straight out "skipped" the Wifi action and continued doing the rest of actions in the task. The task was done beautifully, except the Wifi wasn't turned off. I don't have the option continue if error checked. So apparently this is also a possible behavior.

Currently I've set Tasker in Preferences to be able to queue 20 tasks, although there will never be a single point of time where 20 tasks will be running in parallel. The preference Reduce Resource Usage has always been disabled and the phone should be more than capable to handle Tasker in terms of computing power. The preference reliable alarm is set to be enabled when screen is off (I hope my interpretation of 'screen is off' is right). All battery optimization measures in device are disabled for Tasker and Tasker Settings apps.

Device OnePlus CPH2399 ("Nord 2T")
Android 12 – Stock ROM, everything original, not rooted or anything, nothing crazy (OxygenOS 12.1)
Tasker version 6.0.10
Tasker Settings app is installed, version 1.5.0 .

If you also personally use Tasker for your everyday automation, I'll be bewildered if you've never encountered such hanging bug. Have some 15-20 profiles with 10-15 tasks (in total) across 2-3 projects, most of the tasks contain 20-40 actions (not every single action will be carried out, there are many IF's) doing various automation things including turning Tasker's profiles on/off and stopping Tasker's tasks for efficiency. If you then still never encounter a single hanging bug, yeah, probably a OnePlus / Oxygen OS (recently they've changed it to Color OS?) thing.

Although it'd be worth to mention, that my Tasker projects could be not as "simple" of an automation. Maybe a simple automation that Tasker can handle perfectly would be only e.g., if connected to home Wi-Fi then turn up volume, if disconnected then turn down volume. My automations could be not that simple, in that e.g. there are 1 or 2 tasks kept in loop for 30 minutes (checking every e.g. 5 min.) to maintain that Wi-Fi doesn't get turned off and airplane mode doesn't get turned on, while another "main task" does another automation that's a once-and-done thing. I'm also a little bit of a coder and have made sure (through hours if not days of debugging, testing) that there's no coding error e.g. there's not a single occurrence where Wi-Fi is being turned on, and then again off, and then again on, and so on and so forth, so that Tasker / Android will be in an error/exception state.

Just all things considered in short : I'll be bewildered if you've never encountered such hanging bug, not ever once, if you also personally use Tasker for your everyday automation.

After googling around, quite some other people also find Tasker to be generally unstable. E.g. when there are many profiles/tasks/projects, Tasker's interface can become unstable, in that e.g. some profiles or its tasks/contexts can't be selected/tapped or turned on/off.

I can say that I've never experienced that hanging bug and I have a pretty complex setup myself that I use every day.

I do not have tasks that are kept in loop though. Can you maybe share why you're doing those loops exactly?

Maybe you could use the Time context or the Tick event instead to trigger tasks from time to time? And if you do that, let me know if the Wifi action doesn't get stuck anymore...

Sorry, really wish I could reproduce the issue so I could help you out!

Hello, first thank you for your interest in helping me out !

Then maybe Tasker could indeed have some difficulties when running multiple processes (e.g. multiple looping tasks or tasks with Wait actions). I'm not familiar in how troublesome this would be to optimize within Android app development. With my Tasker projects, there are mostly at max. only 3 tasks running in parallel, which makes me wonder that this actually shouldn't be challenging at all for the phone's computing resources.

Why I'm doing the loops : Let's say I'd like to do this kind of automation: When I'm not at home, check every half an hour or so to turn off Wi-Fi, if no Wi-Fi AP is connected.

Yeah, I guess I could develop it all again with the Time context, thank you very much for your suggestion. But currently I'm not really in the mood to re-develop everything, then testing, debugging etc., with this new concept incorporating the Time context. Currently I've gotten my setup working with a very weird workaround I've found. The workaround is to kick-off a task in parallel with a Wait(1 sec) before every action that can trigger the hanging bug. Maybe someday I could share everything exactly with you with some information deducted to make very sure that it is also reproducible with you, and also so that you can see how that weird workaround I've found can mitigate the issue.

Although, aren't the Time context (with 'every', e.g. every 20 min.) and the Wait action handled similarly in the backend, maybe with that reliable alarm thing? If not, maybe the Wait action could be made to work similar to the Time context, if the Time context is indeed more reliable. Because using the Wait action, it can be more granularly programmed (or at least easier to program), as opposed to using the Time context. E.g. Wait 20 min. when this, but 10 min. when that, etc. But I could also be in the huge wrong if I treat Tasker as if it was a "programming language" ; although, how frickin awesome would that be, though.

Also, with me, the loops / Wait actions are most probably not the single cause of that hanging bug ; It could also very well be, because there's a chain of tasks (though not that many, around 3 - 5 at max.) whilst Tasker still needs to monitor multiple profiles' contexts. Again, seemingly shouldn't be a thing that's challenging for the phone. One day I'll share everything, though only if that day I've not already migrated to a Pixel phone, where everything just works.

You're right, for longer waits it already does it with alarms instead of actively waiting in the task. I just find it cleaner to use the "Time" context myself so there are no pending tasks running at any time 😅

Just so you know, I didn't create the task queueing mechanism myself: it was the previous Tasker developer that did that. 

I'm simply trying to work with what I have because otherwise I would have to re-do the all thing from the ground up.

Looking at the code though, there could be some situations where running one action could not let another one run. Check out this part from the documentation: https://tasker.joaoapps.com/userguide_summary.html#actiongroups

Does that maybe shine some light on the issue?

"because otherwise I would have to re-do the all thing from the ground up."
Yes, that's what I'm afraid of. Could be worth it, idk, your decision as the owner.

I've also studied that part of the documentation. This is probably the relevant part: "only one action from the same action group can be executed at once to prevent interference"
That still wouldn't clear up why Tasker hangs, instead of, idk maybe triggering an error. And more importantly, the doc says "at once", so the next action from the same action group would still be executed afterwards, so-to-say not "at once", but "in turn". Also, I think the doc would explicitly mention, if only 1 action from the same action group can be executed, whilst then the other actions will get terminated for instance. Also, the "Normal" action group contains "all the other actions", so it wouldn't make sense if Tasker would only let one single action from that huge group.

So in other words, running 1 action would still let another one run, but just not all "at once". Although, this could be where the bug lies in in the task / action scheduling.  That concept could be not implemented well in Tasker's backend code. Tasker could still try to run many actions (almost) at once, hence it finds itself with some occasions in an unhandled error/exception state. I think it'd better, if Tasker just implements it in a simple manner (not trying to mimic a very complex programming language), in that every action is executed really really one-by-one, in that action 3 really starts first after action 2 is finished, and action 2 really after action 1 is finished, and so on.

Peace.

When it says that it can only run one of those actions at once it means that the other actions will wait until the action completes to execute, so that could explain why it hangs: it could be an action from a group that's waiting for another action from the same group to complete...

Yes, but not the case with me. Let alone the fact that, in my case, Tasker hangs for at least 30 min. or so at an action ; There is no other competing action that doesn't finish for 30 min. (except Wait action). My Tasker project could be huge, but it's not that huge. The action components are only tiny single actions like turn on/off Wi-Fi, bluetooth, airplane mode, setting audio volume, things like that.