Expression freezes

[digitalstone]

That's true Desmanto, i indeed used action sleep for the longest time and don't recall any problems with that.
I shall replace those sleep-blocks accordingly and come back to report on it.

My example was a very simple one of the flow i actually am using.
It's actually 2 flows:
1. The system-flow that automatically calculates my next upcoming work-break (from whatever time that may be, i have irregular work shifts), while offering the option for executing the raw work-break profile with manual input.
2. The raw work-break profile that interprets still if on automatic or coming in as manual input from the system-flow. And then sets the actual settings. Such as: airplane mode on/off.

I also indeed build in a timeout tolerance so that it doesn't exactly end when my break is over... my work-timeout time values are within a glovar and the script is setup that i can change/add/remove times within that glovar and all will respond accordingly.

[Desmanto]

The minimum sleep is 5 minutes, when multiply by 3, will give total 15 minutes. But for the longest is 30 minutes, that will give total 1,5 hours sleep, kinda inefficient.

The best solution is to replace those timeout with another glovar date/time. When it detects the first execution, it will give the first notif, addMinutes to the glovar date/time. Second exe second notif and finally third exe and notif. You can save the state of the number execution in another glovar map. Or there is a way to save the toggling state for n-th execution by nesting condition execution count; thus no need glovar.

Current solution without modifying too much (because you are using the flow), is to split out the sleep. The simplest way is to use the script once in the beginning, to calculate the sleep needed

Code: Select all

sle = minTolerance*1000*60;

Then use {sle} in the Action sleep for 3 times. Or you can simply remove the script altogether, do the calculation in the main flow and save the sle value in the glovar map.

[digitalstone]

Wait a second. Can i just back up a few?
I'm still not sure about the difference between the sleep action and the sleep script.

I can't just use the sleep action for this? That would seem the easiest way to me besides the script, instead of storing glovars and doing extra calculations etc.

Does the sleep script cause CPU cycles while it's running?

[Desmanto]

Ok. As Martin said that the script/expression has global lock. So if you use sleep() inside script, it will travel across time and space to halt all of your other script/expression in another flow; which is something we don't want to happen. Using Action - Sleep, doesn't suffer from this global lock, thus it is a must to use a separate sleep action for delay longer than several seconds (or minutes). Sleep() function inside script mostly useful in Control UI, where delay is a must. And most of the sleep are very short, in the count of hundreds of ms.

You can still use Action - Sleep to replace the script. There are 3 scripts there, all using sleep() inside the script. You can replace it with 1 script which set the sleep value and 3 Action Sleep using the calculated variable. That way, you won't be halted by the script when you have another flow which has script/expression running too.

The reason I avoid Action - Sleep for a longer period is because the wakelock. As the documentation also state that we should uncheck keep device awake when using it longer than one or two minutes. But as I remember, unchecking this option will cause some problem in several phones, especially the ones that has a very aggresive power saving feature (huawei, xiaomi and its kind). So we tends to check the keep device awake, preventing the CPU from going to sleep, creating unnecessary wakelock which can be avoided.

But if your main flow already utilizing something that require the device to be full awake during the sleep (full brightness or stay awake), the sleep might not give any impact to the battery life anymore. Creating glovar date/time will require more effort and seems not worth it.

