Skip to main content

Remote Control

Remote control is the default path: a client anywhere on the internet changes a Parameter, and the Node applies it. It is what the phone app does when it is not on the same network as the device, and it is the mechanism every other control feature is built on — Group control, Schedules pushed from the cloud, Automation actions and voice commands all end in the same Parameter write.

For the path that skips the cloud entirely, see Local control.

What the user sees​

A control in the app — a toggle, a slider — that takes effect on the device, and a state that stays correct across every other client and session. Nothing polls, so a change made from one phone appears on another without a refresh.

How a parameter change travels​

The path from a user tapping a toggle to that Node's state being visible to every other client:

Seven steps across client, cloud and node lanes: the client gets credentials and publishes the value over MQTT; IoT Core delivers it to the Node, which is already subscribed to only its own topics; the Node's write callback applies the value and reports state into its group-scoped shadow, which any client reads; an indexed Parameter is also mirrored into DynamoDB by an IoT rule

Step 2 is a plain MQTT publish, not a write to the shadow's desired section. That single design choice explains most of Neo's runtime behaviour: control is fast and stateless, and it is also fire-and-forget, so a Node that is offline at that instant never receives the change. Node–Cloud Communication covers the consequences.

What the firmware must do​

Nothing beyond the basics. Remote control is not a feature you enable — it is what esp_rmaker_node_init() and esp_rmaker_start() give you. Write a callback for each writable Parameter and report state back when the value changes; the same callback serves writes from every source, distinguished by the request source in its context.

Limits and caveats​

No store-and-forward for control. A Parameter set on a disconnected Node is not queued for later delivery.

Fire-and-forget. A successful publish means the broker accepted the message, not that the device acted on it. Confirmation comes from the Node reporting its new state, so treat the reported value as the source of truth rather than the value you sent.