Skip to main content

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.

A Schedule named Good Night, evaluated on the Node: any one of three time triggers — 22:00 on weekdays, sunset, or a one-shot delay of 30 minutes — fires a single action that sets Light.Power to false and Fan.Speed to 2 on the same Node

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 (m with d or dd).
  • Solar — sunrise or sunset at a given latitude and longitude (lat/lon with sr/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_sync in 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_SCHEDULES to 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.

The Node's clock is the only clock

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.