Zielladen mit zwei Zeiten

[Pendragon]

Moin!

Nachdem ich hier schon angefangen habe das Problem zu schildern, habe ich dann heute morgen gemerkt, dass es wohl doch, aufgrund der Komplexität (zumindest aus meiner Sicht) einen eigenen Thread verdient.

Ich habe eine OpenWB-Custom mit Adapterplatine und folgender Struktur:

Struktur.jpg (24.35 KiB) 804 mal betrachtet

Die Einstellungen zum Zielladen sind wie folgt:

ZielladeEinstellungen.jpg (93.97 KiB) 804 mal betrachtet

Das Hauptproblem sieht man sehr gut in der folgenden Grafik:

StartdererstenLadung.jpg

(107.49 KiB) Noch nie heruntergeladen

Hier sind aus meiner Sicht folgende Dinge falsch (wobei ich nicht ausschließen möchte, dass Config-Fehler dabei sind):

• Die Zielladung beginnt zu zwei Zeipunkten, wobei die Zielladung nur erreicht werden würde, wenn zum ersten mit Voller Leistung geladen würde
• Während der zweiten Ladephase, wird die Leistung am EVU-Punkt nicht gezählt/erfasst/dargestellt
• Bzw. wird nach Abbruch der ersten Ladephase überhaupt keine Leistung mehr erfasst. In der Zeit habe ich heute z.B. die Kaffeemaschine angeschaltet, Rechner hochgefahren...
• Nachdem der Zieltermin erreicht ist, wird mit 6A weitergeladen, obwohl das Fragezeichen in den Einstellungen sagt, dass nur mit Überschuss geladen werden soll
• Die Meldung "LP 1: Die Einstellungen in dem Fahrzeug-Profil beschränken den Strom auf mindestens 6 A." ab 07:10 macht aus meiner Sicht keinen Sinn... Hängt aber vermutlich mit dem vorigern Fehler zusammen.
• Unter _Konfiguration->Auswertungen_ sehe ich einen riesen Peak um 07:10, am Ende der Zielladung. Dieser Peak ist im normalen Diagramm nicht vorhanden
• Nebenfund: Die Log-Dateien sind nicht zeitlich geordnet, sondern springen. Der (zeitliche)Anfang des Logs ist in der Mitte der Datei.

Hier noch der Screnshot des Peaks:

PeakImZweitenDiagram.jpg (25.7 KiB) 804 mal betrachtet

---------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------
Was ich schon rausgefunden habe:
Es wird anscheinend von vornherein mit zwei Zeitplänen zum Ziellanden geplant, wobei der spätere mit meiner 11kW Box nie den Ziel-SoC erreichen kann:

Code: Alles auswählen

2024-02-27 21:10:20,611 - {control.chargepoint.chargepoint:541} - {DEBUG:MainThread} - EV-Phasenzahl beschränkt die nutzbaren Phasen auf 3
2024-02-27 21:10:20,611 - {control.chargepoint.chargepoint:524} - {DEBUG:MainThread} - Phasenzahl Lademodus: 1
2024-02-27 21:10:20,613 - {helpermodules.timecheck:186} - {DEBUG:MainThread} -[u] delta 0:26:15 start_time 2024-02-27 06:43:45 end 2024-02-27 07:10:00 [/u]now 2024-02-27 21:10:20.612941
2024-02-27 21:10:20,614 - {helpermodules.timecheck:186} - {DEBUG:MainThread} - delta 0:26:15 start_time 2024-02-28 06:43:45 end 2024-02-28 07:10:00 now 2024-02-27 21:10:20.612941
2024-02-27 21:10:20,616 - {control.ev:734} - {DEBUG:MainThread} - Plan-Nr. 1: Differenz zum Start 34404.387059s, Dauer 0.4375h, Termin heute verpasst: False
2024-02-27 21:10:20,617 - {helpermodules.timecheck:186} - {DEBUG:MainThread} - delta 1:18:45 start_time 2024-02-27 05:51:15 end 2024-02-27 07:10:00 now 2024-02-27 21:10:20.617162
2024-02-27 21:10:20,618 - {helpermodules.timecheck:186} - {DEBUG:MainThread} - delta 1:18:45 start_time 2024-02-28 05:51:15 end 2024-02-28 07:10:00 now 2024-02-27 21:10:20.617162
2024-02-27 21:10:20,619 - {control.ev:734} - {DEBUG:MainThread} - Plan-Nr. 1: Differenz zum Start 31254.382838s, Dauer 1.3125h, Termin heute verpasst: False
2024-02-27 21:10:20,620 - {control.ev:783} - {DEBUG:MainThread} - Verwendeter Plan: Zielladen-Standard

