OhioIoT
Menu

Commands

Saved buttons in your dashboard that reach out and do something — publish an MQTT message to a device, or fire an HTTP request at any service — with optional feedback tracking.

A Command is a reusable action you define once and click whenever you need it: open the garage, restart the pump, ping a webhook. It comes in two flavors — MQTT (talk to your devices) and HTTP (talk to anything with a URL).

MQTT commands

An MQTT command publishes a payload to a topic. You set the topic and the payload when you create the button; clicking it sends the message. That's the whole mechanism for "turn the relay on," "set the mode," or any instruction your device listens for.

Topic:    larry/garage01/command/door
Payload:  open

On the device side, you subscribe to that topic and act on the payload — the same subscribe you'd write for any MQTT message (see Subscribing).

Feedback tracking

A command can be fire-and-forget, or it can ask the device to confirm. With feedback turned on, the button enters a pending state and waits for the device to report back. The platform tracks the round trip and tells you which of four things happened:

  • Received — the device acknowledged the command. For a simple device, that's the end of the story.
  • Success — the device reported the action completed.
  • Error — the device reported a problem; the detail is posted to your messages inbox.
  • Failed — no response arrived before the timeout window closed.

The pending button is per-tab: feedback returns to the browser tab that issued the command. By default the platform waits five seconds for a response before marking the command failed.

A command can still succeed after it's been marked failed — a slow device that answers late. The platform recognizes this for a short window afterward and surfaces it as a late success rather than silently dropping it, so a sluggish-but-working device doesn't look broken.
Give slow actions a longer timeout. A garage door that takes twenty seconds to travel should not be on a five-second timeout, or every successful open will flash "failed" before the door finishes moving.

HTTP commands

An HTTP command fires a request at a URL — any method, your own headers, an optional body. Use it to wire a dashboard button into something that isn't a device: trigger a webhook, call a third-party API, kick off a script on your own server.

Method:   POST
URL:      https://hooks.example.com/notify
Headers:  Authorization: Bearer ...
Body:     {"event": "tank_full", "source": "ohioiot"}

The button reports success when the request returns a success status and failed otherwise; on failure, the response detail is written to your messages inbox so you can see what the remote service said.

Built-in device actions

Alongside the commands you define, each device card carries a few built-in actions the platform already knows how to send:

  • Restart — reboots the device. You see it confirmed when the boot counter ticks up and uptime resets.
  • Clear counters — resets the device's event counters.
  • OTA accept / abort / rollback — control an in-flight or just-installed firmware update (see OTA Updates).

Firing commands from your own code

Commands aren't limited to the dashboard. Anything that can publish MQTT or make an HTTP request can do the same thing your buttons do — publish to the command topic your device listens on. The Node.js integration and Ingest API both reach devices this way, and a hosted Commands API is on the roadmap (see Commands API).