Beispiel: OpenWB Visualisierung mit InfluxDB + Grafana

[truckl]

Hallo Zusammen,

ich hab mich rein interessehalber damit befaßt die Daten aus OpenWB über die Monitoring Toolchain aus InfluxDB, Telegraf und Grafana zu visualisieren.

Gleich vorweg: Grund dafür war nur der "Spieltrieb" und keinerlei Kritik an der Visualisierung durch OpenWB selbst.
Einziger Vorteil wären vermutlich die Unterstützung für beliebig viele OpenWBs im selben GUI (host umschaltbar) sowie die extrem mächtigen und fein-granular konfigurierbaren Alterungsstrategien von InfluxDB (Rententions, Continuous Queries). Spart euch aber bitte die Arbeit dieses Setup extra für eine einzelne OpenWB aufzusetzen! Außer es treibt auch euch der "Spieltrieb".

Ich möchte hier nicht die Installation von InfluxDB und Grafana erklären.
Falls ihr es neu aufsetzen wollt, gibt es dazu hinreichend Quellen im Internet für alle Varianten des Serverbetriebs (Docker, APT, ...).

Kurz eingehen möchte ich auf die Installation von Telegraf auf dem OpenWB RASPI. Das funktioniert meiner Meinung nach am einfachsten über diese Anleitung (falls nicht hält das Internet genug Alternativen bereit):

Code: Alles auswählen

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
echo "deb https://repos.influxdata.com/debian $VERSION_CODENAME stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
sudo apt-get update
sudo apt-get install telegraf

Nach der Installation von Telegraf deaktiviert ihr ihn erst mal wieder bis die Konfiguration angepaßt ist:

Code: Alles auswählen

sudo service telegraf stop

Jetzt könnt ihr euch die anghängte "telegraf.conf.template.txt" vornehmen. Sie wurde auf das Nötigste reduziert. Am Ende der Datei wird die Datensammlung von OpenWB über MQTT konfiguriert.

• Falls ihr Telegraf schon in Betrieb habt, den Teil ab "[[inputs.mqtt_consumer]]" mit eurer existieren "telegraf.conf" vereinigen. Dabei ggf. bei "servers" die Adresse der OpenWB Wallbox eintragen falls euer Telegraf nicht auf dem OpenWB RASPI läuft.
• Ansonsten in meiner Version nach "<your-" suchen und dort eure Daten eintragen (den Text in den spitzen Klammern sowie die Klammern selbst ersetzen). Hier könnt ihr auch anpassen welche Topics überhaupt in InfluxDB landen sollen. Bitte nicht "openWB/#" (also alles) weiterleiten. Denn Telegraf/InfluxDB würden das Datenformat für die OpenWB Graphen im Web-GUI nicht verstehen und reichlich Fehlermeldungen ausspucken. Die "telegraf.conf.template.txt" kommt nun nach "/etc/telegraf/telegraf.conf" (unbedingt das .template.txt entfernen) auf den RASPI der OpenWB.

Optional könnt ihr (z.B. bei Angst vor Performance-Problemen) natürlich auch die Inputs für das RASPI-Monitoring weg lassen. Ich konnte durch die angehängte Konfiguration bei meiner OpenWB aber keinerlei Probleme feststellen.

Dann Telegraf wieder starten und prüfen ob er wie gewünscht läuft:

Code: Alles auswählen

sudo service telegraf start
sudo tail -n 100 /var/log/telegraf/telegraf.log

Nur wenn der letzte Befehl Zeilen ähnlich dieser hier ausgibt kommuniziert Telegraf erfolgreich sowohl mit Influx als auch dem OpenWB MQTT Broker:

Code: Alles auswählen