Mehr kann ich leider aus dem Logs nicht rauslesen. Ich hänge die relevanten um den Zeitpunkt heute morgen hier mal an. Der MQTT log scheint mir übrigens auch sehr komisch geordnet. Zumindest konnte ich mich darin nur mit Hilfe von Notepad++ nicht zurechtfinden.

2024-02-28 06_40-MAIN.txt

(4.96 MiB) 10-mal heruntergeladen

Die MQTT Logs und der vom Ladepunkt kommen im nächsten Post, da die Anzahl der Anhänge auf 5 begrenzt ist.

Besten Dank im Voraus schonmal, wenn sich dem jemand annehmen könnte.
Christian

[Pendragon]

Hier die weiteren Logs:

2024-02-28 06_40-Ladepunkt.txt

(4.18 MiB) 24-mal heruntergeladen

2024-02-28 06_40-MQTT.txt

(3.8 MiB) 9-mal heruntergeladen

[openWB]

Laut Graph kommen zwischen 6 und 7 Uhr schonmal keine Daten an den MQTT EVU Zähler an.
Das erklärt auch direkt den Peak im Graph.
Wie bereitest du die Daten auf und sendest die an die openWB?

[Pendragon]

Die Daten kommen von einem Huawei Wechselrichter und dort lese ich den Zähler am EVU Punkt über Modbus TCP mit Solaranzeige aus, korrigiere die Vorzeichen der Werte, und packe sie in Arrays und sende sie dann mit MQTT über Edomi (Hausautomationsserver für KNX) an die Wallbox.

Jetzt wo du es sagst, habe ich mal in andere logs geschaut... Soaranzeige sendet genau zwischen 05:10 und 07:10 keine Daten an Influx und dementsprechend auch nicht an die nachgeschalteten MQTT Quellen... Wie so eine einfache Frage doch helfen kann.

Grafana.jpg (22.94 KiB) 799 mal betrachtet

Was mich nur irritiert: Warum habe ich bis zum Abbruch der ersten Ladung noch plausible Werte in der OpenWB Anzeige?

EndeDerErstenLadung.jpg (33.11 KiB) 799 mal betrachtet

Und warum stimmen diese Daten mit den geplanten Ladezeitpunkten zusammen.
Ich schaue mal, ob ich die MQTT-Daten auch irgendwo logge. Sind die sonst nicht in dem MQTT-Log drin? Da habe ich aber garkeine externen Daten gefunden.

[Pendragon]

Okay, langes suchen in verschiedenen logs und tatsächlich, wurde heute zwischen 05:51 und 07:10 keine Leistung vom EVU Zähler empfangen. Hier das Sendelog von Edomi. Auch finde ich dort in den internen Logs keine Empfangenen Daten von Solaranzeige.

Code: Alles auswählen

2024-02-28 05:47:20	112864	50609	debug 	EXE19001053 [v0.8]: Publishing topic: openWB/set/counter/2/get/power with payload: 1448 and qos: 1 and retain: 1 (1957)
2024-02-28 05:49:36	613102	52181	debug  	EXE19001053 [v0.8]:	Publishing topic: openWB/set/counter/2/get/power with payload: 300 and qos: 1 and retain: 1 (1957)
2024-02-28 05:50:13	941730	52641	debug  	EXE19001053 [v0.8]:	Publishing topic: openWB/set/counter/2/get/power with payload: 307 and qos: 1 and retain: 1 (1957)
2024-02-28 05:51:30	224351	53523	debug  	EXE19001053 [v0.8]:	Publishing topic: openWB/set/counter/2/get/power with payload: 302 and qos: 1 and retain: 1 (1957)
2024-02-28 07:10:02 660581 43271 	debug  	EXE19001053 [v0.8]:	Publishing topic: openWB/set/counter/2/get/power with payload: 10259 and qos: 1 and retain: 1 (1957)

