Sending Commands

Send a value to a device’s sensor and get confirmation back once the device has applied it — sometimes called a cloud-to-device (C2D) command.

1. Receiving a command on the device

Attach a listener for the command event — this automatically subscribes the device, no separate call needed:

device.on('command', (command, ack) => {
  console.log(command.sensorId, command.value)
  // ...apply it — flip a relay, change a mode, etc...
  ack({ success: true, value: command.value })
})

Call ack() once you’ve actually applied the command — the platform is waiting on it to know the command really happened, not just that it arrived.

2. Sending a command from the platform

On a sensor’s page — for any sensor set up to Receive or Exchange commands (see Device Provisioning) — you’ll find a control instead of a static value:

• A binary sensor gets a toggle switch.
• A state sensor gets a text field and a Send button, since its values aren’t limited to on/off.

Both send as soon as you interact with them — there’s no separate confirm step.

3. What you’ll see

While a command is in flight, you’ll see one of:

• Sending…
• Confirming with device…
• Command timed out
• Command failed
• Device offline — shown immediately if the device wasn’t reachable to send to.
• Failed to send command — a generic send error.

A “Command timed out” message isn’t necessarily the final word — the device may still apply the command and the platform record it as confirmed shortly after. If you’re not sure, revisit the sensor’s page to check its current state.

4. Command history

Every confirmed change to a sensor’s state — whether from a command you sent, an automation, or the device itself — appears in a history table on the sensor’s page: the value change, who or what made it, and when. A command that failed or timed out without ever being confirmed doesn’t appear here — only the transient status message you saw while sending it.

5. Sensors that can’t receive commands

A Send-direction sensor is report-only — its page shows a read-only value instead of a control, with a note that it can’t receive commands.

Next steps

• Device Provisioning — sensor types and data direction, which determine what can receive a command.
• Automations — sending commands automatically as part of a workflow.
• Telemetry — publishing and querying the sensor data your commands often act on.