2019-11-24T16:39:50Z I! Loaded inputs: cpu disk mem processes file exec diskio kernel swap system net mqtt_consumer
2019-11-24T16:39:50Z I! Loaded aggregators:
2019-11-24T16:39:50Z I! Loaded processors:
2019-11-24T16:39:50Z I! Loaded outputs: influxdb
2019-11-24T16:39:50Z I! Tags enabled: host=openWB
2019-11-24T16:39:50Z I! [agent] Config: Interval:27s, Quiet:false, Hostname:"openWB", Flush Interval:10s
2019-11-24T16:39:50Z D! [agent] Initializing plugins
2019-11-24T16:39:50Z D! [agent] Connecting outputs
2019-11-24T16:39:50Z D! [agent] Attempting connection to [outputs.influxdb]
2019-11-24T16:39:50Z D! [agent] Successfully connected to outputs.influxdb
2019-11-24T16:39:50Z D! [agent] Starting service inputs
2019-11-24T16:39:50Z I! [inputs.mqtt_consumer] Connected [tcp://127.0.0.1:1883]
2019-11-24T16:40:10Z D! [outputs.influxdb] Wrote batch of 50 metrics in 70.765514ms
[...]

Für die Visualisierung könnt ihr euch entweder selbst ein Grafana-Dashboard zusammenklicken. Oder ihr probiert das Dashboard dessen JSON-Konfiguration ich hier angehängt habe. Für letzteres in Grafana auf "Dashboards -> Manage -> Import" und den JSON-Text in das entsprechende Feld ("Or paste JSON") kopieren.
Ich habe versucht das angehängte Dashboard so universell wie möglich zu halten. Aber leider hab ich derzeit weder eine PV und/oder Speicher noch mehrere Ladepunkte. Entsprechend konnte ich dafür leider keine Dashbaord-Panels bauen.
Außerdem müßt ihr vielleicht die Limits an die eurer Installation anpassen.

Ein Beispiel was ihr damit bekommt seht ihr hier:

Screenshot des Beispiel-Dashboards

Grafana12hrsWeb.jpg (78.87 KiB) 18760 mal betrachtet

Der Teil "CP #1" sollte beim Vorliegen von Daten für mehrere Ladepunkte automatisch mehrfach erscheinen. Was ich aber in Ermangelung mehrerer LPs bei mir nicht testen konnte.
Viel Spaß damit! Vielleicht hilft's ja dem Einen oder Anderen.

Die RASPI-Daten könnt ihr z.B. mit diesem vordefinierten Dashboard visualisieren.

Ich bin jederzeit offen für Kritik oder Verbesserungsvorschläge. Gerne aktualisiere ich auch das angehängte Grafana Dashboard oder ihr postet einfach selbst eure eigenen Versionen.

[2019-11-25]
Anhänge aktualisiert für Ladepunktnummern in separatem Subtopic

[aiole]

Wow - sehr beeindruckend truckl!
Danke für Deinen "Spieltrieb" .

Ich würde noch die openWB-MQTT-Umstellung abwarten, bis ich mich da ranwage.
Aktuell ist die Logging-Anzeige noch nicht perfekt, aber Kevin hatte schon angedeutet, dass Chart.js wohl eine gute Alternative für die Standardinstallation ist.

Deine toolchain erlaubt dann noch krassere Konstellationen.

@Kevin
Würdest Du die in anderem thread angesprochene MQTT-Namensgebung jetzt mit "gerade" ziehen, um den Unterbau dann gut nutzbar zu haben?

VG aiole

[hominidae]

@truckl
Das ist richtig gut...habe endlich Zeit gefunden damit zu spielen.
Bei mir läuft alles in jeweils einem Docker (influxdb, grafana, telegraf) auf dem NAS.

Ich habe noch die PV hinzugefügt, die Legenden mit MIn/Max/Current ergänzt und bei den Ladepunkten die Stati eingefärbt, sowie bei den Ladepunkten den Ladestrom-Graph gegen die (Gesamt-)Ladeleistung getauscht (bei mir ist der Ladestrom an den Ladepunkten nie 0, selbst wenn keine Ladung aktiviert bzw kein Auto eingesteckt ist...Rundungsfehler, sagt Kevin...da sind immer um die 0.03A oder so "anliegend").

Es sieht jetzt so aus:



Mein JSON File zum Design:

OpenWB-grafana-JSON_hominidae-v0.9.txt

(126.4 KiB) 478-mal heruntergeladen

Allerdings habe ich noch zwei Schönheitsfehler...kriege die mit meinem influxQL-KnoffHoff nicht hin:

- Bei der PV geht die Anzeige des Nachts, wenn keine Sonne scheint auf "no data". Wie kriege ich es hin, das der letzte Wert "0" stehen bleibt?
Dies klappt in der Anzeige beim Ladepunkt "km Charged" prima.
Wie müsste das Influx-Query aussehen?
Bei PV ist es so:

Code: Alles auswählen

SELECT last("value") FROM "mqtt_consumer" WHERE ("host" =~ /^$host$/ AND "topic" = 'openWB/pv/W') AND $timeFilter GROUP BY time($__interval) fill(previous)

Bei "km Charged" so:

Code: Alles auswählen

SELECT last("value") FROM "mqtt_consumer" WHERE ("topic" =~ /^openWB\/lp\/$chargePoints\/kmCharged$/ AND "host" =~ /^$host$/) GROUP BY time($__interval) fill(previous)

- gleiches beim Ladestrom-Graphen an den Ladepunkten.
Da habe ich:

Code: Alles auswählen

SELECT last("value") FROM "mqtt_consumer" WHERE ("topic" =~ /^openWB\/lp\/$chargePoints\/W$/ AND "host" =~ /^$host$/) AND $timeFilter GROUP BY time($__interval) fill(previous)

Auch hier wäre es schöner wenn die "0" stehen bliebe...oder geht das beim Graph einfach nicht (wenn ich auf den Zeitraum zoome, in dem der Wert 0 erstmals aus dem mqtt-broker der openWB reingesaugt wurde, sehe ich die "0-LInie"), wenn keine Ladung in dem angezeigten Zeitraum vorhanden war?

THX,
hominidae

[ftd]

Wie kriege ich es hin, das der letzte Wert "0" stehen bleibt?

Im Panel die "Relative time" größer stellen...

panel.jpg (6.66 KiB) 17899 mal betrachtet

[hominidae]

Hmmm...ja, aber damit hole ich ja immer diese Menge an Daten ab
Im Panel für "km Charged" ist da nichts eingestellt und es funzt trotzdem

[truckl]

Erst mal vielen Dank für die Einfärbungen. Das macht's echt hübscher.

Um es vorweg zu nehmen: Mit den 0-Werten hast Du einen "wunden Punkt" erwischt. Ich muß gestehen, daß ich daran auch schon ein wenig getüftelt habe ohne eine allgemein gültige Lösung zu finden.

Das Problem ist schlichtweg daß die Werte von der openWB nur per MQTT gesendet, und somit in die InfluxDB geschrieben werden, wenn sie sich ändern. Während das in allen erdenklichen Szenarien absolut Sinn macht, verursacht es im Zusammenhang mit Influx/Grafana Probleme wenn im ausgewählten Zeitbereich schlichtweg kein einziger Wert gesendet wurde. Denn dann liefert die InfluxQL-Abfrage ein leeres Ergebnis mit dem Grafana nichts anzufangen weis bzw. welches es ganz korrekt als "No data" präsentiert.

Wenn man "fill (previous)" benutzt leuchtet es mir ja noch ein, daß Grafana nichts sinnvolles Anzeigen kann. Bei "fill (0)" ist es nicht ganz so ersichtlich, aber letztlich erscheint auch dann das Verhalten konsequent. Denn wenn es keinen Punkt gibt, gibt es auch nichts to "füllen".

Den Trick von ftd kannte ich aber noch nicht. Hab's aber leider heute auch nicht mehr geschafft das auszuprobieren.

Da ohnehin mit "last(...)" gearbeitet wird: Hast Du mal versucht anstatt "AND $timeFilter" mit einem selbstgeschriebenen Filter "AND time <= $__to" und evtl. ohne das "GROUP BY time" zu arbeiten. Dann sollte man eigentlich immer den letzten Wert bekommen der kleiner als $__to ist. Unabhängig davon ob er auch > $__from ist (Details zu den Vars gibt's hier).
Dabei ist dann aber zu beachten, daß das Panel dadurch in gewisser Weise "lügt" weil es dem benutzer den Wert präsentiert als wäre er im gewählten Intervall gültig. Das kann stimmen und korrekt sein, muß es aber nicht (z.B. wenn der Lademodus geändert wird und der Wert keine Bedeutung mehr hat).

[ftd]

Hmmm...ja, aber damit hole ich ja immer diese Menge an Daten ab

Ja, dein Interval steht auf 3 Stunden... da in der Nacht keine Sonne scheint, kommen auch keine Daten. Du kannst aber auch aus deinem

Code: Alles auswählen

fill(previous)

ein

Code: Alles auswählen

fill(0)

machen. Dann zeigt er auch 0 an. Ist ja auch 0, weil keine Daten kommen.

Oder: In Grafana 7 kannst du auch Daten transformieren / reduzieren / berechnen. Kann mir vorstellen, dass da noch was geht. Hab ich selber aber noch nicht getestet, da Grafana 7 erst ein paar Tage draußen ist.

Zu 0 schreibt Grafana:

null.jpg

(69.28 KiB) 397-mal heruntergeladen

[hominidae]

OK, danke sehr!
Das probiere ich mal aus, mit dem fill(0).
Der Trick mit den Query Options hat auf jeden Fall bei den Gauges gut funktioniert.

Hier noch ein Update...im Wesentlichen "PV Daily Yield" hinzugefügt und PV "positiv" gemacht.
Ausserdem ein paar Thresholds mehr für die Gauges und an den Legenden der Panels "gespielt".



...und die JSON dazu, für Grafana:

OpenWB-grafana-JSON_hominidae-v0.91.txt

(137.83 KiB) 451-mal heruntergeladen

[hominidae]

Da ohnehin mit "last(...)" gearbeitet wird: Hast Du mal versucht anstatt "AND $timeFilter" mit einem selbstgeschriebenen Filter "AND time <= $__to" und evtl. ohne das "GROUP BY time" zu arbeiten. Dann sollte man eigentlich immer den letzten Wert bekommen der kleiner als $__to ist. Unabhängig davon ob er auch > $__from ist (Details zu den Vars gibt's hier).
Dabei ist dann aber zu beachten, daß das Panel dadurch in gewisser Weise "lügt" weil es dem benutzer den Wert präsentiert als wäre er im gewählten Intervall gültig. Das kann stimmen und korrekt sein, muß es aber nicht (z.B. wenn der Lademodus geändert wird und der Wert keine Bedeutung mehr hat).

Hmm...ja, ich muss gestehen, ich bin gerade noch in der Lernkurve.
Mit den Variablen muss ich eh noch spielen. da ich Docker einsetze und i.d.R keine Hostnames für die Container verwende, wird bei jedem Neustart ja ein neuer (condainerID) kreiert. Zum Glück läuft telegraf seither durch

Ich will jetzt erstmal meine Idee vom PV-Forecast da einbauen.
Über influx komme ich einfach an die 10min-Mittelwerte, die ich zur Optimierung wieder an den API-Anbieter zum Tuning einsenden kann.

[hominidae]

...es gibt updates...Einbau der PV-Prognosewerte und "füttern" des Prognose-Anbieters zum Tuning der Prognose funktioniert.
erste Infos dazu hier: viewtopic.php?f=11&p=10321#p10321

...ein Ausblick:



Zum "Wie" über Node-Red und Influx/Grafana mache ich mal einen eigenen fred, bei Gelegenheit.