openWB Forum

ChristophR hat geschrieben: Do Mär 05, 2026 5:11 pm In Deinem 2. Screenshot Geladene Energie und Entladene Energie meinte ich.

Ah, OK, das ist der CSV Export, das habe ich schon geändert.

Die "Rohdaten" in charge_log/yyyymm.json sind nicht ganz so einfach zu testen.
Mein Testsystem ist nur ein raspi und hat keinen realen sondern nur einen MQTT-Ladepunkt, der den LP der "echten" produktiven openWB quasi spiegelt.
Die Daten der produktiven openWB, die aktuell auf 2.1.9 läuft, werden per MQTT und node-red flow zum Testsystem gesendet, aber nur mit 2 Stellen.
Um das zu testen addiere ich jetzt im node.red flow im Feld imported 0,001 um eine 3. Stelle zu bekommen.
Das wird im MQTT-Explorer auch schon richtig angezeigt.
Nach der nächsten Ladung werde ich dann sehen ob das schon sauber bis in das charge_log propagiert wird.

rleidner hat geschrieben: Do Mär 05, 2026 5:04 pm

ChristophR hat geschrieben: Do Mär 05, 2026 4:25 pm

rleidner hat geschrieben: Do Mär 05, 2026 12:19 pm Jetzt wird der Km-Stand auch im Ladeprotokoll angezeigt.
odometer-ladelog1.JPG
Der Km-Stand und die 3 Nachkommastellen bei den Zählern werden auch im CSV-Export so angezeigt:
odometer-ladelog-csv.JPG

Ich dachte, die Daten stehen im charge_log und sind bereits dort gerundet abgespeichert?
Bei geladene Energie sind es noch 2 Stellen, kannst Du die auch auf 3 ändern?

Du hast Recht, im charge_log stehen die (noch) 2-stellig - hier der letzte Eintrag aus dem Screenshot oben:

Code: Alles auswählen

  {
    "chargepoint": {
...
      "imported_at_start": 5547028.81,
      "imported_at_end": 5549558.59,
...
    },
  }

Ich werde mal suchen, wo die Rundung beim Zähler (imported_at_start, imported_at_end) stattfindet und ändere das dann.

Da habe ich nicht aufgepasst - imported_at_start, imported_at_end sind in Wh, d.h. schon mit 2 Stellen sehr genau, daher wird im weitere Verlauf auch richtig gerechnet.
Ich hatte das im letzten Test auf 3 Nachkommastellen geändert, habe das aber wieder zurückgeändert, da es unnötig ist.
Ansonsten sieht der letzte Test gut aus.

Ich sehe an der Diskussion, dass das Interesse vorhanden ist.
PR kann ich erst erstellen, nachdem der PR zu diesem Thema abgeschlossen ist: viewtopic.php?t=11875 (Berechnung, wenn SoC-Daten zu alt), sonst gibt das zu viele Überschneidungen.

rleidner hat geschrieben: Sa Mär 07, 2026 5:11 pm

rleidner hat geschrieben: Do Mär 05, 2026 5:04 pm

ChristophR hat geschrieben: Do Mär 05, 2026 4:25 pm

Ich dachte, die Daten stehen im charge_log und sind bereits dort gerundet abgespeichert?
Bei geladene Energie sind es noch 2 Stellen, kannst Du die auch auf 3 ändern?

Du hast Recht, im charge_log stehen die (noch) 2-stellig - hier der letzte Eintrag aus dem Screenshot oben:

Code: Alles auswählen

  {
    "chargepoint": {
...
      "imported_at_start": 5547028.81,
      "imported_at_end": 5549558.59,
...
    },
  }

Ich werde mal suchen, wo die Rundung beim Zähler (imported_at_start, imported_at_end) stattfindet und ändere das dann.

Da habe ich nicht aufgepasst - imported_at_start, imported_at_end sind in Wh, d.h. schon mit 2 Stellen sehr genau, daher wird im weitere Verlauf auch richtig gerechnet.
Ich hatte das im letzten Test auf 3 Nachkommastellen geändert, habe das aber wieder zurückgeändert, da es unnötig ist.
Ansonsten sieht der letzte Test gut aus.

Ich sehe an der Diskussion, dass das Interesse vorhanden ist.
PR kann ich erst erstellen, nachdem der PR zu diesem Thema abgeschlossen ist: viewtopic.php?t=11875 (Berechnung, wenn SoC-Daten zu alt), sonst gibt das zu viele Überschneidungen.

Es scheint einen Fehler in der Berechnung der Ladekosten zu geben, der über die Rundungsdifferenzen hinaus geht.
Die Kosten, die im chargelog ausgewiesen sind stimmen wohl entgegen meiner ersten Annahme doch nicht.
Ich habe es hier gemeldet:
viewtopic.php?p=140717#p140717

