Falk

🤬🤬🤬🤬🤬 - 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 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)

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... 😇 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.

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. 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?

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