Wallbox temporär via API aus Lastmanager-Verbund herauslösen

[Falk]

Guten Morgen allesamt 😇

tl/dr: Ich habe eine etwas seltsame Aufgabenstellung: Ich würde gerne eine WARP3 Pro temporär aus einer Fremdsteuerung (PV-Überschussladen, verwaltet von einer anderen WARP3 Pro) herauslösen, damit ich dort für einen Ladevorgang die vollen 11kW ziehen kann. Aber ich beiße mir an der Deaktivierung der Fremdsteuerung die Zähne aus.

Lange Version: Wir haben in der Firma mehrere WARP3 Pro im Einsatz, die mit PV-Überschuss die Fahrzeuge laden sollen. Das klappt auch wunderbar (so wunderbar, dass ich davon überrascht war, wie gut das geklappt hat: Ein großes Lob!) - jetzt habe ich nur leider zusätzlich den Fall, dass der Geschäftsführer (und manche andere) die Möglichkeit brauchen, diese Regelung außer Kraft zu setzen (wenn bspw. am Nachmittag ein Auswärtstermin ansteht, wofür man den vollen Akku braucht).

Mein erster Versuch war eine Automatisierung (über Tastendruck) - was wunderbar bei unser ersten Versuchs-Wallbox geklappt hat. Nur leider zeigt sich, dass der Knopf jetzt bei der primären Wallbox den Lademodus auch für alle verwalteten auf "schnell" stellt. Und bei den sekundären Boxen überhaupt keinen Effekt zeigt.

Jetzt habe ich mich durch die API gewühlt und getestet, aber ich finde nichts, was die Fremdsteuerung deaktivieren kann.

/evse/external_enabled -d 'false'

der Aufruf lässt es nicht ändern, die Antwort auf die Abfrage ist weiterhin "true" (auch nach Reboot)

/evse/management_enabled -d 'false'

klappt, bewirkt aber nicht das gewünschte

/power_manager/config -d '{"enabled":false,"phase_switching_mode":2,"excess_charging_enable":false,"default_mode":0,"meter_slot_grid_power":1,"meter_slot_battery_power":255,"battery_mode":0,"battery_inverted":false,"battery_deadzone":100,"target_power_from_grid":0,"guaranteed_power":1380,"cloud_filter_mode":2}'

enabled ist später wieder true

/charge_manager/config -d '{"enable_charge_manager":false,"enable_watchdog":false,"default_available_current":125000,"maximum_available_current":125000,"minimum_current_auto":true,"minimum_current":6000,"minimum_current_1p":6000,"minimum_current_vehicle_type":0,"verbose":false,"requested_current_threshold":60,"requested_current_margin":3000,"chargers":[]}'

enable_charge_manager wird false, aber die Fremdsteuerung bleibt trotzdem aktiv

 

Kann mich da irgendjemand in die richtige Richtung weisen? Oder geht das schlicht und einfach nicht? Ich würde gerne vermeiden, die komplette Fremdsteuerung extern zu programmieren...

 

Danke!
Falk

[MatzeTF]

Der Lademodus kann nur auf der Wallbox geändert werden, die das Lastmanagement übernimmt. Von daher sind deine Beobachtungen mit der Automatisierungsregel genau richtig. Da auch nur auf dieser Wallbox Charge Manager und Power Manager aktiv sind (bzw. sein sollten), zeigen die entsprechenden API-Änderungen auf den fremdgesteuerten Wallboxen auch keinen Effekt.

/evse/management_enabled -d 'false'

Das schaltet auf einer fremdgesteuerten Wallbox die Fremdsteuerung aus und sollte somit das Ladelimit aufheben. Charge Manager und Power Manager sollten auf der Wallbox schon aus sein. Da die Wallbox auf dem Lastmanager aber weiterhin als kontrollierte Wallbox eingetragen ist, wird der dann den gesamten restlichen Wallboxverbund wegen Fehlkonfiguration anhalten.

Ansonsten musst du bedenken, dass einzelne Wallboxen aus dem Verbund herauszulösen bedeutet, dass der Gesamtstrom aller Wallboxen nicht mehr korrekt gesteuert wird. Der Gesamtstrom würde auf alle restlichen Wallboxen im Verbund verteilt und die herausgelöste Wallbox käme dann noch dazu. Damit kann man sich leicht die Sicherungen rauswerfen.

Das von dir gewünschte Feature, einzelne Wallboxen von PV auf Schnell stellen zu können, steht auf unserer langen Todo-Liste, aber leider stehen aktuell andere Dinge weiter oben. Ich kann nächste Woche mal einen Kollegen fragen, ob man da was hacken kann, aber aktuell ist da leider nichts so einfach möglich.

[Falk]

Danke!!

