Мониторинг отключений и событий питания

Сценарий использования

Используйте этот шаблон, когда вашему бэкенду нужно обновлять доступность, поднимать оповещения или записывать поддерживаемые сигналы изменения питания без частого опроса состояния устройства.

• device.connection.online и device.connection.offline описывают изменения подключения.
• device.power.lost сообщает о сигнале потери питания от устройств, предоставляющих этот сигнал.
• device.power.restored сообщает о восстановлении питания, но не означает, что сетевое соединение доступно.
• Модели устройств не обязательно имеют одинаковое поведение обнаружения питания. Проверьте определение типа устройства и документацию поставленного устройства, прежде чем обещать эти оповещения в продукте. Если явно документированной возможности нет, не предполагайте поддержку.

Рекомендуемый поток

WebSocket обеспечивает своевременные уведомления, но не является постоянной системой учёта. Храните текущее состояние в собственном сервисе и восстанавливайте его из REST после любого пробела в событиях.

Пошаговая реализация

1. Постройте начальное состояние учётной записи с помощью Список устройств (на английском).
2. Изучите Список определений типов устройств (на английском) и документацию поставленного устройства перед включением специфичного для питания интерфейса или оповещений. Общий список операций не является доказательством поддержки обнаружения питания.
3. Создайте тикет WebSocket (на английском), подключитесь и запустите Ping/Pong протокола вместе с session.ping.
4. При device.connection.offline прекратите отображать устройство как управляемое и запишите occurredAt.
5. При device.connection.online пометьте подключение как восстановленное, но не предполагайте, что вся периферия уже синхронизирована. Обновляйте устройство, когда требуется актуальное состояние.
6. При device.power.lost сохраните событие и поднимите оповещение. При device.power.restored оповещение о питании можно закрыть, но дождитесь device.connection.online, прежде чем считать устройство управляемым.
7. Используйте только структурированный topic и временные метки для событий питания. Не анализируйте сырой текст прошивки и не стройте на нём логику ветвления.
8. После переподключения используйте REST для восстановления базового состояния учётной записи и запрашивайте только критичные устройства, требующие немедленного подтверждения.

Ключевые интерфейсы и события

Назначение	Ссылка
Текущее базовое состояние учётной записи	Список устройств (на английском)
Подтвердить одно устройство	Получение устройства (на английском)
События подключения и отключения	События подключения устройства (на английском)
Семантика потери и восстановления питания	События питания устройства (на английском)
Heartbeat и восстановление	Heartbeat и переподключение (на английском)

Сбои и восстановление

• Обнаруживайте закрытые соединения и истечение heartbeat, затем переподключайтесь с ограниченной экспоненциальной задержкой и случайным jitter.
• Никогда не используйте wsTicket повторно; создавайте новый непосредственно перед каждой попыткой подключения.
• События не воспроизводятся повторно. После переподключения восстанавливайте текущее состояние, а не предполагайте, что событий не произошло.
• Доставка событий может дублироваться при повторных попытках или на границах переподключения. Делайте обработчики идемпотентными, используя доступный topic, deviceId, временные метки и итоговое состояние; не полагайтесь на поле, которое не определено контрактом события.
• У событий питания и подключения нет гарантированного порядка, и может прийти только одна из категорий. Не выводите изменения питания из online/offline.

Соображения для продакшна

• Храните время получения события отдельно от occurredAt устройства для наблюдаемости.
• Определите правила подавления оповещений и восстановления, чтобы штормы переподключений не создавали дублирующиеся инциденты.
• Относитесь к WebSocket как к каналу живых обновлений, а к REST — как к пути восстановления состояния.
• Подтверждайте поддержку событий питания при подключении устройства. Не предполагайте поддержку только потому, что другой тип устройства сообщает об этом событии.

Следующие шаги

• Панель мониторинга устройств
• Формат сообщений WebSocket (на английском)
• REST API или WebSocket