Device Interaction Documentation

Device Model Supported Trait Capabilities

Device Capability Files

Each supported device model has a corresponding capability JSON file that describes the exact Device Trait (e.g., LockV1) operations and values available for that model. Use these files to configure which fields, settings, and notifications your application surfaces for a given device.

Correlating a Device to Its File

Query device.trait.DeviceInfoV1.state.model.reported.value for the connected device and match the returned value against the Model column in the table below to identify the correct capability file.

File Contents

Each capability file is a JSON document containing the following top-level fields:

model — The device model identifier (matches the Device Model column in the table below).
modelId — A short identifier for the device hardware model (e.g., Xe360DBRTWFMTD). Provided as reference context alongside the model field.
supportedCapabilities — A map of Device Trait keys to their supported operations, keyed by Device Trait name in PascalCase (e.g., LockV1DeviceTrait). Each entry contains:
queryFields — State fields that can be read for this device. Enum fields include the exact set of values the device can report. Scalar fields (String, Int, DateTime) are listed without value constraints — the device always returns the raw reported value.
actionMutations — Mutations that can be invoked on this device. Inputs include the accepted enum values or scalar type. The actionType field identifies the mutation pattern; refer to the Action Mutation Overview for flow diagrams by action type.
notificationEvents — Event names the device can emit.

What These Files Do Not Include

The following are intentionally omitted because they are invariant across all devices and defined in the Device Trait API documentation:

UNSUPPORTED and UNKNOWN enum values — These sentinel values are excluded from query field enum lists. Any device may return them in error conditions, but they do not represent supported device states on the happy path and should not drive UI logic.
Action mutation response fields — Fields such as actionId, deviceId, and traitName are returned by every mutation on every device. Bulk data mutations (e.g., credential and schedule URL requests) additionally return uploadUrl and uploadUrlExpiresAt. These are documented in the individual Device Trait API pages and do not vary by device model.
Query range and length constraints — Device state fields always return the raw value reported by the device. Integer ranges, string lengths, and similar constraints are not applied to reported state and are therefore not included.
deviceId action input — Required on every mutation across all devices and models. Defined once in the API documentation rather than repeated per capability file.

Accessing These Files

Use the hyperlinks in the table below to access each file directly. You may programmatically fetch a file from its URL if your system requires it at runtime; files are safe to cache and are updated only when a new device model version is onboarded or when mapping updates are released.

Device Capabilities File Matrix

Title

Description