WARP1 Smart - PV-Überschussladen nicht möglich? (Lastmanagement blockiert)

[alestrix]

Moin!

Vorgeplänkel/Was bisher geschah
Da ich endlich wieder ein vernünftiges Leasingangebot gefunden habe, steht ab morgen wieder eine Zoe vor meiner Haustür. Darum habe ich heute meine liebe WARP Smart der ersten Stunde wieder in Betrieb genommen und die aktuellste Firmware aufgespielt. Erst mal muss ich sagen wie begeistert ich bin von den zusätzlichen Funktionen, die auch die gute alte WARP1 dazu bekommen hat. Insbesondere die Automatisierungen (habe das NFC Bricklet eingebaut, da ist Automatisierung ideal) und die Anbindung externer Datenquellen ist ein gutes Feature - die Einbindung meines Tasmota Stromzählers als API-Stromzähler in der WARP war blitzschnell erledigt.

Die Schwierigkeit
Da die WARP ja nun die Werte von Netzbezug/Netzeinspeisung zur Verfügung hat, war der logische nächste Schritt, auch das PV-Überschussladen direkt in der WARP (habe früher dazu evcc genutzt) zu konfigurieren. Dazu muss man zwangsweise das Lastmanagement aktivieren - interessanterweise nicht unter "Lastmanagement", sondern unter "Wallboxen" zu finden 🤔. Das hat aber zur Folge, dass die Ladung dauerhaft blockiert ist - im Ladestatus steht nun hinter "Lastmanagement" immer "Blockiert".

Ursache?
Ich kann mir vorstellen, dass es daran liegt, dass die WARP1 Smart keinen internen Stromzähler hat, die Lastmanagementlogik aber zwingend einen solchen verlangt. Das macht ja auch beim "echten" Lastmanagement Sinn, wenn das LM aber nur deswegen eingeschaltet wird, weil PV-Überschussladen genutzt werden soll, dann ist eine solche stringente Regel eigentlich nicht mehr notwendig.

Was tun?
Ich könnte mich jetzt nach zwei Jahren Pause wieder versuchen in evcc einzudenken, eine Lösung mit möglichst wenigen externen Abhängigkeiten, die also nur die WARP und den Stromzähler involviert, ist aber eigentlich immer zu bevorzugen. Daher meine Bitte: Kann die stringente Anforderung, für PV-Überschussladen einen eingebauten Zähler zu benötigen, fallen gelassen bzw. deaktivierbar gehalten werden?

Alternativen/Feedback
Die Möglichkeit, per API Daten an die WARP zu pushen, ist schon ein guter Anfang, aber eine Kombination aus HTTP GET mit json query als "pull" Lösung würde weitere Möglichkeiten bieten - z.B. das Auslesen eines bereits vorhandenen externen Wallbox-Stromzählers (der Name "Stromzähler" im Menü unter "Energiemanagement" ist übrigens nicht eindeutig - es könnte der am Netzübergabepunkt sein, einer vor der Hausbatterie, oder ein Stromzähler direkt vor der Wallbox). Auch wäre eine (ausgehende) API zur Anbindung eines externen Schützes zur 1p3p Umschaltung ein Use Case, den sicherlich nicht nur ich hätte.

Danke & viele Grüße
 Alex

 

PS: Noch etwas Seltsames: Wenn ich in der Benutzerverwaltung "Verlangt eine Freigabe des Lade­vorgangs durch einen Benutzer zum Laden (z.B. per NFC-Tag)" aktiviere und dann ein NFC-Tag an den Leser heranhalte (bzw. injecte), das einem Nutzer zugewiesen ist, dann steht im Ladestatus weiterhin "Blockiert" bei "Benutzer/NFC". Wo ist der Denkfehler?

bearbeitet July 18, 2024 at 23:14 von alestrix

[MatzeTF]

PV-Überschussladen benötigt gar keinen eingebauten Zähler. Eine WARP1 Smart ist völlig ausreichend.

Bitte schließe bei ausreichend PV-Einspeisung dein Auto an und versuche, den Ladevorgang per NFC freizugeben. Wenn das Auto eigentlich laden sollte, einen Debug-Report runterladen und hier anhängen, damit wir uns deine Einstellungen und ggf. Fehlermeldungen ansehen können.