Damit kann ich zumindest etwas weiter probieren. Wir haben nicht so viele Wallboxen, dass die Sicherungen tatsächlich ein Problem wären, immer 2 auf 16A-gedippte Boxen haben eine 32A Sicherung (und natürlich eigene FI) und die Zuleitung davor ist ausreichend groß, sodass das auslösen von 1-2 Wallboxen tatsächlich kein Problem darstellt. Und der verbliebene PV-Strom ist einfach niedriger, wie wenn andere ungeregelte Geräte im Haushalt an wären.

Zitat

Da die Wallbox auf dem Lastmanager aber weiterhin als kontrollierte Wallbox eingetragen ist, wird der dann den gesamten restlichen Wallboxverbund wegen Fehlkonfiguration anhalten.

steht dann wirklich alles? Oder "humpelt" er dann ohne die weiter? Ansonsten müsste ich ja eigentlich "nur" das "chargers"-Array von 

/charge_manager/config

entsprechend manipulieren und dort die ausgelöste Wallbox entfernen.

Oder sollte ich lieber evcc oder etwas ähnliches oben drüber setzen? Müsste auch funktionieren, oder?

[MatzeTF]

On 7/10/2025 at 12:36 PM, Falk said:

steht dann wirklich alles? Oder "humpelt" er dann ohne die weiter? Ansonsten müsste ich ja eigentlich "nur" das "chargers"-Array von 

/charge_manager/config

entsprechend manipulieren und dort die ausgelöste Wallbox entfernen.

Dann steht wirklich alles, da das eine offensichtliche Fehlkonfiguration ist. Wenn eine Wallbox nicht fremdgesteuert sein soll, muss sie bei der Lastmanager-Wallbox entfernt werden, und zwar mit genau der API.

Was evcc für sowas bietet, weiß ich nicht.

Ansonsten kommt das Feature bei uns; ich weiß nur noch nicht, wann das sein wird.

Spontane Idee: Vielleicht wäre es sinnvoll, ein oder zwei Wallboxen permanent eigenständig zu betreiben? Dann kann man je nach Ladebedürfnis die passende Wallbox aussuchen.

[Falk]

Ich habe ein Problem mit dem Aufruf für /charge_manager/config - es gibt eine Deserializer-Fehlermeldung (payload could not be parsed) mit folgendem Aufruf (Versuch, das Array von 2 auf 1 zu verkleinern):

curl http://$HOST_MASTER/charge_manager/config -d '{"enable_charge_manager":true,"enable_watchdog":false,"default_available_current":125000,"maximum_available_current":125000,"minimum_current_auto":true,"minimum_current":6000,"minimum_current_1p":6000,"minimum_current_vehicle_type":0,"verbose":true,"requested_current_threshold":60,"requested_current_margin":3000,"chargers":[{"host":"127.0.0.1","name":"warp3-xxxx","rot":1}]}'

und auch 

curl http://$HOST_MASTER/charge_manager/config -d '{"enable_charge_manager":true,"enable_watchdog":false,"default_available_current":125000,"maximum_available_current":125000,"minimum_current_auto":true,"minimum_current":6000,"minimum_current_1p":6000,"minimum_current_vehicle_type":0,"verbose":true,"requested_current_threshold":60,"requested_current_margin":3000,"chargers":[{"host":"127.0.0.1","name":"warp3-xxxx","rot":1},{"host":"$HOST_SLAVE","name":"warp3-yyyy","rot":3}]}'

(zum Testen, es wurde genau die Antwort verwendet, die auf die Anfrage /charge_manager/config zurückgegeben wurde, also keine Änderung - klappt aber auch nicht, wenn ich die slave-box über das Webinterface lösche und dann den Befehl sende)

Das ganze über MQTTX direkt via MQTT zu senden ändert auch nichts.

Im Protokoll stehen leider auch keine weiteren Infos, wo genau er sich beim deserialize ne blutige Nase geholt hat. Kann ich da irgendwo noch mehr Infos anschalten?

 

(Der Teil mit /evse/management_enabled -d 'false' funktioniert, aber wie du schon geschrieben hast, dann stehen die anderen Wallboxen)

 

Für die Umschaltung von 1 auf 3 Phasen habe ich eine MQTT-Automatisierung konfiguriert, die mit /automation_trigger/phase entweder 1 oder 3 als Nachricht erwartet und umschaltet. Das Feature ist echt cool! Wenn man jetzt noch mehrere Aktionen an eine Automatisierung hängen könnte... 😇

 

Zitat

Spontane Idee: Vielleicht wäre es sinnvoll, ein oder zwei Wallboxen permanent eigenständig zu betreiben? Dann kann man je nach Ladebedürfnis die passende Wallbox aussuchen.

Dafür haben wir leider nicht genug Platz für komplette extra Wallboxen. Und auch einfach 1-2 komplett aus dem Verbund auszulösen funktioniert nicht, weil der Janitza Stromzähler nicht genug Modbus-TCP-Sockets anbietet um mehrere "Master" laufen zu haben.

bearbeitet July 11, 2025 at 06:04 von Falk

