Running "background" process

[flip111]

I would like to try to combine nodemcu-httpserver with a ledstrip controller. For that i need to constantly send codes to the ledstrip. How can i share cpu time with the http server process (i'm not sure if process is the right name here, maybe it's a coroutine or something like that). It's ok if the ledstrip goes down under any traffic (request/response of webserver) because i just need to configure what colors i want once and then it can run that pattern until i would like to configure something else.

When i make GET/POST requests to the webserver how do i get my background process to pick up on the new values i'm setting? Should i use some global variable for that?

[marcoskirsch]

I plan on doing something similar soon. I want to send a "heartbeat" via http request every X seconds to a script on a remote server so I know the NodeMCU is "alive". My plan is to do it through a timer with a function.

I don't know the details of your application, but assuming you have a global state for the LED strip, then you can do something similar to update the LEDs, and the server can update this global state as requested.

If you make progress, it'd be near to see how you did it on GitHub.

[flip111]

I'm pretty new to this stuff (lua / nodemcu) ... could you give me a suggestion where i should initialize my timer? Would you use the this module for timer? https://nodemcu.readthedocs.io/en/master/en/modules/tmr/ Any other suggestions are welcome !

[flip111]

I'm used to very low level C programming on microcontrollers (i did this a little bit many years ago). So how lua plays into this was a bit of a mystery to me. However i found two pages that explains things well

https://github.com/nodemcu/nodemcu-firmware/blob/master/docs/en/extn-developer-faq.md
https://nodemcu.readthedocs.io/en/master/en/lua-developer-faq/#so-how-does-the-sdk-event-tasking-system-work-in-lua
https://nodemcu.readthedocs.io/en/master/en/lua-developer-faq/#so-how-is-context-passed-between-lua-event-tasks

So from what i understand both tcp requests and timers are both converted into tasks. Then i saw coroutines being used, i think they work in the context of a single task and thus are scheduled at a lower level (time allocation is done with the task gets time from the cpu). So coroutines are not important here for scheduling between the tcp request and a timer (because this is done on the task level). Then i saw you can set task priorities (low, medium, high). It seems useful to make use of these priorities.

Set the tcp request high so that the website stays very responsive (and working).
Set the LED strip low (because it's ok if the lights go out when i want to configure a new pattern).

I guess the default priority for any task is medium. So setting the ledstrip task to low priority should be good enough. However the ledstrip timer does not have a priority argument (i don't know why). But the task can be reposted.

Code could look like this (pseudo code):

tmr.alarm([id/ref], interval_ms, mode, func(
  node.task.post([task_priority], control ledstrip function here)
))

disadvantage is loosing some accuracy on the timer because the task is reposted.

If i have any updates on the feasibility of this idea i will post again. Maybe it turns out that task priorities are not necessary because there is still enough CPU time left.

---

Also to ask my question earlier. Where to initialize the timer ... i think either somewhere in the main boot code and then share incomming settings from http by the lua registery or inside the http handler by using a closure (upvalues), but then the timer needs to be re-registered in order for the new callback to be activated (the closure needs new configuration values).