Umbau Phasenumschaltung für WARP 1

[fepilins]

Moin zusammen,

ich war so frei und habe die 2.1.5 ohne SoC Modul auch mal installiert. Sieht nach 3,5h Uptime soweit gut aus.

Ich hatte mir die ToDo's für den Merge auf eine neuere Codebasis auch mal angeschaut, aber steige da leider nicht so wirklich durch. In diesem Sinne vielen Dank für deine Arbeit.

Gruß Felix

[ThomKa]

@borg vielen Dank für Deine Ausführung. Das ist für mich auch gut so. Beim BoostMode war ich mir nicht sicher, ob er dafür gedacht war. Dann aktiviere ich den mal.

[mattsches]

So, hier mal wieder ein Update. In einer längeren Aktion habe ich nun auch die Charts wieder in das Frontend hineinoperiert. Das war etwas mühsam, schaut aber jetzt wie ich finde ganz gut aus. An der Funktion der Phasenumschaltung selbst hat sich nichts geändert.

Achtung, das ganze basiert auf dem aktuellen Entwicklungsstand von Tinkerforge von gestern MIttag (Commit 50bff1bdbd0fd13ed4105569800473188b691953). Also nicht mehr auf dem letzten offiziellen Release der Firmware.

Wer interessiert ist, bitteschön:

warp_firmware_2_1_5_65337f7b_5e06939a5f34f83_merged.bin

[ThomKa]

Hey Matthias, wieder einmal vielen Dank für Deine Mühe👍. Würde ich gerne direkt ausprobieren,bin aber erst Anfang November zurück... Bis denn'e 😁

[deepflyer911]

Grüße,

 

neuste Version läuft ohne Probleme. Die erste Ladung heute bei feiner Sonne ohne Einschränkungen.

[deepflyer911]

Grüße zusammen,

was mir aufgefallen ist, aber glaube auch schon bei den vorherigen Version der Fall war, wenn ich das Auto anstecke, bevor ein Überschuß vorhanden ist, startet die Ladung zu einem späteren Zeitpunkt nicht automatisch, wenn ausreichend Überschuß vorhanden ist. Das Auto neu anstecken hilft dann.

Gibt es da eine Einstellung die dieses Problem behebt?

[mattsches]

Hi @deepflyer911 , bei mir startet in der Situation der Ladevorgang automatisch. Hast du evtl. die Option "Manuelle Ladefreigabe" gesetzt? Die muss aus sein. Hier mal meine Ladeeinstellungen zum Vergleich:

Ich kann mir aber auch vorstellen, dass das zusätzlich vom Auto abhängt. Möglicherweise tolerieren es nicht alle Autos, länger angesteckt zu sein, ohne dass eine Ladefreigabe kommt. Wir haben einen Fiat 500e, der ist diesbezüglich recht geduldig. Lädt auch brav am nächsten Vormittag, wenn die Sonne rauskommt, auch wenn man ihn nachts ansteckt.

bearbeitet October 24, 2023 at 20:10 von mattsches
Einfluss Auto ergänzt

[deepflyer911]

Hey @mattsches,

 

die Einstellungen sind analog jener bei mir.

Vermute das Problem auch beim Enyaq. Dieser zeigt mir in der Situation in der App, dass der Status unbekannt ist.

Denke der hat einen Zeitablauf.

Da es früher nciht der Fall war, hatte ich zunächst vermutet, dass die Software der Wallbox asich geändert hat. Tatsächlich hat aber auch der Enyaq ein größeres Update erhalten. Ggf ist die Urwsache darin zu finden.

[mattsches]

Vielleicht würde hier eine CP-Trennung ja helfen. Einen Kanal auf dem Quad Relay Bricklet haben wir dafür noch frei.

@ThomKa, du hast doch auch einen Enyaq, oder? Wie ist das bei dir?

[ThomKa]

Hi. Yip, habe noch unseren enyaq und bin mit diesem gerade im Allgäu im Urlaub. Kann erst im November etwas dazu sagen, wenn ich wieder zu Hause bin... 

[mattsches]

Neue Version basierend auf dem offiziellen 2.1.5 Release: https://github.com/mattsches1/esp32-firmware/releases/tag/phase_switcher-2.1.5

[deepflyer911]

@mattsches Aktualisierung erfolgreich. Mal schauen, wenn die SOnne irgendwann scheint und ausreichend Überschuss vorhanden ist, wie es läuft.

Hinsichtlich des "Aufweckens" des Autos, damit nach längerer inaktiver Phase eine Ladung starten kann, @ThomKa konntest du meine Problemstellung nadchvollziehen? @mattsches was wäre nötig, um diese Option zu integrieren?

[mattsches]

@deepflyer911, die CP-Leitung muss statt direkt aufs EVSE-Bricklet auf Kanal 0 des Ind. Quad Relay-Bricklets gelegt und von dort weiter zur bisherigen Klemme. Und dann muss die Software so angepasst werden, dass vor Beginn des tatsächlichen Ladevorgangs das Relais für eine einstellbare Zeit geöffnet wird. Das dürfte keine Raketenwissenschaft sein. Ich scheue nur den Aufwand des Umbaus für mich, da ich die CP-Trennung ja nicht brauche. Aber die Ansteuerung des Relais kann ich ja mal auf den Zettel nehmen. Vorher wäre aber die Rückmeldung von Thomas noch interessant, ob er mit seinem Enyaq dasselbe Problem hat.