Hast du eine Zoe 1 oder 2? Bei einer Zoe 2 musst du beim Lastmanagement den Zoe-Modus auswählen. „Ausreichend PV-Einspeisung“ bedeutet dann 6348 W Überschuss, da eine Zoe 2 dreiphasig erst ab 9,2 A sinnvoll lädt.

Zum Feedback:

Irgendeine Art von „pull“ für Zählerwerte haben wir auch schon in Erwägung gezogen, aber leider gibt es da zu viele mögliche Datenformate. Hat der Endpunkt einfach nur eine Zahl als String? JSON? Einfaches Array von Werten? Assoziatives Array? Was bedeuten die Werte? Ampere oder Milliampere? Deswegen gibt es nur die Push-API.

Im nächsten Firmware-Release wird an der Stromzähler-Einstellung stehen, dass es sich um den Hausanschluss handelt. Ein externes Schütz für eine 1p/3p-Umschaltung macht an einer WARP1 keinen Sinn, da sie nicht über die nötige Hardware verfügt, um einem angeschlossenen Fahrzeug sicher eine Phasenumschaltung zu signalisieren. Eine Phasenumschaltung ohne entsprechende Vorkehrungen führt gerade bei einer Zoe zu einer sehr knusprigen Ladeelektronik. 😉

[alestrix]

Am 19.7.2024 um 02:27 schrieb MatzeTF:

Bitte schließe bei ausreichend PV-Einspeisung dein Auto an und versuche, den Ladevorgang per NFC freizugeben. Wenn das Auto eigentlich laden sollte, einen Debug-Report runterladen und hier anhängen, damit wir uns deine Einstellungen und ggf. Fehlermeldungen ansehen können.

Hi Matze,

vielen Dank für die Rückmeldung zu so später Stunde! 😃 Den Test werde ich machen, sobald das Auto da ist (morgen Abend) und dann wieder die Sonne scheint (Samstag ☀️).
Mein Verständnis ist aber, dass bereit jetzt

• ohne angeschlossenes Fahrzeug
• im Lademodus "Schnell"

das Lastmanagement nicht auf "Blockiert" stehen dürfte.

Als Trockenübung habe ich jetzt mal ohne Auto per inject_tag zwischen zwei NFC Tags hin- und her geschaltet, an der Blockierung bei "Lastmanagement" und "Benutzer/NFC" hat das aber nichts geändert.

                  0,057 |                  |     **** TINKERFORGE WARP CHARGER V2.4.0+665589EC ****
                  0,058 |                  |          325K RAM SYSTEM   298500 HEAP BYTES FREE
                  0,068 |                  | READY.
                  0,069 | main             | Last reset reason was: Software reset via esp_restart.
                  0,286 | tools            | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used
                  0,577 | api              | WARP Charger config version: 2.2.0 (warp)
                  0,577 | esp32_brick      | ESP32 Brick UID: TH5
                  1,029 | evse_common      | Continuing to use sum of imported and exported energy for charge tracker.
                  1,030 | evse_common      | Remove tracked charges to switch to imported energy.
                  1,265 | ntp              | Set timezone to Europe/Berlin
                  1,731 | meters           | Meter in slot 0 declared 1 values.
                  1,998 | charge_tracker   | Found 1 record: first is 1, last is 1
                  2,050 | charge_tracker   | Last charge record size is 3168 (3168, 0)
                  2,427 | power_manager    | Raising guaranteed power to 1840 based on minimum charge current set in charge manager.
                  2,566 | device_module    | NFC Bricklet found. Enabling NFC support.
                  2,998 | network          | mDNS responder started
                  3,373 | wifi             | Connecting to rtlwrmft-IoT
                  3,380 | charge_manager   | Available phases: 1
                  3,382 | device_name      | This is warp-TH5 (warp-TH5), a WARP Charger Pro 22kW +NFC
                  3,398 | power_manager    | Pausing energy updates because power value is not available yet.
                  6,014 | wifi             | Connected to rtlwrmft-IoT, BSSID 82:8A:20:8A:2E:F6
                  6,912 | charge_manager   | Seen all chargers.
                  7,541 | wifi             | Got IP address: 192.168.8.216/24. Own MAC address: 10:52:1C:89:56:AC
                  9,424 | power_manager    | Resuming energy updates because power value is now available.
                  9,425 | power_manager    | Seen all chargers.
                  9,436 | power_manager    | wants_on decision changed to 1
                  9,436 | power_manager    | Immediate switch-on during start-up period, power available: 7360, current available: 32000