[MatzeTF]

On 7/11/2025 at 7:40 AM, Falk said:

Ich habe ein Problem mit dem Aufruf für /charge_manager/config - es gibt eine Deserializer-Fehlermeldung (payload could not be parsed) mit folgendem Aufruf (Versuch, das Array von 2 auf 1 zu verkleinern):

curl http://$HOST_MASTER/charge_manager/config -d '{"enable_charge_manager":true,"enable_watchdog":false,"default_available_current":125000,"maximum_available_current":125000,"minimum_current_auto":true,"minimum_current":6000,"minimum_current_1p":6000,"minimum_current_vehicle_type":0,"verbose":true,"requested_current_threshold":60,"requested_current_margin":3000,"chargers":[{"host":"127.0.0.1","name":"warp3-xxxx","rot":1}]}'

und auch 

curl http://$HOST_MASTER/charge_manager/config -d '{"enable_charge_manager":true,"enable_watchdog":false,"default_available_current":125000,"maximum_available_current":125000,"minimum_current_auto":true,"minimum_current":6000,"minimum_current_1p":6000,"minimum_current_vehicle_type":0,"verbose":true,"requested_current_threshold":60,"requested_current_margin":3000,"chargers":[{"host":"127.0.0.1","name":"warp3-xxxx","rot":1},{"host":"$HOST_SLAVE","name":"warp3-yyyy","rot":3}]}'

(zum Testen, es wurde genau die Antwort verwendet, die auf die Anfrage /charge_manager/config zurückgegeben wurde, also keine Änderung - klappt aber auch nicht, wenn ich die slave-box über das Webinterface lösche und dann den Befehl sende)

Kann ich nicht reproduzieren. Beide curl-Aufrufe funktionieren bei mir einfach, wenn ich $HOST_MASTER durch meine Test-Wallbox ersetze.

Benutzt du richtiges curl oder den Pfusch von der Windows PowerShell?

Du kannst testweise mal versuchen, die API über die Recovery-Seite der Wallbox aufzurufen:

http://$HOST_MASTER/recovery

Da gibt es ein Beispiel, wie der API-Aufruf formatiert werden muss.

Wenn es über die Recovery-Seite funktioniert, ist es ein curl/Shell-Problem.

[Falk]

Zitat

Wenn es über die Recovery-Seite funktioniert, ist es ein curl/Shell-Problem.

  🤬🤬🤬🤬🤬 - ja... Windows-Rotz, über Recovery geht es.

Und die MQTT-Doku habe ich wohl auch nicht ganz richtig gelesen, habe nicht realisiert (obwohl eigentlich logisch), dass update und lesen unterschiedliche Topics sein müssen

/charge_manager/config_update

wäre gut gewesen, und nicht nur

/charge_manager/config

😵😵Vielen Dank für die Hilfe! Das Ganze gieße ich jetzt in einen NodeRED Flow

Doku für alle, die nach mir kommen

Zitat

 

ich verwende als Trigger eine Automatisierung auf den Button jeder Wallbox, der eine MQTT-Nachricht (unterschiedlich je Wallbox) verschickt und zum Deaktivieren einen Trigger (zum Versand einer anderen MQTT-Nachricht) auf Automatisierung "Ladestatus wechsel" von "beliebig" auf "getrennt":

1: Auslösen des Slaves aus der Master-Regelung durch entfernen des Eintrags aus "chargers" im Topic $PREFIX_MASTER/charge_manager/config_update 
2: $PREFIX_SLAVE/evse/management_enabled_update mit Inhalt "false"

zum wieder einschalten, das ganze andersherum:

1: $PREFIX_SLAVE/evse/management_enabled_update mit Inhalt "true"
2: Einfügen des Slaves in die Master-Regelung durch einfügen des Eintrags in "chargers" im Topic $PREFIX_MASTER/charge_manager/config_update 

 

Leider lässt sich das scheinbar nicht so direkt innerhalb der Wallbox erledigen, weil zwei getrennte Nachrichten erforderlich sind (und Wissen über die konfigurierten Slave-Boxen im Master nötig ist, das extern (in meinen Fall NodeRED) vorgehalten werden muss).

Ich würde (wenn es mein Projekt wäre) vermutlich als "quick und Semi-dirty" einen/zwei API-Punkt(e) definieren, der das Löschen (z.B. mittels IP als Key) und Hinzufügen einer kontrolliertenWallbox im Master erlaubt (existiert aufgrund der Visualisierung potenziell bereits?) und einen, der die Slave-Box anweist, sich beim Master zu registrieren/löschen (mit einem Objekt mit zwei Keys: "Master-Topic" und Chargers-Array-Eintrag ({"host":"$HOST_SLAVE","name":"warp3-yyyy","rot":3}) - das könnte dann die nötigen zwei calls machen (bzw nur den einen zum Master, je nachdem wie es programmiert ist)