rtrbt

Du kannst (wenn du das nicht in der brickd.conf umkonfiguriert hast) von anderen Rechnern aus auf einen Brick Daemon zugreifen. D.h.

56 minutes ago, tfRookie said:

Gibt es irgendwie eine Moeglichkeit, alle Master Bricks mit USB an einen anderen Rechner anzuschliessen den unter Nutzung der aktuellen Software als Server zu verwenden?

funktioniert einfach, wenn du in deiner Software "localhost" auf die IP oder den Hostnamen des anderen Rechners änderst, an dem alle Bricks angeschlossen sind. (auf dem anderen Rechner muss natürlich auch Brick Daemon installiert sein)

Alternativ kannst du WiFi- oder Ethernet-Extensions benutzen oder alle Stapel mit RS485-Extensions zusammenschalten.

13 hours ago, AndyHandy said:

Laut RFC darf die Warp2 Charger Pro nicht Content-Length als Server senden.

Hm da habe ich gleich was gelernt, danke :) https://httpwg.org/specs/rfc7230.html#header.content-length sagt

Quote

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

Der Ladetracker benutzt Transfer-Encoding: Chunked damit der ESP nicht das ganze Ladelog gleichzeitig im RAM halten muss. Die Content-Length wird gesetzt, für den Fall dass das Log groß ist und die Netzwerk-Verbindung langsam. Dann kann der Download ein paar Sekunden dauern. Zumindest die Browser verstehen das und man bekommt eine sinnvolle Fortschrittsanzeige.

Da jetzt aber der Normalfall ist, dass man das Ladelog über das Webinterface runterlädt, dass die Binärdatei in Javascript noch in eine CSV umbaut, sieht man sowieso die Browser-Fortschrittsanzeige nicht. D.h. ich nehme das Setzen der Content-Length einfach raus, dann müsste es in Node-Red mit der nächsten Firmware auch funktionieren: https://github.com/Tinkerforge/esp32-firmware/commit/4b21a005257d08c44ac553315b744aff5da9532f

Zumindest den Teil dass du per MQTT die Stromzählerwerte setzen kannst haben wir schon: https://www.warp-charger.com/api.html?v=2#meter_state_update (und die Funktionen danach)

Den Software-Support für den Umbau auf drei Schütze, die dann nicht direkt vom EVSE gesteuert werden, werden wir nicht übernehmen.

@mattsches weil ich gerade nochmal über den Code gescrollt bin: Du solltest hier: sicherheitshalber https://www.tinkerforge.com/en/doc/Software/Bricklets/IndustrialQuadRelayV2_Bricklet_uC.html#c.tf_industrial_quad_relay_v2_set_monoflop

statt set_value verwenden, zumindest für die Channels bei denen du das Schütz durchschaltest. Das hat den Vorteil, dass falls der ESP aus irgendeinem Grund abschmiert oder hängt, das Quad Relay abschaltet, wenn der Monoflop abgelaufen ist.

Genau.

2 hours ago, Photon_1978 said:

Ich gehe mal davon aus, dass in der Wallbox nix ist was bei einem Spannungseinbruch schwächeln könnte.

Habe mal den Hardware-Entwickler gefragt, das Netzteil, dass die 12V für den Ladecontroller macht, funktioniert bis auf 85V runter, d.h. das sollte es nicht sein.

2 hours ago, Photon_1978 said:

Hat der Wlanabbruch irgendwelche Auswirkungen auf den Ladevorgang? Sollte eigentlich nicht.

Nur wenn du Lastmanagement machst.

2 hours ago, Photon_1978 said:

Also hab ich das richtig verstanden, wenn beim Laden der Widerstand über 1790 Ohm steigt, macht die Wallbox mit State 3 auf 2 aus?

Genau, dann würde die Wallbox das als 2,7k interpretieren, dementsprechend das Schütz abschalten und auf State 2 gehen.

Wenn der Taster nicht angesteckt ist, denkt die Box permanent, dass er gedrückt wäre. Das ist erstmal nicht schlimm (weil der Ladecontroller auf Knopfdruckänderungen reagiert, d.h. dir wird nicht die ganze Zeit die Ladung abgebrochen), wird mit der nächsten Firmware-Version aber dazu führen, dass die Wallbox ~ 30 Sekunden langsamer bootet.

Wenn du willst kannst du, damit der Taster die ganze Zeit gedrückt ist, Pin 3 und 4 der entsprechenden Buchse verbinden.