In fact, I also don't know the battery consumption for a flow which only sleep for a long time. It takes a long time to test it and the result is very easy to be skewed by other factors. I tried to amplify it, by using 10 flows which all sleep at the same time, and still didn't found any big drain as well. Maybe should try another method to test this out. I just see it from the inefficiency part; any flow that is running but doing nothing useful, should be considered as inefficient. So far, no one prove the otherwise (that sleep doesn't consume a noticeable battery life), so I am holding on the same assumption, that it is better to use glovar date/time rather than long sleep.

[digitalstone]

Ok. As Martin said that the script/expression has global lock. So if you use sleep() inside script, it will travel across time and space to halt all of your other script/expression in another flow; which is something we don't want to happen. Using Action - Sleep, doesn't suffer from this global lock, thus it is a must to use a separate sleep action for delay longer than several seconds (or minutes). Sleep() function inside script mostly useful in Control UI, where delay is a must. And most of the sleep are very short, in the count of hundreds of ms.

You can still use Action - Sleep to replace the script. There are 3 scripts there, all using sleep() inside the script. You can replace it with 1 script which set the sleep value and 3 Action Sleep using the calculated variable. That way, you won't be halted by the script when you have another flow which has script/expression running too.

The reason I avoid Action - Sleep for a longer period is because the wakelock. As the documentation also state that we should uncheck keep device awake when using it longer than one or two minutes. But as I remember, unchecking this option will cause some problem in several phones, especially the ones that has a very aggresive power saving feature (huawei, xiaomi and its kind). So we tends to check the keep device awake, preventing the CPU from going to sleep, creating unnecessary wakelock which can be avoided.

But if your main flow already utilizing something that require the device to be full awake during the sleep (full brightness or stay awake), the sleep might not give any impact to the battery life anymore. Creating glovar date/time will require more effort and seems not worth it.

In fact, I also don't know the battery consumption for a flow which only sleep for a long time. It takes a long time to test it and the result is very easy to be skewed by other factors. I tried to amplify it, by using 10 flows which all sleep at the same time, and still didn't found any big drain as well. Maybe should try another method to test this out. I just see it from the inefficiency part; any flow that is running but doing nothing useful, should be considered as inefficient. So far, no one prove the otherwise (that sleep doesn't consume a noticeable battery life), so I am holding on the same assumption, that it is better to use glovar date/time rather than long sleep.

Alright thanks Desmanto, Now i'm following again.
I'm sorry but i'm living the sort of life that i have very little time on hands.
Reading a single post of the forum goes by small parts at a time, so that's probably i didn't follow the earlier posts.

The calculation of times and durations is already being done beforehand of the actual work-timeout flow (the one with the 3x sleep), even if done manually.
I shall just replace the sleep-script with the sleep-actions then, since i leave my screen mostly on during breaktime.

The reason i switched to the sleep-script method is (i believe) that some time ago you said something about, that you always are using the sleep-script instead of sleep-action.
And so i tried that and it worked (little did i know about the side effects later).
Anyway, i shall update my flow and report later.

Thanks again.

[Desmanto]

)Yes, I remember I ever post about combining the next sleep action into the script before, to save single element execution. But probably I am not clear enough that I only use small sleep value inside script, not until minutes. (sorry for the confusion). And when I say script, it includes Control UI as well (which is the majority part where I use sleep() function). For sleep more than 1-5 minutes, my previous link for the concept applies; using glovar date/time as the timeout replacement.

It takes more time to design the first concept of using glovar date/time, than just simply use sleep action. when later you need a longer sleep time, glovar date/time is a must then. For now, since the screen is always on anyway, sleep action is enough for the use case.

[Martin]

That control UI did not properly lock is a very old bug (introduced in October 2012 ) that's fixed in the next build. Sleep in a script will definitely not cause the problem anymore so it should theoretically not be a noticeable change for most users.
I would recommend to use a plain action Sleep in general when no other scripting features are involved in the flow since it's internally slightly doing less stuff like parsing scripts etc. and is probably easier to understand for most users.

Regards,
Martin

[Desmanto]

Thanks Martin for the extra clarification. I never experience any race condition in Control UI, but I still prefer it will be fixed to prevent unpredictable problem in the future.

I just need a sleep action in my current flow. And because of this, I have split it to a separate sleep action. It only add 4 ms latency anyway, while we already commit to use a longer sleep.

[digitalstone]

Sleep action works: Confirmed (well dah)

I replaced my sleep scripts with sleep actions, and conditions are no longer discontinueing anywhere.

[Desmanto]

The sleep() function has been improved in EAP 1.35.0. Now sleep() won't halt other script/expression anymore. But it is still encouraged to use separate sleep action for longer sleep.