Reset a task start time

[AcuarioCat]

Hi, is it possible to reset a task start time while the task is active?
This is my scenario:
I want a task to control the backlight on an lcd so the display turns off when there is no user activity for say 30 seconds.
I would like to start a task for this (no problem) but if there is some activity from a user then I want to reset the task execution start time back to the beginning to delay the task. I guess I can do this with disable/enable but is there another cleaner way?

[arkhipenko]

I use restartDelayed() for this purpose all the time. The task you are talking about is a Timeout task. Its callback method implements timeout functions (e.g. turn the display off, put device to sleep, etc.). Any other task, that should prevent a timeout should call Timeout.restartDelayed(); in their callback method. Please check my pumpkin project. There is a timeout task implemented there. Cheers, Anatoli Sent from a mobile device. Apologies for accidental typos. On Dec 24, 2017 10:58 AM, AcuarioCat <notifications@github.com> wrote: Hi, is it possible to reset a task start time while the task is active? This is my scenario: I want a task to control the backlight on an lcd so the display turns off when there is no user activity for say 30 seconds. I would like to start a task for this (no problem) but if there is some activity from a user then I want to reset the task execution start time back to the beginning to delay the task. I guess I can do this with disable/enable but is there another cleaner way? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#41>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AATGTRDowsC9gczzbLDmtRdwwRRn12txks5tDiBWgaJpZM4RL4oh>.

[arkhipenko]

Make sure you enableDelayed() your timeout task at the very end of setup() method. Otherwise it will trigger immediately...

[arkhipenko]

Make sure you enableDelayed() your timeout task at the very end of setup() method. Otherwise it will trigger immediately...

[mm108]

hi, a small doubt related to the same issue - If I were calling <taskname>.restartDelayed(); without passing the parameter(unsigned long aDelay), I might as well straightaway call <taskname>.resetTimeout();?

Here's something about what I am trying to achieve:
When a certain thing happens, I want one of the tasks to start counting from the beginning again (say the task is set to run at 3 Sec interval and 2 Secs have since passed, it should reset back to 3 Sec again).

I was thinking of the best or recommended way to do that. I read that you mentioned restartDelayed() but then I came across resetTimeout() in the documentation and thought I should check. Thanks a ton.

Cheers

[mm108]

Ok, I think I understand this. resetTimeout() just resets the interval back to what was originally set and starts the (time) count from start again.

restartDelayed() on the other hand gives and extra parameter which makes it work in this manner.
An example of restartDelayed(n) called with the parameter n

1. The task gets stopped if it was running
2. There will be delay of n seconds.
3. After the completion of n seconds, the task is enabled again and starts executing with whatever interval was set previously.

... unless I got any of the above wrong

Cheers

[arkhipenko]

Fundamentally the `restart()` and `restartDelayed()` methods are for regular execution. In your case `restartDelayed()` should do the trick. An example of a user story for this type of functionality could be: "Restart blinking an LED 2 times per second indefinitely when a button is pressed". `resetTimeout()` is part of the overall timeout functionality which disables the task completely regardless of the remaining iterations, time left, etc... `resetTimeout()` just restarts overall task timeout counter, but does not affect current task execution, so if task was on iteration 10 and 1 second from next callback (say every 3 seconds), it will continue to wait for 1 second and then trigger iteration 11. `restartDelayed()` alternatively will reset iteration counter to 1 and trigger callback in 3 seconds as if it was first time. An example of a user story for this type of functionality could be: "Stop blinking LED completely after 5 seconds regardless of which iteration it is or how much time is left until next iteration". There is a subtle difference between use cases. `enable` and `restart` methods are for functional purposes, while timeout is more for exceptions. Does it make sense?

[mm108]

Cool, it makes perfect sense. And I understand the difference now. Thanks a lot.

[mm108]

Oops, when I execute the restartDelayed() 3-4 times, the ESP32 reboots :-/ I am trying to figure out why but the reboot's never happened before until I made the change to reset the task interval.

I am thinking I could disable => enable the task. I guess that resets the interval ( start counting from zero again?) Thanks

Cheers

[arkhipenko]

I never tested TaskScheduler on ESP32 myself. However I find it very strange that a restart method would cause a reset. Are you sure it is not something else ? On Dec 25, 2018 10:10 AM, RW <notifications@github.com> wrote: Oops, when I execute the restartDelayed() 3-4 times, the ESP32 reboots :-/ I am trying to figure out why but the reboot's never happened before until I made the change to reset the task interval. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#41 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AATGTdptDvucMVW28nnsxm_PMho3MrxDks5u8j_bgaJpZM4RL4oh>.

[mm108]

hi, yes I can confirm that the restartDelayed() has something to do with the reboots. I commented out the part where I reset the timeout and then the reboots don't happen anymore. Thanks

Cheers

[arkhipenko]

Could you please send your full sketch to arkhipenko@hotmail.com ? On Dec 25, 2018 10:56 AM, RW <notifications@github.com> wrote: hi, yes I can confirm that the restartDelayed() has something to do with the reboots. I commented out the part where I reset the timeout and then the reboots don't happen anymore. Thanks Cheers — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#41 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AATGTfr5ulCvvHtsDFjNCFYy4EKwTf3aks5u8krDgaJpZM4RL4oh>.

[mm108]

hi, yes but I'll probably need to comment out a number of lines because the sketch is huge and has a lot of lines dealing with other hardware, sensors, OLED screen etc. I guess it'll would throw a whole bunch of errors if run without the same hardware connected to the same pins :-/
Cheers

[arkhipenko]

That's ok. You can send as is, or please make sure it still resets after you comment out the lines. On Dec 25, 2018 12:02 PM, RW <notifications@github.com> wrote: hi, yes but I'll probably need to comment out a number of lines because the sketch is huge and has a lot of lines dealing with other hardware, sensors, OLED screen etc. I guess it'll would throw a whole bunch of errors if run without the same hardware connected to the same pins :-/ Cheers — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#41 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AATGTSDo4J39wFfM_AABgpeWWxhOern5ks5u8lo0gaJpZM4RL4oh>.

[mm108]

When I was commenting out some lines I accidentally commented out couple of lines that have to do with ESPAsyncWebServer. After that the reboots haven't happened so far. Also the restartDelayed() when run in a separate sketch many times over does not cause a reboot. So I guess it could be some conflict between the 2 libraries - or the combo being heavy on the memory or something. I'll send the sketch after commenting out some lines - there is a whole lot of lines just related to OLED display and sensors scattered in the sketch that won't run on general esp32 dev boards. I'll be back with an update. Still so far one of the best and comprehensive libraries I have come across, and also great support. Thanks @arkhipenko once again for that. Cheers.