Charger status und charge mode in influxDB speichern und in Grafana anzeigen - wie?

[wolfgangr]

Mein Visualisierung kriegt langsam ein Gesicht.
Allerdings sehe ich bisher nur numerische Daten, v.a. Leistungswerte (und kumuleirte Energie)
Klar, man kann sich den Status dann schon zusammen reimen, aber schöner wäre es, die Statuswechsel mit zu loggen.

Im Logfile finde ich

charger status: { A | B | C | D }
set charge mode: { minpv | pv | off | now }

• kann ich evcc-Export so konfigurieren, daß das gleich mit in Bucket kommt?
• tuckert das über mqtt?
• es gibt glaub' ich ein log-file Plugin für Telegraf. Hat jemand damit Erfahrung?
• api??
• sonstige Idee?

[VolkerK62]

tuckert das über mqtt?

ja.
evcc/loadpoints/1/mode
evcc/loadpoints/1/connected
evcc/loadpoints/1/charging

connected: false = Status A
connected: true + charging: false = Status B
charging: true = Status C

[wolfgangr]

Ich weiß, jetzt werde ich pingelig.: 😉

.... und was ist mit Status F?
z.B. modbus-Verbindung abgerissen ( ...wörtlich 🙈 🙊)
.... oder ... oder ... Netzwerk, Stromausfall, WLAN, Wallbox geklaut, ....

wäre das Sahnehäubchen, wenn man das sofort im Dashboard sähe.

Im Logfile wäre es zu sehen, aber eigentlich möcht' ich das debug-logging demnächst abschalten, weil es doch ganz schön Plattenplatz frisst.

Was ich dann trotzdem auch noch eine Zeit lang halten möchte (bis mein Speicher wieder läuft....), wäre die Zeile mit dem Plan-Strom.

Könnte man das irgendwie über mqtt raus schicken?

Sep 29 00:03:16 homeserver evcc[3315380]: [lp-1  ] DEBUG 2024/09/29 00:03:16 charger status: F
   .....
Oct 13 14:29:50 homeserver evcc[3439618]: [lp-1  ] DEBUG 2024/10/13 14:29:50 charger status: B
Oct 13 14:29:50 homeserver evcc[3439618]: [lp-1  ] DEBUG 2024/10/13 14:29:50 pv charge current: 19.6A = 0A + 19.6A (-13549W @ 3p)

[wolfgangr]

https://docs.evcc.io/docs/reference/plugins#mqtt-lesenschreiben

Beispiel Schreiben:

source: mqtt
topic: mbmd/charger/maxcurrent
payload: ${var:%d}

kann ich damit beliebige interne Variablen raus schicken??

[RenatusRo]

ist dann in grafana mit 'state timeline' schnell erledigt:

[wolfgangr]

und wenn jetzt der Spickzettel noch irgendwo rum liegt, wie Du das von mqtt in influx gebracht hast?
Telegraf?
Vielleicht a bisserl von der config?
Danke :-)

[VolkerK62]

ich weiß nicht, was Renatus empfiehlt, ich nutze dafür Node Red.

[RenatusRo]

ja, telegraf. aber ich muss sagen, ich hab' mir das vor 'nem jahr zusammengegoogelt und instantly vergessen ... (unter ubuntu)

[wolfgangr]

für's Protokoll:

Input-Plugin in Telegraf:
(ich hab' "charging" noch dazu genommen, und wegen meinem Kia-Phasen-Hack auch noch die aktiven Phasen)

$ tomlq -t . evcc_status_mqtt_in.conf 
[inputs]
[[inputs.mqtt_consumer]]
servers = [ "tcp://127.0.0.1:1883",]
topics = [ "evcc/loadpoints/+/mode", "evcc/loadpoints/+/connected", "evcc/loadpoints/+/charging", "evcc/loadpoints/+/enabled", "evcc/loadpoints/+/phasesActive",]
log_level = "debug"
name_override = "evcc_status"
tagexclude = [ "host", "topic",]
data_format = "value"
data_type = "string"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "evcc/loadpoints/+/+"
measurement = "_/measurement/_/_"
tags = "_/_/loadpt/aspect"

$ tomlq -t . ../conf_available/evcc_filter_converter.conf
[processors]
[[processors.converter]]
[processors.converter.tags]
measurement = [ "aspect",]

Ich hätt' auch noch die Strings auf Integer gemapped (enum plugin), aber der Status Bar von Grafana kommt mit den Strings besser klar.

Das wird dann so an Influx geschickt (print plugin)

Oct 13 14:00:20 homeserver telegraf[3625075]: connected,loadpt=1,target_bucket=evcc_status value="true",status_code=1i 1728820820827000728
Oct 13 14:00:20 homeserver telegraf[3625075]: charging,loadpt=1,target_bucket=evcc_status value="false",status_code=0i 1728820820827401397
Oct 13 14:00:20 homeserver telegraf[3625075]: enabled,loadpt=1,target_bucket=evcc_status value="false",status_code=0i 1728820820950806876
Oct 13 14:00:20 homeserver telegraf[3625075]: mode,loadpt=1,target_bucket=evcc_status value="off",status_code=10i 1728820820951235594

Und das ist dann die Flux-Abfrage für Grafana

from(bucket: "evcc_status")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "charging" or r["_measurement"] == "connected" or r["_measurement"] == "enabled" or r["_measurement"] == "mode" or r["_measurement"] == "phasesActive")
  |> filter(fn: (r) => r["_field"] == "status_code")
  |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false)
  |> yield(name: "last")

[wolfgangr]

kleiner Schönheitsfehler:

Krieg' ich in der state timeline von Grafana die Labels der Zeitreihen nach rechts, so wie die Legenden in den normalen Zeitreihen?
Ich hab' zwar einen gekoppelten Cursor, wenn ich also über ein Chart fahre, fährt der in den anderen mit.
Aber schön wäre es, wenn das auch noch optisch sauber untereinander läge

[wolfgangr]

Noch ein Schönheitsfehler:
Mir fehlt noch der Status, wenn er wegen eines Ladeplanes lädt.
Hab' erst einen Bug vermutet, als plötzlich "Mondscheinladen" aktiv war 🙈 .

Nachdem mein Kia-Hack seinen Status auch nur über mqtt bezieht, limitiert der den Ladestrom (mangels Sonne) auf 6 A, der Kia schaltet auf 2 Phasen, und es gehen nur mehr 2,8 kW durch den Charger. Nicht gut für den Familienfrieden 😳, wenn's am nächsten Morgen pressiert ....

hab' mal einen extra Faden
Sagt mir mqtt evcc/loadpoints/1/planActive , ob er aktuell grad wegen Ladeplan lädt? #16954
dafür aufgemacht.

[wolfgangr]

Tut jetzt halbwegs was er soll.
Bei der Gelegenheit kann ich auch meine Version des Dashboards präsentieren:

Die vertikale Positionierung könnte noch etwas Feinarbeit vertragen.
Aber mit dem synchronisierten Cursor und dem gekoppelten zoom über ausgewählte Zeitbereiche kann man trotzdem recht genau analysieren, was und warum die Mühle tut - oder eben auch nicht.
Alles Andere diente nur der Schönheit, und Schönheit wird nicht bezahlt.
Ok, blöder Witz in einem FOSS-Forum ... 😇 🤣

Das Balkendiagramm integriert über den gesamten angezeigten Zeitraum.
Damit kann man jeden beliebigen Zeitraum auswählen, Grafana zoomt rein und damit werden die kumulierten Energieflüsse dargestellt.

[wolfgangr]

Das war Samstag, 26. Oktober:

Ich muß leider scrollen, wenn ich Erzeugung und Verbrauch zusammen sehen möchte.
Summen und Status sind dann weg.

Es war ein trüber Nebeltrag, erst am Nachmittag hat's für zwei Stunden aufgerissen, bevor es dann schon wieder dunkel wurde.
Trotzdem hat's für 45 kWh PV gereicht (aus 30 kWp).
Davon gingen 15 kWh in die Haushalte und 28 kWh in die Auto-Ladung.
3 kWh Bezug und 5 kWh Einspeisung sind für derart schwankende Produktion gar nicht mal so schlecht.
Vor allem mit der Kia-Macke, bei 7 bis 8A von 2 auf 3 Phasen umzuschalten.
Das gibt eine Lücke zwischen 2,8 und 5,4 kW-Stunden, in der das Netz nicht auf Null geregelt werden kann.