Was du tun musst hängt davon ab, ob in der neuen Firmware (oder falls du Updates überspringst in irgendeiner zwischen der installierten und der die du neu installieren willst) die EVSE-Firmware aktualisiert wurde. Das erkennst du daran, dass dann im Changelog etwas in Richtung "[Änderung...] (durch Update auf Ladecontroller-Firmware 2.1.6)" steht.

Falls das nicht der Fall ist, kannst du:

• Das esp32-firmware-git pullen
  (da du keine Änderungen außer der Firmware-Datei haben solltest, müsste das immer klappen)
• Dann sicherheitshalber ein git checkout warp2-x.y.z machen
  (Ich tagge immer den Commit, der dem Stand einer veröffentlichten Firmware entspricht. Das sorgt dafür, dass du auf einem definierten Stand bist und nicht ein paar unveröffentlichte Änderungen mitnimmst. Eigentlich sollte die Firmware auf jedem Commit funktionieren, aber bei größeren Änderungen kann das zwischenzeitlich auch mal nicht klappen.)
• Deine Firmware sollte dann noch in esp32-firmware/software/src/modules/evse_v2 liegen
• Die ESP-Firmware neu kompilieren und flashen

Wenn es eine neue Ladecontroller-Firmware gibt, musst du folgendes davor in evse-v2-bricklet/ tun:

• Mit git stash deine Änderungen bei Seite legen
• Mit git pull unsere Änderungen holen
• Dann git checkout vX.Y.Z damit du auch hier auf dem Stand einer veröffentlichten Firmware bist.
• Deine Änderungen wieder anwenden mit git stash apply
  (Falls das nicht klappt musst du nachsehen, was sich an der Code-Struktur geändert hat)
• EVSE-Firmware neubauen und wieder nach esp32-firmware/software/src/modules/evse_v2 packen
• Dann die Schritte von oben um die neue ESP-Firmware zu bauen

On 7/11/2022 at 4:45 PM, Photon_1978 said:

880 Ohm und 2700 Ohm wie groß ist der Toleranzbereich beim messen?

Ziemlich groß: https://github.com/Tinkerforge/evse-v2-bricklet/blob/90b0d370b231c3ca5b2ce9f093d318d988541c94/software/src/iec61851.c#L42-L56

Also alles < 1790Ω betrachten wir als 880Ω (State C = Laden), alles über 1790Ω als 2700Ω (State B = Auto will keinen Strom).

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Ich kann die Widerstände ja im Ladecontroller sehen. Gibt es eine Möglichkeit diese zu loggen?

Wenn dir einmal pro Sekunde reicht könntest du das z.B. über MQTT machen, oder mit einem Script dass http://warp2-xyz/evse/low_level_state abfragt.

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Vielleicht hab ich ja ein Problem mit den Widerständen?

Das wäre prinzipiell möglich, würde ich aber nicht mitten beim Laden erwarten. Wäre trotzdem interessant, wenn du das mal loggst.

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Wer kommt überhaupt auf die Idee im Zeitalter der digitalen Kommunikation analoge Widerstände zu messen??

Das ist absichtlich darauf ausgelegt, dass man theoretisch ohne Digitaltechnik auskommt, siehe auch hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Ich habe im Log viele wifi Abbrüche was merkwürdig ist da die Fritzfunke keine 80cm über der Wallbox sitzt.

Hm vielleicht ein Problem mit der Antennenausrichtung bzw. anderen Netzen auf dem Kanal? Ist das ein Repeater? Vielleicht versucht die Box sich zu einem anderen AP deines Netzes zu verbinden (dann wäre die BSSID-Sperre an). Alternativ: Wenn das nur 80cm sind, kannst du viell ein LAN-Kabel verlegen.

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Tja, ansonsten wenn ich herausfinden will warum der U5 was wie macht muss ich wohl erst chinesisch lernen, aber darum sollte er das laden abbrechen?

Was mir in einem der EVSE-Logs aufgefallen war, ist dass die Spannung auf L1 relativ niedrig ist, wenn er lädt. Meine mich an 216V erinnern zu können. Vielleicht bricht die Ladung ab wenn die Spannung unter irgendeinen Grenzwert fällt?

10 hours ago, Andreas_Mainz said:

Ich habe auch schon das Zbin File in das passende Directory vom Esp32 gelegt und mit Vsc eine neue Version gebaut.

