Rückmeldungen openWB software 2.1.3 Release & Release Patch 1

[karlssonvomdach]

Hallo,

ich hab leider denselben Fehler wie er in der Beta schon mal gemeldet wurde

viewtopic.php?p=104601#p104601

Code: Alles auswählen

2024-03-15 16:00:00,969 - {root:99} - {ERROR:MainThread} - Fehler im Main-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/measurement_logging/write_log.py", line 165, in get_previous_entry
    previous_entry = content["entries"][-1]
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 90, in handler5MinAlgorithm
    totals = save_log(LogType.DAILY)
  File "/var/www/html/openWB/packages/helpermodules/measurement_logging/write_log.py", line 148, in save_log
    previous_entry = get_previous_entry(parent_file, content)
  File "/var/www/html/openWB/packages/helpermodules/measurement_logging/write_log.py", line 171, in get_previous_entry
    with open(path_list[-2], "r") as jsonFile:
IndexError: list index out of range

Es werden keine Tagesdaten angezeigt. Wenn man das Diagramm für einen Tag aufrufen will, kommt derselbe Fehler.

Hintergrund: Ich hatte nach dem Wechsel mit Datenübernahme von 1.9. auf 2.0 ständig Probleme mit dem Colors Theme und deshalb die openWB zurückgesetzt und nochmal alles neu eingetragen.
Seitdem bekomme ich keine Tagesdaten mehr.
Ich habe auch noch keine, da eben neu aufgesetzt.
Also ist dort richtigerweise noch kein Eintrag.
Aber die 2.1.3 kann leider nicht damit umgehen.
Auch im aktuellen Master 2024-03-14 11:49:47 keine Besserung.

[hoaloha]

Hallo,

hatte mich gerade gewundert warum mindestens ein Ladevorgang von heute im Ladelog fehlt. Auch in der CSV fehlte er. Gedacht System zeigt das vielleicht aus irgendeinem Grund gerade nicht an und daher einmal neu gestartet. Negativ. Weiter überlegt und dann darauf gekommen, dass der Modus seit Ladebeginn von mir nicht geändert wurde. Ladepunkt Carport (letzter Eintrag steht also immer noch auf PV Laden). Auf Stop gewechselt und siehe da, der Ladevorgang ist da (Ende 22:48Uhr).

Ich verstehe die Logik, dass PV-Laden noch immer aktiv war und somit auch der "vermeintliche" Ladevorgang, aber das macht so doch keinen Sinn, bzw. ist das Problematisch für eine Abrechnung zum Beispiel am Monatsende, wenn hier kein Wechsel oder ich nehme an auch Abstecken stattgefunden hat?! Ein PV Ladevorgang über 23h und 22min ist wahrscheinlich auch eher unrealistisch, selbst bei geringstmöglich aktiver Mindeststromstärke.

Selbst wenn bei Wolken ein Ladevorgang immer wieder unterbrochen wird (und damit Eintrage produziert), dann sind das doch im Zweifle auch 5,6,7 oder mehr Ladevorgänge. -> Evtl. kann man das ja über eine Tageszusammenfassung (Ausklappmenü) in der Anzeige dann wieder ansehnlicher darstellen?

Oder verstehe ich den Sinn/ Grund hier falsch?

Ladelog.jpg

(415 KiB) Noch nie heruntergeladen

Version: 2024-03-14 11:48:27 +0100 [1d1d842c5]

[aiole]

Ich würde einen Ladevorgang von Anstecken zu Abstecken erwarten.

[hoaloha]

Ich würde einen Ladevorgang von Anstecken zu Abstecken erwarten.

Beim Sofortladen z.B. beendet aber das Auto den Ladevorgang (und es wird dann auch ein Log geschrieben). Nach Deiner Logik müsste dann ein weitere drei Tage stehendes Auto (und sein SOC nachladen) insgesamt nur als 1 Ladevorgang über 72h+ gewertet werden.

Bei PV beendet nicht das Auto den Ladevorgang, sondern der fehlende Überschuss. Aber der Ladevorgang wir abgebrochen/ unterbrochen. Spätestens wie bei mir heute per Sonnenuntergang (ausgenommen jmd nutzt die Mindeststrom Einstellung).

Bei 1.9 und Pushover gab es ja sogar den Durchschnittswert KW des Ladevorgangs. Ist hier dann natürlich nicht möglich, bzw. werden das unsinnige Werte.

[aiole]

Bei PV-Laden kann das EV auch beenden (wenn es voll ist).

Ggf. kann man bei sw2-seitiger Unterbrechung etwas mit einer max. Tagessession (24h) einbauen, um keine Mehrtagesladungen zu bekommen. Ist dann für die Wenigfahrer:innen sicher übersichtlicher.

[hoaloha]

Bei PV-Laden kann das EV auch beenden (wenn es voll ist).

Richtig. Und das spricht auch gegen deine Logik:

Ich würde einen Ladevorgang von Anstecken zu Abstecken erwarten.

Die Tageswechsel Lösung wird nicht funktionieren, weil ein Ladevorgang auch über diesen hinweg laufen kann. Ein im Sommer laufende PV-Ladung mit Mindeststrom 6A auf einer Phase, wird möglicherweise über Mitternacht hinaus gehen.
Es muss die Unterbrechung (im Zweifel mit einem Timer) berücksichtigt werden.

[aiole]

Nö. Auto voll ist eben anders als EMS-initiiert.

Die Tageswechsel Lösung wird nicht funktionieren, weil ein Ladevorgang auch über diesen hinweg laufen kann. Ein im Sommer laufende PV-Ladung mit Mindeststrom 6A auf einer Phase, wird möglicherweise über Mitternacht hinaus gehen.
Es muss die Unterbrechung (im Zweifel mit einem Timer) berücksichtigt werden.

Man könnte einen fixen Zwischenstop um 0:00 vorgeben, um immer nur max. 24h-Vorgänge zu haben. DAS meinte ich mit "Tagessession".

[hoaloha]

Das ist/war mir klar. Ist aber nur eine Krücke und keine konsistente Lösung.

Und das „Nö“ etc. ist deplatziert. Eine Unterbrechung ist eine Unterbrechung, über die ich im Log auch informiert werden könnte. Anyway.

[xwo]

Kurz nach Mitternacht taucht mit dieser folgender Fehler im Log auf:

Code: Alles auswählen

 2024-03-16 00:00:01,684 - {root:99} - {ERROR:MainThread} - Fehler im Main-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 91, in handler5MinAlgorithm
    update_daily_yields(totals)
  File "/var/www/html/openWB/packages/helpermodules/measurement_logging/update_daily_yields.py", line 22, in update_daily_yields
    data.data.counter_all_data.data.set.daily_yield_home_consumption = totals["hc"]["all"]["energy_imported"]
KeyError: 'all'

Der folgende Fehler fehlt scheint beim Start eines Ladevorgang aufzutreten:

Code: Alles auswählen

 2024-03-15 14:17:14,285 - {helpermodules.setdata:338} - {ERROR:Setdata} - Payload ungültig: Topic openWB/set/chargepoint/5/set/current, Payload 3 liegt in keinem der angegebenen Wertebereiche.

Folgender Fehler aus dem Log des internen Ladepunkts tritt regelmäßig auf, ich kann die Zeitstempel aber keinem Vorgang zuordnen, evtl. könnte es die RFID Authentifizierung sein:

Code: Alles auswählen

 2024-03-15 17:48:03,335 - {modules.internal_chargepoint_handler.clients:107} - {ERROR:Internal Chargepoint} - LP0 Device: /dev/ttyUSB0
2024-03-15 17:48:03,505 - {modules.internal_chargepoint_handler.clients:53} - {ERROR:Internal Chargepoint} - Modbus-ID der EVSE an LP0: 1
2024-03-15 17:48:04,576 - {modules.internal_chargepoint_handler.clients:67} - {ERROR:Internal Chargepoint} - Verbauter Zähler: <class 'modules.common.sdm.Sdm630'> mit Modbus-ID: 105

Die Wallbox ist eine openWB Standard mit Display, Addon, RFID.

[electron]

Hallo Eckhard,

danke für den Hinweis. Die Fehlermeldung bedeutet, dass da Nachrichten von der Wallbox in unerwarteter Reihenfolge kommen. Komisch, dass das vorher noch nicht bei Nutzern der Master/Beta-Versionen aufgetreten ist. Ich habe jetzt eine Korrektur eingereicht, die das Problem in Zukunft vermeiden sollte. Ich weiss aber nicht, wann sie im Release verfügbar sein wird.

Claus

Nach dem Update von 2.1.2 (und inzwischen mehreren Neustarts) zeigt das Color-Theme den PV-Bogen und das Verlaufsdiagramm nicht an. Die Konsole zeigt immer folgende Meldung:

Code: Alles auswählen

index-a6d0268a.js:2 Uncaught TypeError: Cannot set properties of undefined (setting 'energy_exported')
    at Jd (index-a6d0268a.js:2:17292)
    at vh.qd (index-a6d0268a.js:2:16248)
    at ke.emit (vendor-6c3d972a.js:1:61917)
    at FO (vendor-6c3d972a.js:21:79849)
    at sR (vendor-6c3d972a.js:21:157385)
    at o (vendor-6c3d972a.js:21:162906)
    at r._write (vendor-6c3d972a.js:21:163161)
    at H (vendor-6c3d972a.js:21:46120)
    at Q (vendor-6c3d972a.js:21:45366)
    at j.write (vendor-6c3d972a.js:21:45421)

Im Standard-Theme läuft alles normal, auch im Status ist alles normal.