Feature overview
Not everything in the SDK needs to be switched on. Some features are always there, some need one function call, and some need a Kconfig option plus a component link. This page is the map.
What you get without asking
These come up inside esp_rmaker_node_init() and esp_rmaker_start(). There is no enable call and no option to turn them off.
| Feature | Notes |
|---|---|
| MQTT connection management | X.509 mutual TLS to AWS IoT Core, reconnect, subscription state, retry with backoff |
| Node configuration reporting | Published on start, but only when its checksum changed |
| State reporting | Coalesced parameter reports, shadow updates, online/offline state |
| Schedules | Full schedule service, persisted in NVS |
| Automation triggers | Parameter-threshold triggers evaluated on every update |
| Parameter persistence | For parameters flagged PROP_FLAG_PERSIST |
| Assisted claiming | ESP-IDF with BLE enabled — the node obtains its own cloud credentials at first setup |
Schedules and automations need no enable call — those services are always present.
Scenes are not implemented in the RainMaker Neo node firmware yet. The request-source values ESP_RMAKER_REQ_SRC_SCENE_ACTIVATE / _DEACTIVATE and the esp.service.scenes / esp.param.scenes type strings are reserved for when they are. Do not build against them.
One function call
Call these after esp_rmaker_node_init() and before esp_rmaker_start().
| Feature | Call | Guide |
|---|---|---|
| Time synchronisation | esp_rmaker_config_t.enable_time_sync = true | Time and timezone |
| Timezone service | esp_rmaker_timezone_service_enable() | Time and timezone |
| System service | esp_rmaker_system_service_enable(&cfg) | System service |
| Local control | esp_rmaker_local_ctrl_service_enable() | Local control |
| On-network challenge-response | esp_rmaker_on_network_chal_resp_start(&cfg) | Local control |
| Serial console | esp_rmaker_console_init() | Serial console |
| OTA updates | esp_rmaker_ota_enable(&cfg) — also link esp_rmaker_neo_ota | OTA firmware updates |
Parameter flags only
| Feature | How | Guide |
|---|---|---|
| Time series data | PROP_FLAG_TIME_SERIES or PROP_FLAG_TS_CUMULATIVE on the parameter | Time series data |
| Fleet-searchable values | PROP_FLAG_INDEXED | Data model |
| Reboot-safe values | PROP_FLAG_PERSIST | Data model |
Kconfig-gated
These change what gets compiled, so they need a rebuild.
| Feature | Option | Default | Guide |
|---|---|---|---|
| Bridge nodes | CONFIG_RMNG_BRIDGE_ENABLED | n | Bridge nodes |
| Remote (host) control | CONFIG_RMNG_HOST_CTRL | n | Configure and build |
| Heap monitoring | CONFIG_RMNG_HEAP_MONITORING | n | — |
| Custom MQTT client | CONFIG_RMNG_CUSTOM_MQTT_CLIENT_PROVIDER | n | — |
| OTA signature verification | CONFIG_RMNG_OTA_SIGNATURE_VERIFY_ENABLE | n | OTA firmware updates |
| OTA custom job documents | CONFIG_RMNG_OTA_CUSTOM_JOB_SUPPORT | n | OTA firmware updates |
Mutually exclusive choices
A few features cannot coexist. The Kconfig dependencies enforce these, but it is easier to plan around them than to discover them at build time.
| These conflict | Why | What to do |
|---|---|---|
| Local control vs on-network challenge-response | Both use protocomm_httpd, which is a singleton | Pick one. Local control is the usual choice; it can host the challenge-response endpoint itself via CONFIG_ESP_RMAKER_LOCAL_CTRL_CHAL_RESP_ENABLE. |
| Either of the above vs active Wi-Fi provisioning | Same protocomm_httpd singleton | Enable them after provisioning completes — which is what the standard startup order already does |
| Serial console vs remote control on UART0 | Both multiplex UART0 | Move the console to USB Serial/JTAG, or disable one |
| MQTT budgeting vs OTA | An OTA download shares the MQTT connection and would exhaust the budget | Kconfig defaults budgeting to n when esp_rmaker_neo_ota selects its transport |
| MQTT budgeting vs bridge | Bridged children exhaust the budget | Kconfig defaults budgeting to n when the bridge is enabled |
Cloud-side features that need nothing from firmware
Several product features are implemented entirely in the cloud or the app. Your node does not need code for them — but the data model has to be right, which is where firmware comes in.
| Feature | What firmware must do |
|---|---|
| Groups and subgroups | Nothing. The SDK handles group info and shadow migration. |
| Node sharing | Nothing. |
| Voice assistants (Alexa, Google) | Use standard device and parameter types and assign a primary parameter. |
| Automations across nodes | Nothing — cloud-evaluated. On-node parameter triggers are separate and are built in. |
| Notifications | Nothing. Cloud-side, driven off state changes. |
| Time series queries and aggregation | Set the timeseries flags; the cloud does the rest. |
See Product overview → Features for the product-level view of each.
Related
- Configure and build — where these options live in
menuconfig - Firmware specifications → Services — the wire contract for built-in services
- Firmware specifications → Optional Services