Geräteüberwachungs-Dashboard

Anwendungsfall

Verwenden Sie dieses Muster für ein kontoweites Dashboard, das Geräteverbindung und Peripheriezustand anzeigt und dabei einen vorhersehbaren HTTP-Traffic beibehält.

• Verwenden Sie Gerätelisten über REST für die anfängliche Darstellung, Paginierung und Hintergrundsynchronisierung.
• Verwenden Sie eine Einzelgeräteabfrage, wenn ein Benutzer explizit eine Detailansicht aktualisiert oder wenn ein Vorgang eine Bestätigung erfordert.
• Verwenden Sie WebSocket-Ereignisse für kontinuierliche Änderungen bei Verbindung, Relais und Digitaleingängen.

Fragen Sie nicht kontinuierlich jedes Gerät per HTTP ab.

Empfohlene Architektur

Führen Sie einen Zustandseintrag pro deviceId. Verwenden Sie stateUpdatedAt beim Zusammenführen von Laufzeitzustand, damit ältere Daten neuere nicht überschreiben. Verbindungsereignisse aktualisieren den Verbindungszustand; changes in device.state.changed gibt die betroffenen Relais oder Digitaleingänge an, während peripherals der vollständige Zustandsblock ist, kein inkrementeller Patch. Lesen Sie Sensor- und Analogeingangswerte, wenn ein Benutzer aktualisiert oder wenn der Geschäftsprozess es erfordert; fragen Sie nicht alle Geräte mit hoher Frequenz ab.

Schrittweise Umsetzung

1. Erhalten Sie ein Access Token mit dem device:read-Scope.
2. Rufen Sie Geräte auflisten (auf Englisch) auf, folgen Sie der Paginierung und speichern Sie deviceType, status, Peripherie und stateUpdatedAt jedes Geräts.
3. Fragen Sie Gerätetypdefinitionen auflisten (auf Englisch) ab und verknüpfen Sie jeden deviceType mit seiner Fähigkeitsdefinition. Cachen Sie diese Definitionen, statt sie bei jeder Darstellung abzufragen.
4. Erstellen Sie ein einmaliges WebSocket-Ticket (auf Englisch), stellen Sie die Verbindung her und starten Sie den dokumentierten Heartbeat-Prozess.
5. Wenden Sie die Ereignisse device.connection.online, device.connection.offline und device.state.changed auf den entsprechenden Geräteeintrag an.
6. Wenn ein Benutzer explizit aktuelle Daten für ein Gerät anfordert, rufen Sie Gerät abrufen (auf Englisch) auf oder senden Sie device.state.get (auf Englisch).
7. Nach einer Trennung oder einem Prozessneustart verbinden Sie sich mit einem neuen Ticket neu und stellen den Basiszustand über REST wieder her, bevor Sie der Live-Ansicht erneut vertrauen. Aktualisieren Sie nur geschäftskritische Geräte einzeln.

Wichtige Schnittstellen und Ereignisse

Zweck	Referenz
Anfängliche Liste und Paginierung	Geräte auflisten (auf Englisch)
Fähigkeitsbasierte Oberfläche	Gerätetypdefinitionen auflisten (auf Englisch)
Explizite Einzelgeräteaktualisierung	Gerät abrufen (auf Englisch)
WebSocket-Authentifizierung	WebSocket Ticket erstellen (auf Englisch)
Verbindungsänderungen	Geräteverbindungsereignisse (auf Englisch)
Peripheriezustandsänderungen	Ereignis für Gerätezustandsänderung (auf Englisch)

Fehler und Wiederherstellung

• Markieren Sie bei WebSocket-Verlust den Live-Kanal als nicht verfügbar, verbinden Sie sich mit exponentiellem Backoff und Jitter neu und erstellen Sie bei jedem Versuch ein neues wsTicket.
• Während der Trennung verpasste Ereignisse werden nicht erneut zugestellt. Stellen Sie den Basiszustand nach der Wiederverbindung über REST wieder her.
• Wenn Ereignis und Anfrage in Konflikt stehen, behalten Sie den Zustand mit dem neueren stateUpdatedAt.
• Warten Sie nach 429 RATE_LIMITED auf Retry-After. Wechseln Sie nicht zum Polling pro Gerät, um einen getrennten WebSocket zu kompensieren.
• Ein Gerät im Status OFFLINE kann noch den zuletzt synchronisierten Peripheriezustand enthalten. Zeigen Sie Verbindungsstatus und Datenaktualität getrennt an.

Überlegungen für die Produktion

• Führen Sie normalisierten Zustand pro deviceId; identifizieren Sie Sensormesswerte anhand von index + type.
• Machen Sie die Ereignisanwendung idempotent. Verbindungsereignisse liefern occurredAt, Zustandsereignisse stateUpdatedAt; ignorieren Sie ältere Aktualisierungen, die bereits im aktuellen Eintrag berücksichtigt sind.
• Speichern Sie geschäftskritische Ereignisse sofort dauerhaft, da WebSocket keine Verlaufswiedergabe hat.
• Verfolgen Sie Wiederverbindungsversuche, Ereignisverzögerung, REST-Synchronisierungsfehler und requestId-Werte, ohne Zugangsdaten oder Token zu protokollieren.

Nächste Schritte

• Trennungen und Stromereignisse überwachen
• REST API oder WebSocket
• Heartbeat und Wiederverbindung (auf Englisch)