Hast du den Dateinamen in z.B. bricklet_evse_v2_firmware_2_1_6.zbin geändert und die Firmware die da schon liegt z.b. in .zbin.old umbenannt? Der Bauprozess erzeugt die evse_v2_bricklet_firmware_bin.embedded.h/cpp automatisch aus einer Firmware-Datei die auf das Schema passt.

Ein Trick aus der Praxis damit man mit den Firmware-Dateien nicht durcheinander kommt: Die Versionsnummer ist in evse-v2-bricklet/software/src/configs/config.h hinterlegt. Für Entwicklungs-Firmwares kannst du die  FIRMWARE_VERSION_REVISION auf z.b. 99 ändern, die Firmware neu kompiliern und als bricklet_evse_v2_firmware_2_1_99.zbin nach esp32-firmware/software/src/modules/evse_v2/esp32-firmware/software/src/modules/evse packen. Das reduziert die Wahrscheinlichkeit, dass du durcheinander kommst welche Firmware jetzt gerade eingebettet wird/auf dem EVSE läuft.

10 hours ago, Andreas_Mainz said:

Dann habe ich das Merge File in die Wallbox runtergeladen und immerhin hat diese ganz normal wieder eingeschaltet. Es war nur alles in englischer Sprache, wo kann man die verwendete Sprache einstellen?

Das Webinterface kann deutsch und englisch und zeigt dir die Sprache an, die dein Browser als die bevorzugte angibt. Da sollte also zwischen den Firmwares kein Unterschied bestehen, wenn du nicht gerade deine Browser-Einstellungen geändert hast. Du kannst mit der Entwicklerkonsole deines Browsers nachsehen welche Sprachen er anfordert, indem du

navigator.languages

eingibst. Bei mir kommt z.B.

Array(3) [ "de", "en", "en-US" ]

als Ergebnis, also wird Deutsch vor Englisch bevorzugt.

On 7/9/2022 at 9:21 AM, Photon_1978 said:

Ich kann im Log der Box nur sehen wann es passiert, aber nicht von welcher Seite. Wird das irgendwo protokolliert?

Hast du im Ereignislog Ausgaben dieser Art?

Charger state changed from 0 to 2

Das ist der Fahrzeugstatus, also

• 0: Nicht angeschlossen
• 1: Angeschlossen aber Wallbox verbietet das Laden (rein technisch: Die Wallbox ein CP-PWM von 0% an)
• 2: Angeschlossen, Wallbox erlaubt das Laden (CP-PWM >= 10%), Auto müsste jetzt damits losgeht 880Ω anlegen
• 3: Lädt: Auto hat 880Ω angelegt, Schütz ist geschaltet
• 4: Fehler

D.h. wenn dein Ladevorgang mit einem

Charger state changed from 3 to 2

endet, dann hat das Auto wieder 2,7kΩ angelegt, also keinen Strom mehr angefordert -> Daraufhin hat die Box das Schütz abgeschaltet.

Wenn der Ladevorgang mit

Charger state changed from 3 to 1

endet, dann hat die Box den Ladevorgang beendet.

Bezüglich der Stromtests: Wir haben das mit dem Oszilloskop nochmal nachgezogen, das CP-PWM passt zu dem Wert den der Ladecontroller ausgibt. Das hängt natürlich (bzgl. Flankensteilheit usw.) auch davon ab, wie dein Auto genau misst. Aber: Was auf jeden Fall seltsam ist, ist dass du nie über die 15,7A kommst. Ich habe spontan nichts über das Ladeverhalten von dem Aiways U5 finden können, aber kann es sein, dass die Regelung über 16A dann nicht mehr linear ist sondern z.B. erst ab 25A die Ladeleistung erhöht wird?

Wie hast du bei dem Ladeziegel gemessen, dass das Auto dann wirklich 16A zieht?

On 7/8/2022 at 3:44 PM, Photon_1978 said:

Könnt ihr die realen Ampere aus dem Zähler auslesen? Und diese als Limit setzen?

Auslesen ja (siehst du auf der Stromzählerseite wenn du die Details aufklappst) Nachregeln nein: Das Limit nachregeln wenn ein Auto weniger zieht ist extrem gefährlich, falls es sich nicht linear verhält.

