Erweiterung MQTT mit Parameter Uptime

[andreas_n]

Uptime = Wie lange ist die Wallbox Online (Tage/Stunden/Minuten)
Vorteil: Hiermit kann die Ladestation auf Ausfall überwacht werden.

Hoffe diese Variable lässt sich zum MQTT Datenhaushalt hinzufügen.

[hominidae]

...die uptime des RPi ist eher wenig aussagekräftig, oder?
Wie wäre es mit einem Timestap, zB immer wenn ein update auf ein Topic erfolgt, unter openWB/date ?

Edit: kannst Du aber auch selbst hinzufügen...die mqtt-Instanz ist "offen".
Ich nutze das schon so im openWB/evu topic....immer wenn sich was tut, wird das topic openWB/evu/date upgedated (wenn es sich dadurch ändert, im Format dd DD.MM.YY - HH:mm, ergibt zB So. 16.11.19 - 18:38).

[andreas_n]

Idealerweise schreibt die Software OpenWB die Uptime selber ins "MQTT".
Beispielhaft wie es z.B. bei ESPEasy (https://www.letscontrolit.com/wiki/index.php/ESPEasy) oder auch bei Tasmota (https://github.com/arendst/Tasmota) konfiguriert werden kann.
Letztendlich geht es mir nur um eine Online Überwachung - eine Art Watchdog - mit der (bei mir FHEM) erkennen kann, ob alle Teilnehmer Online sind.
Uptime hat den Vorteil, dass sogar ein Reboot erkannt werden kann.
Ich hatte auch schon mal die Spannung ins Auge gefasst, denn diese ändert sich auch oft. Aber leider nicht immer, sodass gelegentlich die nachgeschaltete Automatik eine Warnung ausgibt.

Ansonsten glaube ich zu verstehen, dass du gemeint hat mit "selber konfigurieren"
Sowas wie ein CronJob der zyklisch was nach dem Muster "mosquitto_pub -t openWB/$mq -r -m "$tempnewname" (ref. https://github.com/snaptec/openWB/blob/ ... pubmqtt.sh) aufruft. Die ist natürlich so möglich und damit weiß ich, dass Mosquitto und der Raspi laufen - leider nicht ob auch OpenWB glücklich ist.

[truckl]

Ich würde das Feature sogar noch etwas weiter fassen:

Wäre es nicht sinnvoll über MQTT JSON-formatierte Daten zu verschicken? Für bestimmte topics oder sogar generell für alle.
Die JSON-Daten könnten dann mindestens zwei Felder enthalten. Den Timestamp zu dem die Message abgeschickt wurde und den eigentlichen Wert.

Das hätte auf jeden Fall den in diesem Thread geforderten Effekt: Es könnte ein Ausfall der Box (oder der MQTT-Kommunikation) sicher erkannt werden.

Zudem sind bestimmte Werte ohne einen Zeitstempel faktisch nutzlos. Was sagt z.B. ein Zählerstand (wie z.B. "openWB/lp1/kWhCounter") ohne Zeitstempel? Ist das der Stand zum Jahresanfang, von Gestern oder von vor 10 Sekunden?
MQTT und dessen "retention" löst dieses Problem nicht sondern verschlimmert es eher. Denn wenn ein MQTT-Client sich verbindet bekommt er zwar den letzten Wert, aber eben ohne jegliche Information wann dieser Wert gepublished wurde.

JSON läßt sich in Javascript (also im OpenWB UI) meines Wissen problemlos verarbeiten da üblicherweise in jedem REST-Interface verwendet. Auch die MQTT-Dash App kann JSON auswerten und einzelne Felder anzeigen.
Allein das spricht doch schon dafür, daß solch ein vorgehen nicht unüblich wäre.

Letztlich (weit in die Zukunft gedacht) könnte auf Basis von JSON-Messages über MQTT sogar ein echtes, bidirektionales Protokoll zur sicheren Fernsteuerung der OpenWB entstehen welches keinerlei Port-Forwarding o.ä. erfordert. Es müßte nur eine MQTT-Bridge zu einem x-beliebigen MQTT-Server im Internet über das Web-Interface konfigurierbar sein.

Ähnliches kenne ich z.B. von den Cloud-Lösungen kommerzieller WLAN-Hardware-Hersteller die so die Steuerung des heimischen WLAN über Handy-Apps ermöglichen (da ist der MQTT-Server allerdings hart-codiert der des Hardware-Herstellers).

[hominidae]

Idealerweise schreibt die Software OpenWB die Uptime selber ins "MQTT".
Beispielhaft wie es z.B. bei ESPEasy (https://www.letscontrolit.com/wiki/index.php/ESPEasy) oder auch bei Tasmota (https://github.com/arendst/Tasmota) konfiguriert werden kann.

Ja, schon klar...

Letztendlich geht es mir nur um eine Online Überwachung - eine Art Watchdog - mit der (bei mir FHEM) erkennen kann, ob alle Teilnehmer Online sind.

Ja, aber dafür muss man keine Zeit überwachen...wer ein EVU-Kit o-ä- hat kann unter openWB/evu subscriben...da passiert immer was und man hat einen Event, der einen Time-Out resetten kann.

Uptime hat den Vorteil, dass sogar ein Reboot erkannt werden kann.

stimmt...das ist ein Vorteil.

Ich hatte auch schon mal die Spannung ins Auge gefasst, denn diese ändert sich auch oft. Aber leider nicht immer, sodass gelegentlich die nachgeschaltete Automatik eine Warnung ausgibt.

s.o....ich nutze zB node-red...subscribe auf alle topics und jage die durch einen Filter...ein Event wird immer dann generiert, wenn ein topic ein update bekommt.

Ansonsten glaube ich zu verstehen, dass du gemeint hat mit "selber konfigurieren"
Sowas wie ein CronJob der zyklisch was nach dem Muster "mosquitto_pub -t openWB/$mq -r -m "$tempnewname" (ref. https://github.com/snaptec/openWB/blob/ ... pubmqtt.sh) aufruft. Die ist natürlich so möglich und damit weiß ich, dass Mosquitto und der Raspi laufen - leider nicht ob auch OpenWB glücklich ist.

Ich nehme mein node-red (könntest Du mit FHEM machen), erkenne einen openWB event, baue den timestamp zusammen und schreibe ihn in den openWB broker (zB openWB/date) zurück.
Von da kann man ja wieder drauf zugreifen....da es durch openWB events gespeist wird, weiss man, dass die Kette aller Komponenten läuft.
Ich habe das aktuelle Datum genommen, damit ich es in anderen Flows, zB in einem anderen Dashboard wieder verwenden kann.

[hominidae]

Ich würde das Feature sogar noch etwas weiter fassen:

Wäre es nicht sinnvoll über MQTT JSON-formatierte Daten zu verschicken? Für bestimmte topics oder sogar generell für alle.
Die JSON-Daten könnten dann mindestens zwei Felder enthalten. Den Timestamp zu dem die Message abgeschickt wurde und den eigentlichen Wert.

Ich fände das auch praktischer und hatte das Kevin schon gefragt.
Es verbraucht aber wohl etwas mehr Ressourcen auf dem kleinen RPI und deshalb hat er es flach aufgebaut.
Denke es hat auch was mit der UI Integration zu tun und wie die funktioniert.

...aber eigentlich gehört die Diskussion in das MQTT-Topic, würde ich sagen: viewtopic.php?f=6&t=577

[truckl]

...aber eigentlich gehört die Diskussion in das MQTT-Topic, würde ich sagen: viewtopic.php?f=6&t=577

Du hast recht. Da ist es wohl besser aufgehoben. Das hab ich aufgegriffen und meine Antwort im MQTT-Topic abgelegt.

[andreas_n]

Danke, dass der Parameter Uptime in Betracht gezogen wurde. Ich würde dies immer noch als Ideallösung begrüßen.
Aus meiner Sicht ist ein weiterer Zeitstempel zu den anderen Parametern nicht erforderlich, da der Zeitpunkt der letzte Aktualisierung sowieso vorhanden ist. (mindestens in FHEM). JSON wäre möglich - aber diese jetzige Struktur gefällt mit sehr gut, da gezielt Einzelparameter abonniert werden können.
Sollte irgendwas diesbzg. entschieden werden, dann wäre eine kurzes finales Feedback hier nett. (Auch um dieses Topic klein zu halten)