Wenn die Zählerstände im chargelog so genau erfasst sind, lassen die sich ja doch ohne Flux Compensator optimieren.
Danke für Deine Mühe, ich freue mich auch schon auf die Kilometerstände, da warte ich geduldig auf beide PRs.
Besonders der mit dem veralteten SoC ist mir wichtig. Ich bin echt erschreckt, wie unzuverlässig der Online-SoC von Cupra kommt, ich war mit dem WiCAN kaum Abweichungen beim Laden gewohnt...

Noch eine Rückfrage (bzw. FeatureRequest) zum Ladeprotokoll selbst, wieder etwas OffTopic, da es nicht nur den km-Stand betrifft.
(Du weißt ja, was passiert, wenn man jemandem den kleinen Finger reicht)

Unter Einstellungen/Allgemein (http://openwb/openWB/web/settings/#/Gen ... figuration) kann man konfigurieren, welche Datenfelder man beim Ladeprotokoll sehen möchte. Gibt es da dann auch den km-Stand, falls den nicht alle sehen wollen?

Beim Export wird diese Konfiguration jedoch gar nicht berücksichtigt, nur für die Ansicht.
Ich weiß zwar nicht, wie es anderen geht, daher ist eine Änderung dort evtl. nicht gewünscht, aber ich hätte auch gerne im Export die gleichen Felder wie in der Ansicht. Die PV-Aufteilung hat z.B. in meinen Exporten an den AG nichts zu suchen, da sie nicht relevant sind. Das passe ich immer nachträglich an.

Beim Button unten (oder ggf. getrennten Buttons, z.B. Gesamter/Reduzierter CSV-Export) hätte ich erwartet, dass diese Konfiguration berücksichtigt wird. Im Downloadlink oben auf der Seite hätte ich dann unabhängig von der Konfiguration alle Datenfelder erwartet.
Wie aufwendig wäre denn solch eine Umsetzung? Sie müsste natürlich abgestimmt werden, da sich evtl. andere auf ein gleichbleibendes Format zur Vorversion verlassen. (Daher ggf. als weiteren Button).

Der Export basiert auf einer anderen Logik. Daher nicht ganz so trivial.

ChristophR hat geschrieben: Sa Mär 14, 2026 1:37 am Unter Einstellungen/Allgemein (http://openwb/openWB/web/settings/#/Gen ... figuration) kann man konfigurieren, welche Datenfelder man beim Ladeprotokoll sehen möchte. Gibt es da dann auch den km-Stand, falls den nicht alle sehen wollen?

Beim Export wird diese Konfiguration jedoch gar nicht berücksichtigt, nur für die Ansicht.
Ich weiß zwar nicht, wie es anderen geht, daher ist eine Änderung dort evtl. nicht gewünscht, aber ich hätte auch gerne im Export die gleichen Felder wie in der Ansicht. Die PV-Aufteilung hat z.B. in meinen Exporten an den AG nichts zu suchen, da sie nicht relevant sind. Das passe ich immer

In der Ansicht wird der Km-Stand konfigurierbar sein wie die anderen Felder.

Wie openWB schon sagte ist der CSV-Export in einer anderen Logik, daher würde ich das erst mal getrennt sehen.
Da beides im UI/vue passiert sollte prinzipiell die Filter-Logik der Ansicht auch auf den CSV-Export anwendbar sein.
Ich vermute aber dass dann gleich die Frage kommt, für Ansicht und Export verschiedene Filter zu haben

rleidner hat geschrieben: Sa Mär 14, 2026 7:48 am

ChristophR hat geschrieben: Sa Mär 14, 2026 1:37 am Unter Einstellungen/Allgemein (http://openwb/openWB/web/settings/#/Gen ... figuration) kann man konfigurieren, welche Datenfelder man beim Ladeprotokoll sehen möchte. Gibt es da dann auch den km-Stand, falls den nicht alle sehen wollen?

Beim Export wird diese Konfiguration jedoch gar nicht berücksichtigt, nur für die Ansicht.
Ich weiß zwar nicht, wie es anderen geht, daher ist eine Änderung dort evtl. nicht gewünscht, aber ich hätte auch gerne im Export die gleichen Felder wie in der Ansicht. Die PV-Aufteilung hat z.B. in meinen Exporten an den AG nichts zu suchen, da sie nicht relevant sind. Das passe ich immer

In der Ansicht wird der Km-Stand konfigurierbar sein wie die anderen Felder.

Wie openWB schon sagte ist der CSV-Export in einer anderen Logik, daher würde ich das erst mal getrennt sehen.
Da beides im UI/vue passiert sollte prinzipiell die Filter-Logik der Ansicht auch auf den CSV-Export anwendbar sein.
Ich vermute aber dass dann gleich die Frage kommt, für Ansicht und Export verschiedene Filter zu haben

Ich habe mir das jetzt genauer angesehen.
Der csv-Export passiert in einem php-Script das erst mal keinen Zugriff auf die in der Anzeige benutzten Filter hat.
Ich denke das ist eher Kosmetik; die nicht benötigten Felder können in der weiteren Verarbeitung leicht ignoriert werden.
Daher werde ich daran nichts ändern.