2024-07-19 02:36:01,948 | ntp              | NTP synchronized at 16,423
2024-07-19 02:36:08,912 | mqtt             | Connected to broker.
2024-07-19 02:36:16,361 | automation       | Running rule #2
2024-07-19 02:36:16,362 | automation       | Running rule #3
2024-07-19 02:36:16,363 | power_manager    | Switched mode 0->0
2024-07-19 02:36:42,364 | automation       | Running rule #1
2024-07-19 02:36:42,365 | power_manager    | Switched mode 0->2
2024-07-19 02:36:42,479 | power_manager    | wants_on decision changed to 0
2024-07-19 02:36:42,479 | power_manager    | Immediate switch-off after changing modes, power available: -382, current available: 0
2024-07-19 02:36:48,169 | automation       | Running rule #2
2024-07-19 02:36:48,171 | automation       | Running rule #3
2024-07-19 02:36:48,172 | power_manager    | Switched mode 2->0
2024-07-19 02:36:48,327 | power_manager    | wants_on decision changed to 1
2024-07-19 02:36:48,327 | power_manager    | Immediate switch-on after changing modes, power available: 7360, current available: 32000

Bei den Regeln handelte es sich um das Setzen des PV Modus (#1) bzw Schnell Modus (#3) und das Setzen des Ladestroms (#2), jeweils getriggert durch das NFC-Tag. Wenn ich die NFC-Regeln bei der Automatisierung rauslösche, findet sich keine Info über das inject-Event im Ereignislog (hört mit der mqtt connect Meldung auf).

Komplettes Log mit coredump liefere ich dann mit, wenn ich den Test mal mit Auto mache - kann den Anhang dann eigentlich jeder runterladen? Wie ich gesehen habe, ist das WiFi Passwort im coredump enthalten. Und warum steht da eigentlich beim device_name "WARP Charger Pro"? Ich habe ganz sicher keinen in der WB eingebauten Stromzähler.

Viele Grüße
 Alex

PS: Wenn ich "Verlangt eine Freigabe des Lade­vorgangs durch einen Benutzer zum Laden (z.B. per NFC-Tag)" ausschalte und verschiedene Tags verschiedenen Usern mit unterschiedlichen Strombegrenzungen zuweise und dann die verschiedenen Tags injecte, ändert sich kein einziger der 15 Laststromgrenzen-Werten, die Strombegrenzungen bei den Usern haben also keinerlei Auswirkung.

PPS: Wie aufwendig wäre es, die CP Trennung bei der WARP1 nachzurüsten?

 

bearbeitet July 19, 2024 at 01:35 von alestrix

[rtrbt]

On 7/19/2024 at 3:09 AM, alestrix said:

Wie ich gesehen habe, ist das WiFi Passwort im coredump enthalten

Du meinst im Debug-Report? Das WiFi-Passwort (wie auch alle anderen Passwörter usw.) sollte durch null ersetzt sein. Wenn das nicht der Fall ist, sag bitte auf jeden Fall Bescheid, das müssten wir sofort fixen.

On 7/19/2024 at 3:09 AM, alestrix said:

Und warum steht da eigentlich beim device_name "WARP Charger Pro"?

Das liegt vermutlich daran, dass du einen Stromzähler mit der ID 0 (in der Stromzähler-Konfiguration im  Webinterface heißt das generisch "Nummer") hinzugefügt hast. Der wird von der Wallbox als der "interne" Zähler betrachtet und z.B. für den Ladetracker verwendet. Die Wallbox weiß von sich aus nicht, ob sie eine Smart oder Pro ist, sondern wenn ein Zähler mit ID 0 auftaucht, dann betrachtet sie sich selbst als Pro.

Damit der Ladetracker jetzt nicht die Daten deines Hausanschlusses aufzeichnet kannst du entweder die Nummer des Zählers auf 1 ändern, oder von Hand https://docs.warp-charger.com/docs/mqtt_http/api_reference/evse#evse_meter_config_warp1 auf 1 schreiben. Dafür gibt es leider noch keine UI. In beiden Fällen solltest du dann noch unter Wallbox -> Einstellungen die Zählerüberwachung deaktivieren, die dürfte sich scharfgeschaltet haben, wenn die Box sich einmal als Pro erkennt.

On 7/19/2024 at 3:09 AM, alestrix said:

Wenn ich "Verlangt eine Freigabe des Lade­vorgangs durch einen Benutzer zum Laden (z.B. per NFC-Tag)" ausschalte und verschiedene Tags verschiedenen Usern mit unterschiedlichen Strombegrenzungen zuweise und dann die verschiedenen Tags injecte, ändert sich kein einziger der 15 Laststromgrenzen-Werten, die Strombegrenzungen bei den Usern haben also keinerlei Auswirkung.

Das ergibt Sinn, du hast das Feature damit ja ausgeschaltet. Wenn du keine NFC-Freigabe willst, aber trotzdem per NFC den Ladestrom kontrollieren, dann musst du das per Automatisierungs-Regel erschlagen.

On 7/19/2024 at 3:09 AM, alestrix said:

Wie aufwendig wäre es, die CP Trennung bei der WARP1 nachzurüsten?

Das ist möglich, aber involviert etwas Bastelei. @poohnet hat einen Fork der WARP-Firmware mit CP-Trennung für WARP1 und die entsprechende Hardware-Modifikation hier:

hier: https://github.com/poohnet/esp32-firmware

und hier:

Die letzte Version des Forks  ist aber 2.2.1, d.h. da fehlen dir dann die PV-Überschuss-Features

[poohnet]

Moin @alestrix,

ja, ich habe meine WARP1 tatsächlich bereits mehrfach umgebaut und diverse Erweiterungen vorgenommen:

• ESP32-Bricklet durch ESP32-Ethernet-Bricklet ersetzt
• CP-Trennung für die Phasenumschaltung über WARP Energy Manager nachgerüstet (den zugehörigen Thread hat @rtrbt ja schon verlinkt)
• interne Phasenumschaltung der WARP3 nachgebaut
• sowie weitere softwareseitige Anpassungen (Ladeprotokoll, dynamischer Boost, ...)

 

Mit etwas technischem Sachverstand sind solche Umbauten mehr oder weniger problemlos möglich, wie zahlreiche andere Projekte hier im Forum ja auch zeigen. Allerdings sollte man schon wissen, was man tut, um nicht versehentlich die Ladeelektronik des Autos (oder schlimmer noch, sich selbst) zu grillen.

 

On 7/19/2024 at 9:46 AM, rtrbt said:

Die letzte Version des Forks  ist aber 2.2.1, d.h. da fehlen dir dann die PV-Überschuss-Features

Zumindest die letzte veröffentliche Version. Intern aktualisiere ich meinen Fork halbwegs regelmäßig mit dem Tinkerforge-Repo und seit Anfang der Woche läuft bei mir die 2.4.0 🙃

Sofern gewünscht kann ich gerne weitere Details nennen...

Gruß Thomas

[MatzeTF]

On 7/19/2024 at 3:09 AM, alestrix said:

Mein Verständnis ist aber, dass bereit jetzt

• ohne angeschlossenes Fahrzeug
• im Lademodus "Schnell"

das Lastmanagement nicht auf "Blockiert" stehen dürfte.

Als Trockenübung habe ich jetzt mal ohne Auto per inject_tag zwischen zwei NFC Tags hin- und her geschaltet, an der Blockierung bei "Lastmanagement" und "Benutzer/NFC" hat das aber nichts geändert.

Okay, ich hatte nicht realisiert, dass du die ganzen Tests ohne angeschlossenes Fahrzeug durchgeführt hast. Deine Wallbox verhält sich genau so, wie sie sich ohne Fahrzeug verhalten soll. Das Lastmanagement weist einer Wallbox nur dann Strom zu, wenn auch ein Fahrzeug angeschlossen ist. Kein Auto, keine Freigabe, auch nicht im „Schnell“-Modus. Gleiches gilt auch für NFC: Du kannst per NFC nur dann einen Ladevorgang freigeben, wenn ein Fahrzeug angeschlossen ist. Erst NFC-Tag dranhalten und dann einstecken geht nicht.

[alestrix]

Hallo,

erst mal sorry, dass ich so lange nicht geantwortet habe wo Ihr mir so viel Input gegeben habt. Im August sollte ich jetzt wieder etwas mehr Zeit für das Hobby haben...

  

Am 19.7.2024 um 09:46 schrieb rtrbt:

Du meinst im Debug-Report? Das WiFi-Passwort (wie auch alle anderen Passwörter usw.) sollte durch null ersetzt sein. Wenn das nicht der Fall ist, sag bitte auf jeden Fall Bescheid, das müssten wir sofort fixen.

Ja. Es war im coredump enthalten, der am Ende des debug-logs als base64 encodeter String enthalten war. Ich habe mir mal ein paar Debug logs hier im Forum angesehen aber nirgends war ein coredump angehängt. K.A. warum der bei mir dabei war.

Auf den Dump von damals habe ich gerade keinen Zugriff, aber wenn ich mir jetzt noch mal einen frischen ziehe, dann sehe ich das Passwort ab 0x5438. Also als One-Liner:

sed -n '/base64,/,${s/.*base64,//;p}' debug-report-warp-TH5-2024-08-03T17-49-56-460.txt | base64 -d | xxd -u -s 0x5438 -l 32

 

Was die CP Trennung von @poohnet angeht, so muss ich mir das entsprechende GitHub Projekt noch etwas genauer anschauen, schrecke aber ein wenig davor zurück, da ich noch nie SMD Bauteile verlötet habe. Außerdem weiß ich noch nicht, wie ich meinen vorhandenen externen 1p/3p Schütz (per MQTT und HTTP ansteuerbar) in das Ganze einbinden würde.

Wahrscheinlich werde ich das vorerst mal nur in einer Minimalversion "für Arme" umsetzen und per NFC-Regel ein externes Skript triggern, das den Schütz umschaltet (nach einer Prüfung, dass das Auto auch getrennt ist). Dann kann ich zumindest vor dem Ladevorgang entscheiden, ob ich 1- oder 3-phasig laden möchte.
Frage an @rtrbt/@MatzeTF: Genügt es, nach dem Schalten einmal per charge_manager/available_phases die Phasenzahl zu setzen, damit die Berechnung des Ladestroms für das PV-Überschussladen passt? Wenn man die Phasenzahl an der GUI ändert, wird man ja immer aufgefordert, die Box neu zu starten. Oder wird damit die Einstellung ständig im Flash geändert was schlecht für die Langlebigkeit ist? Was wäre dann ein geeigneterer API Aufruf?

 

Am 19.7.2024 um 11:25 schrieb MatzeTF:

Okay, ich hatte nicht realisiert, dass du die ganzen Tests ohne angeschlossenes Fahrzeug durchgeführt hast. Deine Wallbox verhält sich genau so, wie sie sich ohne Fahrzeug verhalten soll. Das Lastmanagement weist einer Wallbox nur dann Strom zu, wenn auch ein Fahrzeug angeschlossen ist. Kein Auto, keine Freigabe, auch nicht im „Schnell“-Modus. Gleiches gilt auch für NFC: Du kannst per NFC nur dann einen Ladevorgang freigeben, wenn ein Fahrzeug angeschlossen ist. Erst NFC-Tag dranhalten und dann einstecken geht nicht.

Ah, wenn man's weiß, dann ist es nachvollziehbar 😉. Warum denn dieser (gefühlte) Designbruch? Für den Ladevorgang begrenzende oder verhindernde Umstände gibt es ja jeweils einen eigenen evse-"Slot". Was ist denn der Hintergrund, den Check, ob das Auto ladebereit angeschlossen ist, in zwei vorhandenen Slots mit unterzubringen statt einen eigenen dafür zu spendieren?

Viele Grüße
 Alex

 

bearbeitet August 3, 2024 at 16:30 von alestrix

[poohnet]

Moin Alex,

On 8/3/2024 at 6:24 PM, alestrix said:

Was die CP Trennung von @poohnet angeht, so muss ich mir das entsprechende GitHub Projekt noch etwas genauer anschauen, schrecke aber ein wenig davor zurück, da ich noch nie SMD Bauteile verlötet habe.

Das habe ich auch nicht selbst gemacht, d. h. ich habe die Platine von JLCPCB fertigen lassen. Da man immer mindestens drei bestellen muss, habe ich noch eine übrig, die ich dir bei Bedarf gerne zum Selbstkostenpreis zuschicken kann…

Gruß Thomas

[alestrix]

Am 19.7.2024 um 09:46 schrieb rtrbt:

Damit der Ladetracker jetzt nicht die Daten deines Hausanschlusses aufzeichnet kannst du entweder die Nummer des Zählers auf 1 ändern, oder von Hand https://docs.warp-charger.com/docs/mqtt_http/api_reference/evse#evse_meter_config_warp1 auf 1 schreiben.

Danke noch für die Info, habe dem API-Zähler die ID 1 gegeben - jetzt habe ich auch verstanden, was mit "Stromzähler für Berechnungen im Zusammenhang mit Ladevorgängen" gemeint ist ;-) (habe mal einen Formulierungsvorschlag per PR gesendet). D.h., wenn ich noch einen weiteren API Zähler "0" anlege und dem regelmäßig die Werte vom Wallbox-Stromzähler übermittle, dann funktionieren auch so Dinge wie Energielimit?

 

