Monitor Offline and Power-loss Events

Use Case

Use this pattern when your backend needs to update availability, raise alerts, or record supported power-loss signals without repeatedly polling device state.

• device.connection.online and device.connection.offline describe connection changes.
• device.power.lost reports a power-loss signal from devices that provide that signal.
• Device models do not necessarily have identical power-loss detection behavior. Check the device type definition and delivered device documentation before promising this alert for a product. If no explicit power-loss capability is documented, do not infer support.

Recommended Flow

WebSocket provides timely notifications, but it is not a permanent system of record. Keep current state in your own service and restore it from REST after any event gap.

Step-by-Step Implementation

1. Build the initial account state with List Devices.
2. Review List Device Type Definitions and delivered device documentation before enabling power-loss-specific UI or alerts. A generic operation list is not proof of power-loss detection support.
3. Create a WebSocket ticket, connect, and start protocol Ping/Pong plus session.ping.
4. On device.connection.offline, stop presenting the device as controllable and record occurredAt.
5. On device.connection.online, mark connectivity restored, but do not assume all peripheral state has already synchronized. Refresh the device when the current state is required.
6. On device.power.lost, persist the event and alert from the structured topic and timestamps. Do not parse or branch on the optional firmware message.
7. After reconnecting, use REST to restore the account baseline and query only critical devices that require immediate confirmation.

Key Interfaces and Events

Purpose	Reference
Current account baseline	List Devices
Confirm one device	Get Device
Online and offline events	Device Connection Events
Power-loss event semantics	Device Power Lost Event
Heartbeat and recovery	Heartbeats and Reconnection

Failure and Recovery

• Detect closed connections and heartbeat timeouts, then reconnect with bounded exponential backoff and random jitter.
• Never reuse a wsTicket; create a new one immediately before each connection attempt.
• Events are not replayed. After reconnecting, rebuild current state rather than assuming no event occurred.
• Event delivery can be duplicated around retries or reconnect boundaries. Make handlers idempotent using the available topic, deviceId, timestamps, and resulting state; do not rely on a field the event contract does not define.
• A power-loss event is normally followed by an offline event, but alert handling must tolerate either event arriving without the other.

Production Considerations

• Store event receipt time separately from device occurredAt for observability.
• Define alert suppression and recovery rules so reconnect storms do not create duplicate incidents.
• Treat WebSocket as a live update channel and REST as the state-recovery path.
• Confirm power-loss support during device onboarding. Do not infer support only because another device type reports the event.

Next Steps

• Build a Device Monitoring Dashboard
• WebSocket Message Format
• REST API vs WebSocket