Device Power Events

When a device with power detection reports an interruption or restoration, the service sends the corresponding WebSocket event.

Topics

device.power.lost
device.power.restored

Permission

Required:

device:read

Power Lost Event

{
  "type": "event",
  "topic": "device.power.lost",
  "data": {
    "deviceId": "abc123456789",
    "occurredAt": "2026-08-01T01:00:00Z"
  }
}

Power Restored Event

{
  "type": "event",
  "topic": "device.power.restored",
  "data": {
    "deviceId": "abc123456789",
    "occurredAt": "2026-08-01T01:03:20Z"
  }
}

data Schema

Field	Type	Required	Description
deviceId	string	Yes	Unique device identifier
occurredAt	string	Yes	Event time recorded by the service, in RFC3339 UTC

Event Semantics

• device.power.lost means that the device reported a power interruption.
• device.power.restored means that the device reported restored power.
• Power and network connection events are independent. Restored power does not mean that the device is connected, and lost power does not mean that the service has confirmed it offline.
• Ordering is not guaranteed between device.power.restored and device.connection.online, or between device.power.lost and device.connection.offline.
• Device types may not provide identical power-detection capabilities. The absence of an event does not prove that power did not change.
• WebSocket events are not replayed after reconnecting. Persist events promptly when long-term retention is required.

Client Handling

• On device.power.lost, record the alert but use device.connection.offline to determine whether the connection is down.
• On device.power.restored, clear the power-interruption alert, but wait for device.connection.online before treating the device as controllable.
• Use deviceId + topic + occurredAt to make repeated handling idempotent.
• After reconnecting WebSocket, restore the current-state baseline with the device list or a single-device query.