Monitorizar desconexiones y eventos de alimentación
Caso de uso
Usa este patrón cuando tu backend necesite actualizar la disponibilidad, lanzar alertas o registrar señales de cambio de alimentación admitidas sin sondear repetidamente el estado del dispositivo.
device.connection.onlineydevice.connection.offlinedescriben los cambios de conexión.device.power.lostinforma de una señal de corte de corriente en los dispositivos que la ofrecen.device.power.restoredinforma de la recuperación de la corriente, pero no implica que la conexión de red esté disponible.- No todos los modelos de dispositivo tienen el mismo comportamiento de detección de alimentación. Comprueba la definición de tipo de dispositivo y la documentación del dispositivo entregado antes de prometer estas alertas en un producto. Si no hay ninguna capacidad documentada explícitamente, no des por hecho que existe.
Flujo recomendado
WebSocket ofrece notificaciones oportunas, pero no es un sistema de registro permanente. Mantén el estado actual en tu propio servicio y restáuralo desde REST después de cualquier hueco de eventos.
Implementación paso a paso
- Construye el estado inicial de la cuenta con Listar dispositivos (en inglés).
- Revisa Listar definiciones de tipo de dispositivo (en inglés) y la documentación del dispositivo entregado antes de activar alertas o interfaz específica de alimentación. Una lista genérica de operaciones no es prueba de que exista detección de alimentación.
- Crea un ticket de WebSocket (en inglés), conecta y arranca el Ping/Pong del protocolo más
session.ping. - Con
device.connection.offline, deja de presentar el dispositivo como controlable y registraoccurredAt. - Con
device.connection.online, marca la conectividad como restaurada, pero no des por hecho que todo el estado de periféricos ya está sincronizado. Actualiza el dispositivo cuando necesites el estado actual. - Con
device.power.lost, persiste el evento y lanza la alerta. Condevice.power.restored, puedes cerrar la alerta de alimentación, pero espera adevice.connection.onlineantes de tratar el dispositivo como controlable. - Usa solo el topic estructurado y las marcas de tiempo para los eventos de alimentación. No analices ni ramifiques según el texto crudo del firmware.
- Tras reconectar, usa REST para restaurar la base de la cuenta y consulta solo los dispositivos críticos que necesiten confirmación inmediata.
Interfaces y eventos clave
| Para qué | Referencia |
|---|---|
| Base actual de la cuenta | Listar dispositivos (en inglés) |
| Confirmar un dispositivo | Consultar dispositivo (en inglés) |
| Eventos de conexión y desconexión | Eventos de conexión de dispositivo (en inglés) |
| Semántica de corte y restauración de alimentación | Eventos de alimentación de dispositivo (en inglés) |
| Heartbeat y recuperación | Heartbeat y reconexión (en inglés) |
Fallos y recuperación
- Detecta conexiones cerradas y timeouts de heartbeat, y reconecta con backoff exponencial acotado y jitter aleatorio.
- No reutilices nunca un
wsTicket; crea uno nuevo justo antes de cada intento de conexión. - Los eventos no se reproducen. Tras reconectar, reconstruye el estado actual en lugar de asumir que no ocurrió ningún evento.
- La entrega de eventos puede duplicarse en torno a reintentos o reconexiones. Haz que los manejadores sean idempotentes usando el topic disponible, el
deviceId, las marcas de tiempo y el estado resultante; no dependas de un campo que el contrato del evento no defina. - Los eventos de alimentación y de conexión no tienen un orden garantizado, y puede llegar solo una de las dos categorías. No infieras cambios de alimentación a partir de
online/offline.
Consideraciones para producción
- Guarda el momento de recepción del evento por separado del
occurredAtdel dispositivo, para poder observarlo. - Define reglas de supresión y recuperación de alertas para que las tormentas de reconexión no generen incidentes duplicados.
- Trata WebSocket como un canal de actualización en vivo y REST como la vía de recuperación de estado.
- Confirma el soporte de eventos de alimentación durante el alta del dispositivo. No lo des por hecho solo porque otro tipo de dispositivo informe ese evento.