Ich hab' versucht, den Aufbau der Graphik dem sunny-portal anzunähern, mit dem wir uns bisher notdürftig über die Runden gerettet haben.

Im "Verbrauch" sind Haus, Charge und Neztzeinspeisung flächig gestackt.
PV-Produktion liegt mit Nullbezug drüber (graublaue Linie).
Man kann damit, denke ich, die Eigenproduktion und Aufteilung auf die Prioritäten sehr schön ablesen.

In "Erzeugung" sind PV und Netzbezug flächig gestackt.
Die Oberkante sollte sich mit der dunkelblauen Linie "totalPower" im Verbrauchs-Diagramm decken.
Die Verbraucher sind hier beide als Linien drüber gelegt - jeweils mit Nullbezug, nicht gestackt.
Damit sieht man die PV-Deckung unabhängig von einer Priorisierung.
Und man kann schön auch die Leistungssprünge beim Ein- und Ausschalten und beim Kia-Phasen-Tanz erkennen.

Bei scharfen Spitzen sieht man in hoher Auflösung (1 min) Digitalisierungsartefakte.
Der Netzzähler wird von evcc aus shared memory abgefragt, der im 2-s-Takt aktualisiert wird.
Ich weiß nicht, ob und wie evcc da integriert oder mittelt.
Nach Influx kommen 20-s-Werte via mqtt.
Teilweise sieht man auch Unterschiede zwischen Plan- und Messwerten.
Man könnte jetzt die Daten weiter verwischen, um das Problem zu kaschieren - lösen tut man's damit nicht.

[wolfgangr]

Vielleicht will sich ja jemand inspirieren lassen - hier die Flux-Abfrage für das letzte Bild.

Ich hab die Daten aus zwei Buckets - einmal von evcc direkt und einmal über telegraf gefüllt.
Die beiden streams werden zur Optimierung schon in influx verknüpft.
Das Ganze steckt in einem (fast) versteckten Panel, das in die beiden anderen als Dashboard-source importiert wird.
Damit entkopple ich die Abfrage vom graphischen Feintuning.

Die ersten zehn Zeilen vergröbern die Auflösung, die von Grafana sonst auf Pixel vorgegeben würde, und setzt sie auf runde Werte.
Damit kann ich das Chart von Tagessummen über Monate bis zu minutengenauer Detailanalyse durch zoomen.
30 Tage z.B laden in einem Sekundenbruchteil, obwohl 40.000 Datenpunkte zu verrechnen sind.
(Für die Statusbalken hab' ich das nicht, da sieht man bei langen Zeiträumen nur Ladeindikator)

import "date"
downscale = date.scale(d: v.windowPeriod, n:8)
myscale = if int(v: downscale) < int(v: 1m)
    then 1m
    else if int(v: downscale) < int(v: 30m)  
    then downscale
    else if int(v: downscale) < int(v: 3h)
    then 1h
    else 1d
// myscale = date.scale(d: v.windowPeriod, n:10)
t1 = from(bucket: "evcc_log")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "homePower" or r["_measurement"] == "pvPower" or r["_measurement"] == "chargePower")
  |> filter(fn: (r) => not exists r.id)
  |> drop(columns: ["vehicle" , "loadpoint", "_field"] )
  |> aggregateWindow(every:  myscale, fn: mean, createEmpty: false)
  // |> map(fn: (r) => ({ r with _value: r._value * 0.001 }))
  // |> yield(name: "mean")

t2 = from(bucket: "SMA_HM")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "mqtt_consumer")
  |> filter(fn: (r) => r["_field"] == "pconsume" or r["_field"] == "psupply")
  |> drop(columns: ["topic" , "host" , "_measurement" ] )
  |> rename(columns: {_field: "_measurement"})
  |> aggregateWindow(every:  myscale, fn: mean, createEmpty: false)
  // |> map(fn: (r) => ({ r with _value: r._value * 0.001 }))
  // |> map(fn: (r) => ({ r with _value: - r._value  }))
  // |> yield(name: "mean")

union(tables: [t1, t2])
  |> map(fn: (r) => ({ r with _value: r._value * 0.001 }))