Schedules
A Schedule is a time-based rule — "set the light to 20% at 22:00 on weekdays" — that runs on the Node itself. ESP RainMaker Neo stores the Schedule set in the cloud so it survives app reinstalls and is visible to everyone with access to the Node, but the Node is what watches the clock and fires the action.
Three kinds of triggers:
- One-shot — fire once, a number of seconds from now (
rsec). - Clock time on chosen days or dates — minutes past midnight plus a day or date mask (
mwithdordd). - Solar — sunrise or sunset at a given latitude and longitude (
lat/lonwithsr/ss).
A Schedule may also carry a validity window with start and end Unix timestamps, outside which it never fires. Anyone who can reach the Node through its Group — or through a Subgroup they have access to — can read, replace and delete its Schedules.
What the firmware must do
Schedules are built-in. esp_rmaker_node_init() starts the service and esp_rmaker_start() fetches the Schedule set from the cloud — there is no enable call and no Kconfig option to switch the feature on.
- Enable time sync (
enable_time_syncin the SDK config) and the timezone service. Schedules are armed only after the first successful clock sync; before that they are held, and they are re-armed when the timezone changes. - Write a handler being called by a Schedule. When one fires, the SDK invokes your ordinary write callback with the request source set to
ESP_RMAKER_REQ_SRC_SCHEDULE. - Set
CONFIG_RMAKER_SCHEDULING_MAX_SCHEDULESto the number your product actually offers, and budget NVS for it.
See Schedules and automations for the callback and Time and timezone for clock setup.
A Node fires Schedules against its own synchronised clock and configured timezone, not the phone's. Until that clock is valid, every Schedule is held.
NTP is the authoritative source, but not the only one: on connecting, a Node asks the cloud for the time over MQTT and uses the response until NTP steps in. See Time and timezone.
Related
- Schedules and automations — the firmware side, with callback code
- Automations — the cloud-evaluated counterpart, for event-driven rules
- Time and timezone — what a Node needs before any Schedule can fire
- Node–cloud communication — how the Schedule set reaches the Node
- Schedules (cloud spec) — storage model, API and MQTT push in full