Schedules and automations

Both features are built in. There is no enable call, no service to create, and no Kconfig option to switch them on — esp_rmaker_node_init() starts them and esp_rmaker_start() fetches their details from the cloud.

What you have to get right is everything around them: the node needs synchronised time, and your write callback needs to handle being invoked by a schedule.

No enable call, and no per-entry operations

Schedules and automation triggers come up automatically — there is nothing to enable. There are also no add/remove/edit/enable/disable operations on the wire: the cloud uploads the complete schedule set and the node replaces what it holds. Scenes are not implemented on the node.

Schedules

A schedule is a set of parameter values plus a trigger — "set the light to 20% at 22:00 on weekdays". Evaluation happens on the node, using its local clock, so schedules keep firing while the internet is down.

What firmware must do

Two things:

1. Enable time sync. A node with no clock cannot fire a schedule. Set enable_time_sync in the SDK config, and enable the timezone service so the user's local time is meaningful:

esp_rmaker_config_t cfg = { .enable_time_sync = true };
esp_rmaker_node_t *node = esp_rmaker_node_init(&cfg, "Light", "light");
/* … */
esp_rmaker_timezone_service_enable();

See Time and timezone. Schedules are armed only after the first successful time sync; before that they are deferred.

2. Handle the SCHEDULE request source. When a schedule fires, the SDK calls your ordinary write callback with ctx->src == ESP_RMAKER_REQ_SRC_SCHEDULE. In most products that needs no special handling — the point of a schedule is to behave like any other write. But if your device does something user-visible on change, like sound a chime, you probably want to suppress it:

if (ctx && ctx->src == ESP_RMAKER_REQ_SRC_SCHEDULE) {
    app_driver_set_quiet_mode(true);
}

That is all. Storage, timer arming, DST handling, re-arming after reboot, and reporting the schedule set back to the cloud are the SDK's job.

Persistence and reboots

Schedules are persisted to NVS as a versioned blob. On boot the SDK reloads them and re-arms every schedule, so a power cut does not lose them and does not need a cloud round trip to recover.

Capacity

Option	Default	Range
CONFIG_RMAKER_SCHEDULING_MAX_SCHEDULES	10	1–50

Raising the limit grows the reported-parameters JSON, which grows every state report that includes it. Raise it only if your product genuinely needs more, and check the resulting payload size against your MQTT buffer.

Automation triggers

An automation trigger watches a parameter for a threshold condition — "when temperature goes above 30, notify". Triggers are attached to a specific parameter and evaluated on the node, inside esp_rmaker_param_update().

What firmware must do

Nothing, beyond reporting the parameter in the first place. The flow is entirely internal:

Two consequences worth knowing:

• Triggers only fire on esp_rmaker_param_update(). A value your driver knows about but has not reported does not exist as far as triggers are concerned. If a sensor can change without your code noticing, poll it.
• Trigger evaluation runs on the calling task. Keep it in mind if you update parameters from a tight loop or an interrupt-adjacent context.

Triggers are pushed down from the cloud with the node's details; a trigger arriving with enabled: false is not added to the node at all.

On-node triggers vs cloud automations

These are two different things with confusingly similar names:

	On-node automation triggers	Cloud automations
Evaluated	On the node, in esp_rmaker_param_update()	In the cloud
Works offline	Yes	No
Can act on other nodes	No	Yes
Firmware work	None	None

See Product overview → Automations for the cloud side.

Debugging

Symptom	Likely cause
Schedules never fire	No time sync. Check local-time on the serial console — if it is wrong or unavailable, fix time sync first.
Schedules fire at the wrong hour	Timezone not set, or set only as a location string with no POSIX rules. See Time and timezone.
Schedules fire, but nothing happens	Your write callback is not handling the parameter type, or is rejecting the value. Reproduce with set-param on the console.
Some schedules are silently dropped	CONFIG_RMAKER_SCHEDULING_MAX_SCHEDULES reached.
Triggers never notify	The parameter is not being updated through esp_rmaker_param_update().

Related

• Firmware specifications → Built-in Services — the schedule and trigger JSON, getSchedVer / getSchedDetails, and how RainMaker Neo differs from ESP RainMaker Classic
• Time and timezone
• Callbacks and events
• Cloud specifications → Schedules