EDIT: 

Am 19.7.2024 um 09:46 schrieb rtrbt:

In beiden Fällen solltest du dann noch unter Wallbox -> Einstellungen die Zählerüberwachung deaktivieren, die dürfte sich scharfgeschaltet haben, wenn die Box sich einmal als Pro erkennt.

Überwacht die Zählerüberwachung den Wallbox- oder den Netzanschluss-Zähler? Falls letzteres, sollte er doch eigentlich aktiv bleiben können, da Tasmota ja alle paar Sekunden die Werte vom Hausanschluss meldet. Und falls der Wert ausbleibt, ist ein Runterschrauben auf einen konservativen Wert ja nichts Verkehrtes, oder?

Ah, nein, hab's mit dem Watchdog verwechselt. Ich nehme an, der Watchdog bezieht sich auf den Netzanschlusszähler, die Zählerüberwachung auf den Wallboxzähler?

/EDIT

 

Am 5.8.2024 um 07:16 schrieb poohnet:

Das habe ich auch nicht selbst gemacht, d. h. ich habe die Platine von JLCPCB fertigen lassen. Da man immer mindestens drei bestellen muss, habe ich noch eine übrig, die ich dir bei Bedarf gerne zum Selbstkostenpreis zuschicken kann…

Vielen Dank für das Angebot! Leider bin ich mir unsicher, ob es überhaupt möglich ist, das CP-Trenn-Bricklet und den externem 1p3p Schütz zum Zusammenspiel zu bewegen. Bisher sehe ich da noch keine Möglichkeit, da die Box ja nicht weiß, dass/wie sie den Schütz per API steuern kann.
 

