Monitor Offline and Power Events

Use Case

Use this pattern when your backend needs to update availability, raise alerts, or record supported power-change 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.power.restored reports restored power, but it does not mean that the network connection is available.
• Device models do not necessarily have identical power-detection behavior. Check the device type definition and delivered device documentation before promising these alerts for a product. If no explicit 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-specific UI or alerts. A generic operation list is not proof of power-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 raise the alert. On device.power.restored, the power alert can be closed, but wait for device.connection.online before treating the device as controllable.
7. Use only the structured topic and timestamps for power events. Do not parse or branch on raw firmware text.
8. 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 lost and restored semantics	Device Power Events
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.
• Power and connection events are unordered and either category may arrive alone. Do not infer power changes from online/offline.

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-event 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