Skip to main content

Toggle Widget

An on/off (or open/close) switch for a dashboard. Instead of placing two separate buttons, the Toggle widget combines a "switch on" command and a "switch off" command into a single control, and shows the current state at a glance.

It is a tier-gated widget. If you don't see Toggle in the Add a widget list, it isn't part of the workspace's plan yet.

What it does​

Flipping the switch sends one downlink when turned on and a different downlink when turned off, to a single device or to a multi-cast group. The switch can also reflect the current state: green for on, red for off, gray for unknown, and a brief amber while a command is in flight.

Choosing the target​

On the Control tab, under Target, pick what the switch acts on:

  • A device - sends the on/off downlinks to one device. On a device dashboard the device is implicit.
  • A multi-cast group - fires the downlink to every device in the group at once. Requires multi-cast to be enabled for the workspace.

Commands​

Pick the two downlink templates from the target's profile:

  • On / open command - sent when the switch is turned on.
  • Off / close command - sent when the switch is turned off.

The two commands must be different templates. Ask before sending adds an "are you sure" step before each command; it's off by default, so the switch acts immediately. It is a question to the person, not a wait for the device: whether the switch waits for the device to confirm depends on the State field below.

Appearance​

On the Appearance tab:

  • Style - Pill, Segmented, Wall, or Power button.
  • State labels - On / Off, Open / Close, or custom text, to match I/O controllers (on/off) versus valves (open/close).
  • Show state text - show or hide the On / Off / Unknown label under the switch. The color always indicates state.
  • Size - small, medium, or large.
  • Hide header / Hide background - strip the widget's title bar or card so the switch sits cleanly on the dashboard.

The state colors are fixed (green on, red off, a neutral gray for unknown) so a switch always reads the same way.

Knowing the current state​

How the switch knows its position depends on what you bind under State feedback:

  • A device state field - bind a field that reports the device's real on/off state, and set the On value (the reading that means on/open; anything else reads as off). The switch then mirrors the device. This works with live telemetry, a formula field, or a static (manually-set) field. When you flip it, the switch moves at once and shows a small waiting mark ("Sent, waiting for the device to confirm") until the field reports something newer than your click; that reading then wins, whatever it says. A device that stays in touch (Class C) confirms within seconds and the mark disappears. A device that only listens after it reports (Class A) takes the command on its next check-in, and the reading that opens that window still shows the old state, so the switch can flip back for one cycle before the following reading confirms. The mark has no time limit: a device that never reports keeps it until the page is reloaded.
  • A static field, written instantly - when the bound field is a static field (a data field with no decoder source), flipping the switch also writes the new value to the field immediately, using the On value and Off value you set. The switch flips and persists right away instead of waiting for the device to actuate and report back. This matters for Class A devices, which only receive a queued command on their next check-in. The downlink still goes to the device; the field tracks the commanded state. Each flip also adds a manual entry to the device's Events tab and recalculates its formula fields. Workflows do not run on a flip, because the command has already been sent. On a shared dashboard link the switch sends its command and does not write the field. Live telemetry and formula fields are read-only and are never written.
  • A multi-cast group - a group has no single state to read, so the switch reads the group's execution history and shows the last command it sent. The position persists across page loads and reflects commands fired from anywhere, including the Multi-casting page.
  • Nothing bound - the switch shows the last command sent from this page and Unknown on a fresh load. There is no waiting mark, because there is nothing to wait for. If your device reports its state but has no field for it yet, add one to its profile and bind it; for a device that never reports state, bind a static field and set its On and Off values so the switch keeps the commanded state.

Rapid changes​

If you flip the switch several times quickly, only the final position is sent, after a short pause. A stream of taps collapses to a single command, so you don't queue a stack of downlinks. This is especially helpful for Class A devices, where queued commands would otherwise dribble out over several later check-ins.

Tips​

  • For a valve or relay whose state you set yourself, bind a static state field and set On/Off values so the switch flips instantly and stays put.
  • For a device that reports its real state, bind that telemetry field and leave the writing to the device; on a Class A device the switch updates when the device next reports.
  • For a device you can't read back at all, leave the state field empty and the switch tracks your last command for the session.