Wenn du willst kann ich dir kurz ein Python-Script schreiben, dass von 6 bis 20 Ampere in 0,1A Schritten abfährt, immer kurz wartet (damit das Auto reagieren kann) und dann Zählerwerte und PWM von der Box liest. Aber ich erwarte nicht, dass da mehr rauskommt, als das was du schon gemessen hast.

Noch ein Einwurf: Wenn du /home/andreas/git/evse-v2-bricklet/software/build gelöscht hast, sieh in /home/andreas/git/evse-v2-bricklet/ mit git status mal nach, dass du nicht noch andere Änderungen hast.

Aber auf /recovery kommst du? Dann zieh mal einen Debug-Report. Bei den Bricks auf meinem Tisch funktioniert das anstandslos.

You can enumerate all connected bricks and bricklets without knowing their UIDs:

https://www.tinkerforge.com/de/doc/Software/IPConnection_Python.html#enumerate

2 hours ago, Andreas_Mainz said:

Könnte man nicht einen Compilerschalter einführen, wie “External_Fi_Type_B“ available

Das können wir machen (als Compile-Flag in der EVSE-Firmware bzw. ein Define das gesetzt sein muss). Das führt natürlich trotzdem dazu, dass du bei jedem Wallbox-Firmware-Update, das eine neuere EVSE-Firmware mitbringt die EVSE-Firmware neu kompilieren und flashen musst.

2 hours ago, Andreas_Mainz said:

sogar als Parameter im Spiffs?

Persistent bzw. ohne dass du "manuell" eingreifen musst würde ich das nicht bauen wollen. Der DC-Schutz ist immerhin ein relativ wichtiger Sicherheitsmechanismus.

14 hours ago, Doncarlos said:

Langfristig wäre es schön, wenn der Lastmanager selbst wüsste was in seinem Cluster verbraucht wird.

Wir haben ein paar Ideen, wie man den Lastmanager effizienter machen kann, dafür bräuchte er dann auch die Zählerwerte der gesteuerten Boxen. D.h. langfristig könnte das kommen ;)

14 hours ago, Doncarlos said:

Alternativ , etwas weniger schön, wäre es, wenn in der charge_manager/state Liste mit den WARPs auch die IP Adresse der einzelnen Boxen mitübertragen werden würden.

Sieh dir mal charge_manager/config an. Damit kannst du von Namen auf Hosts mappen.

7 hours ago, Doncarlos said:

Der einzelne EVSE liefert das ja , aber ich möchte das ja über das ganze Cluster haben. Gibt es das irgendwo ?

Meinst du den aktuell erlaubten Strom pro Wallbox oder den aktuell verbrauchten Strom den der Stromzähler liest?

Ersteres bekommst du aus charge_manager/state (jeweils allowed_current). Den wirklich gezogenen Strom musst du von den Wallboxen selbst runterkratzen. Das Lastmanagement benutzt die Information nicht, weswegen wird das Stand jetzt nicht zwischen den Boxen kommuniziert.

On 7/1/2022 at 4:32 PM, timmy said:

Nun erhoffe ich mir, dass ich in der Wallbox den WLAN-Access-Point einrichten kann, sodass sich das E-Auto damit und weiter via Ethernet bis ins Internet verbinden kann. Kann bestätigt werden, dass das klappen sollte?

Stand jetzt geht das nicht. Ich hatte das vor längerem versucht zum Laufen zu bekommen, das ist aber leider komplex, deshalb hatte ich da nicht mehr Zeit investiert. https://github.com/Tinkerforge/esp32-firmware/issues/14 ist das Issue dazu. Unabhängig davon ist der Durchsatz des WLAN-APs aber auch eher schlecht (selbst wenn gerade nicht Bugs wie dieser https://github.com/espressif/arduino-esp32/issues/6706 auftreten kommt man nur auf 20 MBit/s) Eventuell lohnt es sich also einen kleinen WLAN-AP mit zwei Ethernet-Ports (einen für die Verbindung nach außen, einen für die Wallbox) in die Tiefgarage zu hängen.

On 7/1/2022 at 4:32 PM, timmy said:

OCPP implementieren. Ich lese, das wird kommen. Geht sich das innerhalb der nächsten 6-9 Monate aus?

Versprechen kann ich das nicht, aber ich gehe stark davon aus. Ich arbeite gerade an der OCPP-Implementierung.

Ah das erklärt einiges.

Dann musst du wie oben beschrieben dir eine Firmware für den Ladecontroller (das EVSE 2.0 Bricklet) kompilieren.