VG
Alex

bearbeitet August 7, 2024 at 17:42 von alestrix

[rtrbt]

On 8/7/2024 at 7:22 PM, alestrix said:

D.h., wenn ich noch einen weiteren API Zähler "0" anlege und dem regelmäßig die Werte vom Wallbox-Stromzähler übermittle, dann funktionieren auch so Dinge wie Energielimit?

Genau.

On 8/7/2024 at 7:22 PM, alestrix said:

Ah, nein, hab's mit dem Watchdog verwechselt. Ich nehme an, der Watchdog bezieht sich auf den Netzanschlusszähler, die Zählerüberwachung auf den Wallboxzähler?

Fast. Der Watchdog ist nur relevant, wenn du direkt auf charge_manager/available_current_update schreibst. Also "statisches" Lastmanagement machst, aber selbst den verfügbaren Strom per API vorgibst und dann sichergehen willst, dass wenn das Programm crasht, dass die API befüllt, nicht der letzte verfügbare Stromwert weiter verwendet wird.

Wenn du einen API-Zähler für den PV-Überschuss verwendest dun dann dein Programm crasht, wird im Moment der letzte Wert weiterverwendet. Auf der TODO-Liste steht, damit auch umzugehen, das wird im Zuge des dynamischen Lastmanagements kommen.