Überwachung externer Integrationen

Funktionsanfrage
1

Hallo,

Wäre es möglich, eine Art Überwachung mit einer Benachrichtigung auf dem bevorzugten Kommunikationsweg zu implementieren, wenn eine externe Integration den Status „Verbunden“ in „Getrennt“ ändert (der Status muss mindestens einmal verbunden gewesen sein, sonst erhalten wir Benachrichtigungen direkt nach der Installation der externen Integration)?

Der Sinn dahinter ist, zum Beispiel bei Daikin benachrichtigt zu werden, wenn das Verbindungs-Token abläuft, um die Verbindung neu zu starten oder bei anderen Problemen, die den Status auf „Getrennt“ setzen.

Vielleicht könnte es auch eine ähnliche Benachrichtigung für den Status „Wird ausgeführt“ geben.

Danke

2

Für die TV-Integration ist das nicht möglich. Wenn der Fernseher eingeschaltet ist, erhalten wir die Info, dass wir verbunden sind. Aber wenn er ausgeschaltet wird, riskieren wir, falsche Benachrichtigungen zu erhalten.

3

Ich spreche von folgendem:

image
image1062×333 17.7 KB

Geht bei dir „Verbindung“ auf „Getrennt“ wenn der Fernseher ausgeschaltet ist?

4

Ja :slight_smile: denn der WebSocket ist geschlossen

5

Mal sehen, ob wir Ausnahmen machen können :wink:

6

Aber warum verwaltet der Dienst nicht selbst die Token-Erneuerung?
In meinem Fall, wenn ich den Fernseher wieder einschalte, habe ich ein WOL, um den Fernseher physisch einzuschalten, und eine Socket-Neuerverbindung.

Sollte der Token bei dir nicht automatisch erneuert werden, wenn er abgelaufen ist?
Es sei denn, du musst natürlich eine manuelle Aktion durchführen? :thinking:

7

Ich bin dem Fall bei Daikin nicht begegnet, denn soweit ich weiß, läuft das Token nach 1 Jahr ab
Also werde ich in einem Jahr sehen, ob es automatisch verlängert wird oder nicht :sweat_smile:

Aber ich habe das nur als Beispiel genannt, es kann auch sein, dass es im deaktivierten Zustand ist, weil Daikin zum Beispiel ein Problem hat, oder die Integration ist auf einen nicht behandelten Fehler gestoßen und ist abgestürzt und befindet sich nun im deaktivierten Zustand

8

Welche Verbindungsstatus gibt es? Eingeloggt, ausgeloggt? Vielleicht sollte es auch einen fehlerhaften Zustand geben?

9

Keine Ahnung :sweat_smile:
Ja, vielleicht wäre ein degradierter Zustand nicht schlecht

10

Hallo @prohand, hallo @spenceur!

Danke für dieses Thema, der Bedarf ist sehr real: eine Integration, die leise ausfällt (typischerweise ein abgelaufenes Token), ist der schlimmste mögliche Ausfall in der Hausautomatisierung. Nichts scheint kaputt zu sein, und man merkt es erst drei Wochen später :sweat_smile:

Gute Nachricht: Bei externen Integrationen gibt es bereits einen großen Teil der Überwachung auf Serverseite. Jede Integration sendet einen Heartbeat an Gladys, eine Gesundheitsprüfung läuft ständig, und die Integration wechselt in den Zustand degradiert, wenn sie die Verbindung zum Drittanbieter verliert oder nicht mehr reagiert, mit automatischem Neustart und Backoff dahinter.

Der « degradiert »-Zustand, den du vorschlägst @spenceur, existiert also bereits intern :+1: Was fehlt, ist der für den Benutzer sichtbare Teil: benachrichtigt werden.

Zu dem Alarm « Verbunden → Getrennt »: Das Beispiel des Fernsehers zeigt gut die Falle. « Getrennt » kann zwei völlig unterschiedliche Dinge bedeuten:

  • ein normaler Fall: Gerät ausgeschaltet, WebSocket geschlossen, erwartetes Verhalten;
  • ein anormaler Fall: abgelaufenes Token, Zugriff widerrufen, API-Fehler.

Die Unterscheidung existiert bereits teilweise im Modell (die Integration läuft, aber ihre Verbindung zur Cloud ist ausgefallen, also degradiert), man muss nur sicherstellen, dass jede Integration das richtige Signal zurückmeldet, anstatt bei jeder Trennung blind zu alarmieren.

Zu den Ausschlüssen: Ich würde vermeiden, sie zum Hauptmechanismus zu machen. Das zwingt jeden, empirisch herauszufinden, welche Integrationen « laut » sind, nachdem man falsche Alarme erhalten hat. Wenn man sie von Anfang an braucht, bedeutet das, dass das zurückgemeldete Signal nicht das richtige ist.

Konkreter würde ich also sehen:

  1. Den Zustand sichtbar machen: Der Zustand jeder Integration + das Datum des letzten erfolgreichen Austauschs, direkt in der Oberfläche. Keine Benachrichtigung, aber schon ein großer Teil des Nutzens.
  2. Eine globale Einstellung in den Gladys-Einstellungen: « Mich benachrichtigen, wenn eine Integration fehlerhaft ist ». Ein einfacher Schalter, keine Konfiguration pro Integration oder Szene zu erstellen. Und das deckt natürlich deine Anfrage @prohand « nur wenn es bereits verbunden war »: degradiert bedeutet von Haus aus « es funktionierte, es funktioniert nicht mehr ».
  3. Anti-Flapping integriert in die Einstellung: Eine Mindestdauer im degradierten Zustand, bevor eine Benachrichtigung erfolgt (um dem automatischen Neustart die Arbeit zu ermöglichen), keine Duplikate und eine Benachrichtigung über die Rückkehr zum Normalzustand. Ohne das wird diese Art von Funktion von jedem in einer Woche deaktiviert.

Zu der automatischen Verlängerung der Tokens: 100 % einverstanden mit dem Grundsatz, aber das muss Integration für Integration behandelt werden, und selbst mit einem perfekten Refresh wird es Fälle geben, in denen der Zugriff ausfällt (Widerruf durch den Hersteller, API-Änderung…). Die Überwachung muss also trotzdem existieren.

Kurz gesagt: Die Grundlagen sind bereits vorhanden, die Hauptarbeit besteht darin, all das dem Benutzer zu präsentieren :slightly_smiling_face: