Virtueller HTTP Eingang - Verhalten bei Timeout

[Haidy]

Hallo,
ich habe aktuell 18 Miniserver zu betreuen und damit ich schnell einen Überblick bekomme, ob alle Miniserver laufen, habe ich mir am Miniserver im Büro eine Statusabfrage gebastelt.
Dazu habe ich für jeden Miniserver einen Virtuellen HTTP Eingang angelegt: z.B. xyz.dyndns.org:1111/dev/sps/state (Abfragezyklus 3600s / Timeout 4000ms)
Rückgabe dieser Abfrage: z.B. <LL control="dev/sps/state" value="5" Code="200"/>
Befehlserkennung: value\i="\i\v
Das ganze dann an einen Statusbaustein gekoppelt, um die einzelnen States auszuwerten, das funktioniert soweit, Problem ist aber folgendes:
Wenn ein Miniserver nicht erreichbar ist, bleibt der HTTP VI trotzdem auf dem Wert "5", obwohl kein Wert eingelesen werden kann, ich hätte hier eine "0" erwartet...

Kann ich das irgendwie abfangen, oder habe ich einen kompletten Quatsch zusammengebaut?

[Christian Fenzl]

Nein, du hast keinen Quatsch zusammengebaut, nur die Fehlererkennung von Loxone ist Mist.

Mach am besten ein Ping-Pong:
Du setzt per virtuellem Ausgang vom MS1 aus am MS2 einen Wert (zum Beispiel eine Zufallszahl), und mit einem virtuellen Eingang fragst du diesen Wert wieder ab.

Wenn in 60 Minuten der gesetzte Wert mit dem abgefragten Wert nicht übereinstimmt, gibt es ein Kommunikationsproblem zum MS2.

[Haidy]

Aja... Es gibt quasi keine Fehlererkennung
Möchte eigentlich ungern an der Programmierung der zu überwachenden Miniserver etwas ändern...

[Peter B]

Ich mach das immer so:

zu überwachender Server sendet alle 120 Sekunden einen Impuls den Ich mit meinem Server abfrage und mit dem Impuls wird ein Monoflop getriggert (Zeit 240 S) , wenn kein Impuls mehr kommt hab Ich nach 240 Sekunden eine Meldung Serverausfall

[Haidy]

Hm... blöd.
Hab dann gestern noch eine andere Variante gestestet, die funktioniert aber auch nicht zuverlässig, da nicht jedes LTE-Modem auf einen WAN-Ping antwortet...

[Christian Fenzl]

Du könntest versuchen, am überwachenden MS lokal den virtuellen Eingang per (lokalem) Ausgangsbefehl zurück zusetzen. Du setzt lokal also immer wieder z.B. auf 0, und wenn nicht in einer Stunde wieder ein Wert drin steht, ist irgendwas kaputt.
Bastelstunde mit Loxone :-)

[Haidy]

Interessante Idee! Ich weiß was du meinst, weiß aber noch nicht wie genau ich das programmiertechnisch umsetze...

[Christian Fenzl]

Ein "Virtueller Ausgang" mit http://localhost/ und virtuelle Befehle mit "/dev/sps/io/DeinEingang/0"
Ich weiß aber auch nicht sicher, ob sich VI's per VO's umsetzen lassen.

[Jan W.]

Dass der letzte eingelesene Wert bestehen bleibt, wenn eine Variable nicht gelesen werden kann, ist für viele Anwendungen sinnvoll. Warum sollte z.B. die Temperatur plötzlich auf 0 Grad gehen, nur weil es mal ein Kommunikationsproblem gibt. Am Ende wird dann vielleicht noch die Heizung im Sommer gestartet. In der Statistik sehen solche fehlenden Werte auch unschön aus. Im Winter wäre 0 Grad auch kein Signal für ein Problem, sondern ein normaler Wert.

Blöd ist allerdings, dass man bei Bausteinen nicht abfragen kann, wann der letzte Wert gelesen wurde. Oder sogar ein Alarm ausgelöst wird, wenn ein Wert X Sekunden nicht gelesen werden konnte. Hmm, noch ein Feature Request für Loxone? Bin da sehr skeptisch, ob Loxone tatsächlich mal auf die Wünsche der Anwender reagiert.

Eine andere Möglichkeit, dies für Deinen Anwendungsfall zu ergänzen: Frage doch die Sekunden seit Mitternacht vom entfernten MS ab. Entweder speicherst Du den eingelesenen Wert und vergleichst ihn mit dem aktuell eingelesenen Wert. Wenn er gleich ist, dann wurde der Wert nicht gelesen. Man könnte auch einen Watchdog über einen Monoflop realisieren, der bei ungleichen Werten wieder angetriggert wird (ähnlich dem Vorschlag von Peter B). Die Sekunden könnte man natürlich auch mit dem lokalen Wert vergleichen und bei größeren Abweichungen einen Alarm auslösen.

[Christian Fenzl]

Dass der letzte eingelesene Wert bestehen bleibt, wenn eine Variable nicht gelesen werden kann, ist für viele Anwendungen sinnvoll. .

Es gibt einen Fehlerausgang, und der funktioniert nicht. DAS ist der Mist.

[Xenobiologist]

Ist hier jemandem etwas gutes eingefallen? Ich nutze auch ein paar Virtuelle HTTP Eingänge. Z.B. Wunderground von Christian Fenzl und ich lese das eigene JSON des Miniservers aus.
Bei Wunderground bleibt temp_c auf einem alten Wert kleben und beim JSON bekomme ich nicht die aktuelle last_modified Zeit zurück, sondern eine von heute morgen.
Muss ich die Timeouts erhöhen? Kann man das irgendwie absichern? Ansonsten müsste ich wieder auf node-red ausweichen :-(

[Christian Fenzl]

Bei Wunderground kann man zumindest mit wu_current_observation_epoch (Beispiel ist im Artikel) erkennen, ob noch neue Daten hereinkommen, man kann das also als Validation verwenden, ob die Werte noch ankommen.
Beim MS-JSON gibt's wahrscheinlich keinen Wert, der sich sicher ständig ändert, weil dann könnte man es dort genauso machen.

[Xenobiologist]

Bei Wunderground kann man zumindest mit wu_current_observation_epoch (Beispiel ist im Artikel) erkennen, ob noch neue Daten hereinkommen, man kann das also als Validation verwenden, ob die Werte noch ankommen.
Beim MS-JSON gibt's wahrscheinlich keinen Wert, der sich sicher ständig ändert, weil dann könnte man es dort genauso machen.

Okay, das ist ein Ansatz. Über Nacht haben sich jetzt beide Werte korrigiert. Ich habe gestern Abend auch einen Reboot gemacht.

Das Problem beim JSON war aber auch, dass ich eine neue Konfig einspiele, dann glaube ich danach automatisch versucht wird die Zeit zu extrahieren, das beim ersten Mal warum auch immer schiefgeht und ich somit mindestens bis zum nächsten Abfrage-Intervall warten muss um die neuen Werte im Liveview zu sehen.

Eine Fehlererkennung oder ein Datum letztes Update in Loxone wäre wirklich hilfreich.


Gesendet von iPhone mit Tapatalk