On 6/30/2022 at 9:09 AM, rtrbt said:

- Um eine neue EVSE Bricklet-Firmware zu bauen brauchst du den ganzen PlatformIO-Kram nicht. Das ist ein eigener Mikrocontroller mit eigener Firmware. Die Build-Umgebung dafür läuft in Docker, hier gibt es eine Anleitung zum Aufsetzen: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html#docker

Nach dem Aufsetzen der Build-Umgebung kannst du dir hier https://github.com/Tinkerforge/evse-v2-bricklet den Quellcode der EVSE-Firmware besorgen und dann software/src/dc_fault.c patchen. Auf den ersten Blick musst du nur sicherstellen, dass dc_fault.state immer auf DC_FAULT_NORMAL_CONDITION bleibt.

Die Firmware kannst du dann mit make im software-Verzeichnis kompilieren (das benutzt automatisch die Docker-Build-Umgebung wenn du alles richtig eingerichtet hast), dann solltest du in software/build eine evse-v2-bricklet-firmware.zbin bekommen.

Die Firmware musst du dann auf den Ladecontroller bekommen. Dafür gibt es folgende Möglichkeiten:

• Du kannst das EVSE Bricklet an einen ESP Brick anschließen, dann über http://[IP-deines-ESP-Bricks]/hidden_proxy den Proxy-Modus aktivieren und dich dann mit Brick Viewer zu eben dieser IP verbinden. Da sollte das EVSE als Unknown Bricklet auftauchen. Unter Updates/Flashing -> Bricklets kannst du als Firmware "custom" auswählen, dann mit Browse deine FIrmware auswählen und flashen
• Falls du einen Master Brick oder RPi HAT hast kannst du das EVSE Bricklet direkt an deinen PC anschließen und genauso flashen (dann unter localhost statt der IP des ESPs)
• Die robusteste Variante ist, deine EVSE-Firmware in eine Wallbox- (also ESP-)Firmware einzubetten. Dazu brauchst du das ganze PlatformIO-Setup, einen Klon von https://github.com/Tinkerforge/esp32-firmware und packst die evse-v2-bricklet-firmware.zbin nach esp32-firmware/software/src/modules/evse_v2/ Da müsste schon eine bricklet_evse_v2_firmware_x_y_z.zbin liegen, die musst du überschreiben. Beim Bauen der Wallboxfirmware wird eine .zbin mit exakt diesem Namensschema automatisch eingebettet. Beim Starten prüft die Wallbox-Firmware, ob auf dem EVSE Bricklet eine Firmware mit der erwarteten Versionsnummer läuft (das x_y_z aus dem Dateinamen) und wenn das nicht passt wird das Bricklet auf die eingebettete Firmware umgeflasht. Du kannst aber auch (falls auf dem EVSE schon eine Firmware mit der selben Version läuft) über das Webinterface unter Ladecontroller->Low-Level-Zustand ganz unten das neuflashen erzwingen.

In allen Fällen musst du mit deiner gepatchten EVSE-Firmware dann mit dem "upstream", lies uns Schritt halten, falls du die Wallbox-Firmware aktualisierst. Sonst verlierst du deine EVSE-Änderungen falls wir eine neuere Firmware einbetten.

Das dürfte schon immer so gewesen sein. Auch bei den alten Firmwares reagieren evse/current_limit und evse/start_charging nicht auf HTTP GET (das ist was dein Browser macht wenn du die URL aufrufst) sondern nur auf HTTP PUT. Bei den Node-RED HTTP-Knoten kannst du die Method aber einstellen.

18 hours ago, Little_Company said:

Generell sollte hier das „Core Profile“ für den Betrieb ausreichen.

Das ist die relevante Information ;). Ich hätte für den Anfang auch nur auf das Core Profile abgezielt. OCPP kann noch durch weitere Profiles erweitert werden, z.B. für Reservierungen, Lastmanagement, Authorisierungscaches usw. die wir ggfalls nachziehen können. Der aktuelle Plan ist aber, sobald das "minimale" Feature-Set des Core Profiles läuft mal eine Alpha-Version zu veröffentlichen und die gegen verschiedene Backends zu testen. Dauert aber wie gesagt noch etwas.

4 hours ago, wuesten_fuchs said:

Ich halte das eigentlich für durchaus ziemlich wichtig

Verständlich. Aber wenn man nach der Menge der Anfragen geht sind andere Features (allem voran OCPP an dem ich gerade arbeite) wichtiger.

