Skip to content

Device Capabilities

Two orthogonal questions decide what a device UI should show:

  • What kind of device is it? — its class (subclass: DimmerDevice, RelayDevice, ThermostatDevice, …). Good for browsing and organizing ("show my thermostats").
  • What can you do with it? — its capabilities, expressed by the device's supports* attributes (and, for some, its subclass or plugin-defined properties). This is the axis that decides which controls to render.

Class alone is not enough. Capabilities cut across classes — on/off (onState) spans relays, dimmers, sensors, sprinklers, and speed controls; color and white-temperature split dimmers; cool setpoint and fan mode split thermostats. And plugin-defined custom devices (a plain Device with no subclass) can't be recognized by class at all. So for control UI, capability is the primary axis and class is the secondary (browse) axis.

This page is the canonical capability → control reference. The per-subclass reference documents each type's full property, state, and command set; this page is the cross-cut: which capability gates which control, and the command that drives it.

Capability reference

Each capability is gated by a signal on the device — an IOM supports* attribute, the device's subclass, or a plugin-defined property. Render the control only when the signal is present.

Capability Gating signal Control Command
On / off dev.supportsOnState (and writable — inherent for relay/dimmer; a sensor must allow user on/off changes) on/off toggle indigo.device.turnOn / turnOff / toggle
Brightness (dimming) DimmerDevice subclass brightness slider indigo.dimmer.setBrightness / brighten / dim
Color (RGB) dev.supportsColor / dev.supportsRGB RGB color picker indigo.dimmer.setColorLevels (red/green/blue)
White level dev.supportsWhite white slider indigo.dimmer.setColorLevels (whiteLevel)
Two white levels dev.supportsTwoWhiteLevels warm + cool white sliders indigo.dimmer.setColorLevels (whiteLevel + whiteLevel2)
White temperature dev.supportsWhiteTemperature (range from WhiteTemperatureMin / WhiteTemperatureMax plugin props) white-temperature slider indigo.dimmer.setColorLevels (whiteTemperature, 1200–15000 K)
Cool setpoint dev.supportsCoolSetpoint cool setpoint stepper indigo.thermostat.setCoolSetpoint / increaseCoolSetpoint / decreaseCoolSetpoint
Heat setpoint dev.supportsHeatSetpoint heat setpoint stepper indigo.thermostat.setHeatSetpoint / increaseHeatSetpoint / decreaseHeatSetpoint
HVAC mode dev.supportsHvacOperationMode mode selector (off / heat / cool / auto) indigo.thermostat.setHvacMode
Fan mode dev.supportsHvacFanMode fan mode selector (auto / always-on) indigo.thermostat.setFanMode
Speed control SpeedControlDevice subclass (see speedIndexCount) speed selector indigo.speedcontrol.setSpeedIndex / setSpeedLevel
Sprinkler zones SprinklerDevice subclass zone + schedule controls indigo.sprinkler.run / stop / pause / resume / nextZone / previousZone / setActiveZone
I/O outputs MultiIODevice subclass (binary outputs) binary-output bank indigo.iodevice.setBinaryOutput
Status request dev.supportsStatusRequest refresh / status-request button indigo.device.statusRequest
Energy meter SupportsEnergyMeter plugin prop accumulated-energy readout + reset indigo.device.resetEnergyAccumTotal
Power meter SupportsPowerMeter plugin prop current-power readout (read the curEnergyLevel state)
Battery batteryLevel state present battery-level readout (read the batteryLevel state)
Sensor value dev.supportsSensorValue sensor-value readout (read the sensorValue state)

Readout-only rows (power, battery, sensor value) carry no write command — a detail view shows them, a picker doesn't offer them.

On/off presentation modifiers

Some devices are on/off devices with a domain label rather than a distinct capability. These relabel the on/off control; they add no new controls or commands:

  • Lock / unlock — the IsLockSubType plugin property. The on/off control reads Lock / Unlock. (Dedicated indigo.device.lock / unlock commands also exist.)
  • Open / close — the IsOpenCloseSubType plugin property. The on/off control reads Open / Close.

A client MAY honor these labels or MAY present a plain on/off — both are correct, since a lock or blind/shade/door is fundamentally an on/off device.

Custom (plugin) devices

A plugin custom device is a plain Device with no subclass. In practice, a plugin that wants on/off implements a relay device, so a custom device does not advertise controllable capabilities. Treat custom devices as information-only (states and details) from a presentation perspective: each will likely provide actions to support controlling the device. A custom device is still enumerable and browsable by class.

Using the model

The capability model answers both directions of device UI from one mapping:

  • Which devices does a control offer? (forward) — a brightness control offers only devices with the brightness capability; a color control only color-capable ones. Filter the device list by the capability the control requires.
  • Which controls does a device show? (inverse) — intersect the device's capability set with the table above and render the controls whose capability the device has.

Keeping both directions on one mapping is what keeps every client — the macOS client, the iOS and web clients, and any MCP-driven UI — in agreement about "can this device do X."

See also