Nodemcu-firmware: FR: cron module

[djphoenix]

As proposal to resolve #1670

Missing feature

Cron-like module (with possibility to run repeatable tasks).

Justification

This is very important feature for IoT devices that runs some scheduled tasks (e.g. light controllers with daytime-related switching or dimming).

Workarounds

Manual handle (e.g. minutely) wallclock-time and compare parts with template. Very complex at all.

My propose is to include parser (based on ets_timer and gmtime) in module and parse schedule list in C-level.

API proposal

-- Every day at 09:00
local task_on = cron.schedule('0 9 * * *', function() light.switch(true) end)
-- Every day at 22:00
local task_off = cron.schedule('0 22 * * *', function() light.switch(false) end)
-- Remove task
task_on:unschedule()
-- Re-schedules task to 21:00
task_off:schedule('0 21 * * *')
-- Replaces task handler
task_off:handler(function() light.dim(20) end)

Discussion is welcome.

[marcelstoer]

Sure, would be really nice to have.

My propose is to include parser (based on ets_timer and gmtime)

You mean _this_ ets_timer https://github.com/pvvx/EspLua/blob/master/app/main/ets_timer.c? Brings back some bad memories 😞

Would you base this module on SNTP or rtctime?

[djphoenix]

I mean native SDK struct ets_timer of course.
Because gmtime use, there is no reasons to use sntp or rtctime modules as dependencies. gmtime natively get current system time, and parse it to components. But, of course, user need to set RTC time somehow, before it can start to work.

[djphoenix]

...was played for some time. Got implementation prototype.
Task struct looks like this:

struct schedule_desc {
  uint64_t min; // Minutes repeat - bits 0-59
  uint32_t hour; // Hours repeat - bits 0-23
  uint32_t dom; // Day-of-month repeat - bits 0-30
  uint16_t mon; // Monthly repeat - bits 0-11
  uint8_t dow; // Day-of-week repeat - bits 0-6
};

This is enough to keep all variants of all crontab-like schedules combinations with bitmasks, and so keep memory consumption extremely low (one entry just takes 19 + align bytes, plus some overhead for keep handler ref in userdata and list of entries).