[ThomKa]

Moin zusammen. Bin wieder im Lande und spiele die FW heute noch auf... Habe jetzt aktuell den vorletzten Stand am Laufen. 

Zum Verständnis gefragt... Aktuell mehrfach ohne Probleme beim EPEX laden genutzt:

BEV abends angestöpselt - 0W acP - teilweise rote LED am Enyaq - dann nachts/morgens 04:00 - 11kW acP - Ladeende gegen 05:59 --> Enyaq startete jedesmal problemlos und war morgens auf gewünschten SoC geladen. 

Wie ist die angefragte Problematik genau?..? 

Ansonsten würde ich gerne die Implementierung der CP-Trennung unterstützen 👍. Ich würde den Umbau nachvollziehen und dem Leitfaden erweitern. Bräuchte aber ein wenig mehr Erläuterung oder handschriftliche Skizze, da aktuell nicht im Thema. Und auch nur, wenn @mattsches den SW-Stand entsprechend pflegt... 

Was haltet ihr davon? LG, Thomas

bearbeitet November 4, 2023 at 09:39 von ThomKa
Tippfehler bereinigt

[ThomKa]

@deepflyer911 so, FW ist drin, nächster Ladevorgang vermutlich nächste Woche.

Ich habe den Verlauf nochmal gelesen... Ich hatte ähnliches Verhalten auch zwischendurch ab und zu und mit Stecker neu anstöpseln hat es dann funktioniert. Allerdings war das echt nur vereinzelt. Das Bsp. im vorherigen Eintrag nutze ich eigentlich regelmäßig um zum günstigsten Börsen-Preis zu laden. Ich denke die Wartezeit bis zur EPEX-Ladung dürfte noch länger sein, als auf die nächste Einstrahlung zu warten. Mein Enyaq hat übrigens ME3.5 ota erhalten, allerdings weiß ich nicht wann und kann es daher auch nicht mit Symptomen in Verbindung bringen. 

Baust Du für CP nun noch um? Und nimmst Du die FW-Änderungen vor oder @mattsches? Bin nicht sicher, wie jetzt der letzte Status ist?

Ich komme leider die nächsten Tage/Wochen nicht zum Umbau... 

[deepflyer911]

@ThomKa im Grunde passt deine Beschreibung ganz gut. Fahrzeug angestöpselt aber keine Ladung unmittelbar gestartet. Wenn man zu einem späteren Zeitpunkt laden will, startet die Wallbox nicht. Im Status steht dann "warte auf Freigabe". Dabei ist es egal ob der Überschuss genutzt werden soll oder ich eine ad hoc Ladung starten möchte. Nur das Abziehen und neue anstecken des Autos hilft. Beim Ad hoc kommt noch hinzu, dass ich sowohl mit dem Taster als auch in der Software die Ladung starten muss. Da hoffe ich, das der neue  Button zum Sofortladen Abhilfe schafft.

[ThomKa]

Naja, die einzelnen Lade-Modi, wie dann auch "adhoc laden" , habe ich alle in einer VIS zusammengefasst. Von dort aus steuere ich den WARP dann nur noch über die verfügbare LadeLeistung acP.

In der WARP Oberfläche oder am WARP direkt nutze ich gar keine direkte Funktion. 

 

[mattsches]

@deepflyer911, welche Ladestromgrenze blockiert denn in dem Fall? Zu sehen unter Wallbox -> Ladestatus. Und in welchem Schritt steht die Phasenumschaltung dann?

Ich habe noch ein Problem auf der Liste stehen, dass sich nach Drücken des Stopptasters z. B. während eines Schnellladens das Schnellladen nicht sauber wieder starten lässt. Da scheint mir die manuelle Ladefreigabe dann in die Suppe zu spucken, das muss ich aber erst noch genauer eingrenzen. Und mit der von dir beschriebenen Situation scheint es eher nichts zu tun zu haben.

Wegen der CP-Trennung: Ich kann aktuell auch nicht sagen, ob und wann ich zu einer Softwareanpassung komme. Ohne den Umbau selbst durchzuführen wird die möglicherweise doch auch schwierig. Und dafür habe ich gerade nicht die Zeit.

[deepflyer911]

Grüße zusammen,

@mattsches

die neue Version macht Probleme beim ad hoc laden. Bricht die Ladung eigenständig nach kurzer Zeit ab.

Log ist angehängt.

debug-report-warp-SMq-2023-11-05T12-38-37-553.txt

[mattsches]

Hast du dir dein Log mal angeschaut? Darin  wimmelt es nur so vor Fehlern zu Wifi und MQTT. Und um 12:35:03,500 haut es die Kiste zusammen mit einer Exception. Einen Zusammenhang zum ad hoc-Laden kann ich da spontan nicht erkennen. Zumal ich daran nichts geändert habe. Ich tippe eher auf einen Speicherengpass. Ich habe dir mal eine Variante ohne das SOC-Modul gebaut. Schau mal, ob es damit besser geht. Wenn nein, dann habe ich auch keine Idee. Mit Meldungen wie

MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE?

und

2023-11-05 12:34:00,581  JSON doc overflow while converting to string! Doc capacity is zero but needed 6784.

kann ich auch nichts anfangen, die kommen nicht von meinem Code. Und die Codebasis ist das offizielle 2.1.5er Release von TF.

@ThomKa, du nutzt doch auch MQTT. Kommen da auch solche Meldungen im Log vor?

 

warp_firmware_2_1_5_6547f1b1_323bedfa4d03273_merged.bin

bearbeitet November 5, 2023 at 19:56 von mattsches
Firmware angehängt

[ThomKa]

Am 5.11.2023 um 20:55 schrieb mattsches:

Hast du dir dein Log mal angeschaut? Darin  wimmelt es nur so vor Fehlern zu Wifi und MQTT. Und um 12:35:03,500 haut es die Kiste zusammen mit einer Exception. Einen Zusammenhang zum ad hoc-Laden kann ich da spontan nicht erkennen. Zumal ich daran nichts geändert habe. Ich tippe eher auf einen Speicherengpass. Ich habe dir mal eine Variante ohne das SOC-Modul gebaut. Schau mal, ob es damit besser geht. Wenn nein, dann habe ich auch keine Idee. Mit Meldungen wie

MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE?

und

2023-11-05 12:34:00,581  JSON doc overflow while converting to string! Doc capacity is zero but needed 6784.

kann ich auch nichts anfangen, die kommen nicht von meinem Code. Und die Codebasis ist das offizielle 2.1.5er Release von TF.

@ThomKa, du nutzt doch auch MQTT. Kommen da auch solche Meldungen im Log vor?

 

warp_firmware_2_1_5_6547f1b1_323bedfa4d03273_merged.bin 2.09 MB · 0 downloads

@mattsches nee, bin doch schon länger auf http

[deepflyer911]

Am 5.11.2023 um 20:55 schrieb mattsches:

Hast du dir dein Log mal angeschaut? Darin  wimmelt es nur so vor Fehlern zu Wifi und MQTT. Und um 12:35:03,500 haut es die Kiste zusammen mit einer Exception. Einen Zusammenhang zum ad hoc-Laden kann ich da spontan nicht erkennen. Zumal ich daran nichts geändert habe. Ich tippe eher auf einen Speicherengpass. Ich habe dir mal eine Variante ohne das SOC-Modul gebaut. Schau mal, ob es damit besser geht. Wenn nein, dann habe ich auch keine Idee. Mit Meldungen wie

MQTT: Recv buf is 2048 bytes. meter/all_values_update requires 1786. Maybe bump MQTT_RECV_BUFFER_SIZE?

und

2023-11-05 12:34:00,581  JSON doc overflow while converting to string! Doc capacity is zero but needed 6784.

kann ich auch nichts anfangen, die kommen nicht von meinem Code. Und die Codebasis ist das offizielle 2.1.5er Release von TF.

@ThomKa, du nutzt doch auch MQTT. Kommen da auch solche Meldungen im Log vor?

 

warp_firmware_2_1_5_6547f1b1_323bedfa4d03273_merged.bin 2.09 MB · 0 downloads

Die Probleme mit mqtt bestehen seit anbeginn der Zeit. Immerwieder Abbrüche. Keine Ahnung was das soll. Habe nur einen Broker, keine doppelte Belastung oder dergleichen...

[ThomKa]

@deepflyer911 @mattsches sagt mal ihr 2.. Da hatte doch ?..? damals dazu geschrieben, dass die MQTT Umsetzung im iob "ungünstig" sei...

@deepflyer911möchtest du das mit dem "http post" aus dem iob nicht mal ausprobieren und dafür MQTT am WARP deaktivieren? Der Aufwand dürfte für Dich eher gering sein. Ich könnte Dir die blockly Logik geben. Sofern Du es nicht über blockly lösen möchtest, kannst Du sicher das JS Pendant daraus ableiten

[deepflyer911]

@ThomKa sehr gerne schaue ich mit das mit http an. Wollte mich ohnehin damit beschäftigen, da ich deine Lösung für EPEX LAden nutzen möchte

[ThomKa]

@deepflyer911 dann schau einfach mal im IOB Thread: https://forum.iobroker.net/topic/66839/blockly-baustein-für-http-put. Vielleicht möchtest Du die Umsetzung auch direkt in NodeRed vornehmen, wie es am Ende aufgezeigt ist 😉.

Für die zentrale Steuerung hinter obigen Screenshot habe ich mittlerweile ein eigenes Skript erstellt. Alle anderen Ladearten "adhoc", "EPEX" oder "PVÜS" orientieren sich an der Ladefreigabe dieses Skripts. Das ist aber noch nicht in einem Forum beschrieben. Ich stelle Dir was zusammen und Du kannst dann mal schauen, was Du verwenden möchtest, oder was Dir hilft.1

bearbeitet November 6, 2023 at 09:24 von ThomKa
NodeRed ergänzt