Ich konnte weiterhin feststellen, dass es sich wohl um einen Netzwerkfehler handelt, da ja auch die influxdb nicht erreichbar war. Auch die OpenWB hat sich zu den Zeiten vom Netzwerk abgemeldet:

Router DisconnectionOpenWB.jpg (39.19 KiB) 789 mal betrachtet

Aaaaaaaaaber:
Das beschriebene Verhalten habe ich schon seit Beginn:

02_Ladeverlauf2024-02-28.jpg (11.16 KiB) 789 mal betrachtet

02_Ladeverlauf2024-02-21.jpg (14.27 KiB) 789 mal betrachtet

02_Ladeverlauf2024-02-20.jpg (4.64 KiB) 789 mal betrachtet

Die einzige Änderung für heute war das Anschalten des Debug-Logs (und ich habe gestern abend noch die Phasen rotiert, damit L1 entlastet wird(der Vollständigkeit halber))

Der Regelfehler liegt also nicht an den fehlen den Daten und ist auch in der Relase Version vorhanden, die ich bis vor kurzem drauf hatte.
Zu den fehlenden Daten: Mich irritiert sehr, dass die Daten abbrechen, sobald OpenWB anfängt zu laden (05:51) bzw. Laden soll entsprechend dem Plan aus dem Debug Log und die Daten genau zu der Uhrzeit wieder erscheinen, wenn die Zielladung erreicht sein soll (07:10).

Es gibt ja Zufälle, aber...
Fragt die OpenWB evtl. Modbus-TCP im Broadcast ab?
An einer Netzeinkopplung kann es eigentlich nicht liegen, da das Laden sonst (wenn es kein Zielladen ist) normal aufgezeichnet wird.

[Thomas aus W]

Nachdem der Zieltermin erreicht ist, wird mit 6A weitergeladen, obwohl das Fragezeichen in den Einstellungen sagt, dass nur mit Überschuss geladen werden soll

Das ist ein Feature des Zielladens.
Da wird mit Mindestladeleistung Strom für die Vorklimatisierung bereit gestellt.
Hatte ich hier schon mal angesprochen:
https://forum.openwb.de/viewtopic.php?p=103306#p103306

bye
TW

[Pendragon]

Das ist ein Feature des Zielladens.
Da wird mit Mindestladeleistung Strom für die Vorklimatisierung bereit gestellt.

Danke für die Info!
Dann kommt das mit auf meine Liste, die ich noch im Wiki aufnehmen muss.

Bei mir klappt das aktuall aber nicht, da ich das Zielladen weit vor die geplante Abfahrt legen muss um mit diesem "Nachstrom" in die Nähe des gewünschten SoC zu kommen. Wenn der Fehler gefunden ist, kann ich dann die Zeit ja genau auf Abfahrt legen.

[Thomas aus W]

da ich das Zielladen weit vor die geplante Abfahrt legen muss um mit diesem "Nachstrom" in die Nähe des gewünschten SoC zu kommen.

Bist Du der Empfehlung aus der Hilfe gefolgt, für das Zielladen nicht den Maximalstrom einzutragen?

bye
TW

[Pendragon]

Bist Du der Empfehlung aus der Hilfe gefolgt, für das Zielladen nicht den Maximalstrom einzutragen?

Stell dir vor, ich sitze hier gerade mit der Handfläche fest an die Stirn gehaen...

Natürlich habe ich das nicht eingestellt, sondern der Default-Wert, den die WB technisch gar nicht erreichen kann...

Ich werde es morgen früh nochmal mit einem kleineren Wert ausprobieren, aber dann vermute ich jetzt schonmal, dass das Problem vor dem Rechner saß und erledigt ist.
Vielen Dank für das freundliche und nachsichtige RTFM!

Bleibt nur noch die Bschriftung des Status: "LP 1: Die Einstellungen in dem Fahrzeug-Profil beschränken den Strom auf mindestens 6 A."
sowie die ungeordneten Logs übrig (wenn es morgen früh denn so läuft wie ich erwarte)

[LenaK]

Nein, dieses Feature gibt es nicht. Soll Strom für die Vorklimatisierung bereit gestellt werden, sollte dafür Zeitladen genutzt werden. Zeitladen stellt zur festgelegten Uhrzeit die angegebene Stromstärke zur Verfügung.