Nein, die Box startet absichtlich neu. Es fehlte aber ein Hinweis in dem Modalfenster, dass sich öffnet wenn man auf Löschen klickt. Den habe ich mal eingebaut.

12 minutes ago, Doncarlos said:

Nette Features , vielen Dank!

Immer gerne :)

10 minutes ago, Doncarlos said:

Gibt es Best-Practises zum Thema Lastmanager ? In welchen Zyklen ist es geschickt den Strom zu steuern ? Gibt es Nachteile, wenn der Regelkreis wegen kleineren Leistungen nachregelt ?

Im Idealfall gibst du öfter als alle 30 Sekunden den Strom vor. Dann kannst du den Watchdog aktivieren, der, falls deine Steuerung ausfällt, den verfügbaren Strom auf den "Voreingestellt verfügbarer Strom" zurücksetzt. Den kannst du dann z.B. auf 6A stellen, damit falls deine Steuerung ausfällt du immer noch laden kannst (dann möglicherweise mit Netzbezug). Du kannst ihn auch auf 0A setzen, dann werden alle Ladevorgänge gestoppt falls deine Steuerung ausfällt.

Wenn du den Strom sehr hochfrequent aktualisierst sollte auch nichts passieren: Der Lastmanager regelt alle 10 Sekunden, ggfalls. gehen also Zwischenwerte verloren, was ja aber nicht schlimm ist.

Wenn du kleine Leistungsänderungen regelst, kann es sein, dass die angeschlossenen Autos nicht so genau nachziehen, wie man das gerne hätte. Das haben die EVCC-Leute für ein paar Autos ausprobiert: https://github.com/evcc-io/evcc/discussions/3261

Typischerweise dauert es auch ein paar Sekunden (ich glaube die Spezifikation schreibt < 5 Sekunden vor), bis ein Auto auf einen geänderten Ladestrom reagiert, zusätzlich zu den bis zu 10 Sekunden Latenz durch das Regelintervall des Lastmanagers.

3 minutes ago, Andreas_Mainz said:

Ohne Patch wird doch ein Fehler angezeigt, oder..Ich denke der Patch ist notwendig. Oder hat der Fehlerstrom Fehler keine Auswirkungen auf den Ladevorgang?

Doch der Fehlerstrom-Fehler bricht den Ladevorgang ab. Den würdest du ja aber nur erzeugen, wenn du die Fehlerstromüberwachung (Hardware!) aus der Wallbox ausbaust.

Ich meinte, dass du einfach die (soft- und hardwareseitig!) unmodifizierte Wallbox hinter einem Typ-B-FI betreiben kannst. D.h. es ist garnicht notwendig, die Fehlerstromüberwachung auszubauen.

30 minutes ago, Doncarlos said:

Muss ein Auto der Wallbox sagen wieviel Leistung es nun gerne nehmen würde ? Oder tut es das Auto einfach ? Mit Ankündigung müsste die Firmware das ja regeln können. Ohne ists doof.

Es ist doof :D Die Wallbox sagt dem Auto per PWM z.B. "Es sind gerade 10,6 Ampere verfügbar" und das Auto darf dann bis zu 10,6A auf allen Phasen ziehen, muss aber nicht.

31 minutes ago, Doncarlos said:

Bestenfalls geht es noch darüber zu sagen " Der Wallbox Verbund dürfte gerade mit X Leistung laden, der Warp-Cluster verbraucht aber nur 0,3X, dann ist es wohl ein PluginHybrid und ich kann die Amperes noch höher setzen".

Das würde funktionieren. Wenn es mal daneben trifft, (weil z.B. ein Auto spontan von 1 auf 3phasig wechsel, was theoretisch geht, aber mir unbekannt wäre, dass es das gibt) wäre das in deinem Setup ja nicht sehr schlimm, dann würdest du kurz mehr Strom aus deinem Hausanschluss ziehen und der Regelkreis korrigiert dann.

Das geht aber z.B. nicht wenn die Lastmanagement benutzt wird um sicherzustellen, dass ein Hausanschluss nicht überlastet wird.

Du kannst dann auf Nummer Sicher gehen und den "maximal verfügbaren Ladestrom" beim Lastmanagement-Master auf das Maximum, was die Leitungen und der Hausanschluss hergeben, konfigurieren, damit selbst wenn dein Regelkreis durchdreht nichts passiert.