borg

Cool 😀. Die größte Installation von WARP Chargern die ich kenne hat 50stk WARP2 (soweit ich weiß aber auf 2 unabhängige Lastmanagementkreise aufgeteilt). Also es wäre nicht die erste Installation in der Größenordnung. Da schreibst du uns am besten einmal an mit der Adresse der WEG (info@tinkerforge.com). Meistens überschätzt man wie viele Wallboxen gleichzeitig laden. Wenn wir sagen alle 30 Bewohner haben einen EV und im Schnitt lädt jeder jeden dritten Tag, dann würden im Schnitt 10 Wallboxen gleichzeitig laden. Wenn wir dann sagen über Nacht steht man so ~10 Stunden und man möchte mit 4.2kW minimum laden (42kWh in die Batterie über Nacht) dann wären das 10*4.2k = 42kW die am Hausanschluss über sein sollten (wenn dann mal 20 gleichzeitig laden würden, dann würde auch noch jeder 21kWh über Nacht bekommen in dem Szenario). In Wirklichkeit lädt aber der ein oder andere auch tagsüber und die wenigsten müssen jeden dritten Tag laden etc. Das ist also für den Durchschnitt schon konservativ gerechnet. Mehr dazu aber weiter unten, die Rechnung hat nämlich einen Haken. (*) Es ist in den neueren Firmwares bereits so dass das Lastmanagement weiter funktioniert wenn einzelne Wallboxen ausfallen. Wenn der Lastmanager ausfällt ist das schon problematischer. Wenn der Hausanschluss es zulässt könnte man da über einen minmalen Ladestrom als Fallback nachdenken. Muss dann natürlich gut überlegt sein bei der Konfiguration. Zentrale Nutzerverwaltung und zentraler Ladetracker wird in Kürze veröffentlicht, der Code dafür ist schon da. Wir sind aktuell noch am Feinschliff und das muss dann vor dem Release auch noch gut getestet werden, vermutlich machen wir da erst eine Beta. Geht bald zentral, siehe oben. Es muss am Anfang jede einmal konfiguriert werden, danach funktioniert die Nutzerverwaltung dann zentral mit der neuen Firmware. Ein Modus bei dem man einzelne Wallboxen per Default nur "read-only" sieht und für Konfigurationen ein zusätzliches Passwort o.ä. benötigt ist geplant, gibt es aber aktuell noch nicht. Je nachdem wie lange die Umsetzung des Projekts dauert könnte das dann schon fertig sein. Am einfachsten wäre es sonst sicher wenn die Nutzer erstmal keinen Zugriff auf das Webinterface der Wallbox bekommen. Ja das geht. Wir unterstützen NFC Forum Typ 1 bis 5 sowie Mifare Classic. Das deckt die allermeisten Karten ab, aber es werden insbesondere Karten nicht unterstützt welche keine feste UID haben (bzw. die UID durchrotieren). Das gilt z.B. für Kredit/Girokarten. (*) Die Rechnung oben geht eventuell nicht mehr auf wenn viele Bewohner einen dynamischen Strompreis haben und dann alle gleichzeitig in den günstigsten Stunden laden wollen. Wir betreiben in der Firma 16 WARP2/3 im Lastmanagement. Normalerweise sind davon 11stk von Mitarbeitern belegt bei uns. Wir betreiben die im Winter mit dynamischen Strompreis im Eco-Modus und geben die 4 günstigsten Stunden pro Tag frei. Damit das gut funktioniert muss dann für die 11 Autos für die 4 Stunden aber auch ein entsprechend großer Hausanschluss vorhanden sein (wir haben einen 200kW Anschluss + 200kWp PV. Vom Anschluss und der PV-Anlage können wir grob die Hälfte für die Wallboxen nutzen). Wenn man dann sagt 30 Bewohner der WEG sollen gleichzeitig die günstigsten paar Stunden pro Tag nutzen können, dann wird das irgendwann unrealistisch befürchte ich.

Ich glaube ich hab das Problem gefunden, siehe hier für eine Firmware zum Testen!

Ich glaube ich habs gefunden, bitte einmal die Firmware im Anhang aufspielen. Edit: Veraltete Firmware entfernt.

Ja, das ist normal weil wir während einem Phasenwechsels einen Ladevorgang nicht beenden wollen setzen wir die ADC Messungen aus. Sonst würde es innerhalb eines Ladevorgangs mit Phasenwechsel mehrere Einträge im Ladelogbuch geben und es könnte auch schnell eine Freigabe über NFC oder OCPP o.ä. verloren gehen. Das Problem hier ist dass: "phases_current" sowie "phases_requested" auf 1 stehen (d.h. ein etwaiger Phasenwechsel ist durch. Wenn dies der Fall ist muss CP wieder verbunden sein). Topic evse/control_pilot_disconnected ist 0 (d.h. es wurde nicht direkt über die API CP getrennt, das macht EVCC auch nicht) Wir sind im IEC61851 State B und der erlaubte Ladestrom ist 0 (in dem Zustand wird ein "EV wakeup", welches CP trennen könnte, nicht ausgeführt) Daher kann in Theorie in dem Zustand der State-Machine in dem sich die Wallbox befindet CP nicht getrennt sein ...ist es aber. Dadurch sind wir in einem "Deadlock". Wenn ich es gar nicht reproduziert bekomme würde ich zum nächsten Release erst einmal einbauen dass wir diesen Zustand erkennen können und dann CP einfach wieder verbinden. Ist aber natürlich nicht so schön da wir damit potentiell einen anderen Bug verschleiern.

Sieht aus wie das gleiche Problem das Raudi in dem anderen Thread auch hat. Nutzt du EVCC oder wird durch irgendwas anderes extern ein Phasenwechsel oder "CP Disconnect" ausgeführt? Aus Gründen die ich noch nicht verstehe wird CP getrennt und dann nie wieder verbunden 🤔.

OK, ist sehr komisch. Das sollte nicht mehr auftreten können in der 2.8.13. Sag bitte Bescheid falls es nochmal passiert. Ich schaue es mir in der Zwischenzeit nochmal an.

Nutzt du jetzt aktuell noch irgendwas dass ein "cp disconnect" über die API auslöst?

Mh, das sieht in der Tat komisch aus. Ich kann es mit den aktuellen Daten nicht reproduzieren (aber ich hab jetzt auch einen Tag Versatz in den Daten): Es scheint auch "nur" ein Anzeigebug zu sein, im Log kann ich folgendes sehen: Das ist der 15.11. bei dir und 0=Normalbetrieb, 1=blockierender Betrieb in 15-Minuten-Blöcken. D.h. der ganze rechte Teil wird als blockierend behandelt, wird allerdings nicht korrekt angezeigt 🫣. Ich werde das beobachten, sobald ich das reproduzieren kann ist es bestimmt ein einfacher Fix. Jetzt gerade auf die Schnelle konnte ich leider nicht rausfinden was da das Problem ist. Eine andere Sache macht mich allerdings stutzig: Du schreibst dass die Wärmepumpe im 15-Minuten-Takt taktet, allerdings hast du die Mindesthaltezeit auf 60 Minuten gestellt wenn ich das richtig sehe in der Konfiguration. In dem Fall sollte ein Zustandswechsel erst nach 60 Minuten wieder passieren dürfen. Im Log finde ich z.B. folgendes: Am 15. um 7:45 wurde in den blockierenden Modus gewechselt und in dem Fall wird der Zustand erst wieder gewechselt wenn die 60 Minuten um sind. Das wird soweit ich das überblicke auch eingehalten. Also eine Umschaltung in den Normalbetrieb erfolgt erst um 08:45.

Oh, in der Tat, kann ich im Log auch sehen. Da hatte ich gar nicht mit gerechnet. In dem Fall können wir da vermutlich mit den bestehenden Einstellungen nicht viel machen das Auto sagt dann von sich aus das es nochmal Strom möchte... Eventuell geht eine Automatisierungsregel die "Stop" macht wenn das Auto das erste mal von State 3 auf 2 wechselt und dann wieder Start (damit eine nächste Ladung wieder anfangen kann wenn man das Auto irgendwann wieder einsteckt) bei einem Wechsel auf 1. Kann ich jetzt gerade nicht testen, schaue ich mir morgen an.

Das hab ich auch noch nicht gesehen, der Kuga legt anscheinend selbst wenn er voll ist immer für 10s die 880 Ohm an... Du müsstest einmal unter Wallbox -> Einstellungen den Fahrzeug-Weckruf ausstellen. Das wird das Problem beheben. Interessant wäre ob das Auto dann bei PV-Überschussladen oder im Eco-Modus wenn es eine längere Ladepause gibt einschläft.

Ist ein Versuch wert. Wenn es dann nicht einschläft steht auf jeden Fall fest dass die Wallbox nichts machen kann.

Vielleicht hast du eine andere "step resolution" im Brick Viewer? Im Besipiel wird es auf 8 gesetzt: ss.set_step_configuration(ss.STEP_RESOLUTION_8, True) # 1/8 steps (interpolated) Probier das sonst mal mit STEP_RESOLUTION_256.

Wenn ich das richtig verstehe nutzt die EKZ die Börsenpreise und passt diese dann noch +- 5Rp an. Das können wir aktuell nicht so einfach unterstützen. Was allerdings geplant ist: Aktuell holt sich der WARP Charger die Preise über eine externe API. In Zukunft soll der WARP Charger selbst auch eine API haben über die man ihm die Preise setzen kann. Damit könnte man dann über eine kleine externe Automatisierung beliebige Preise einpflegen die nicht den Börsenpreisen entsprechen.

Ob es möglich ist dass die Wallbox das beeinflusst hängt davon ob wie das Model S feststellt dass es an einer Wallbox hängt. Im Typ2-Stecker (direkt im Stecker, das geht nicht durch das Kabel) ist ein Widerstand zwischen PP und PE. Anhand von diesem Widerstand kann das Auto auslesen wie viel Strom das Kabel maximal führen kann. Es kann daran natürlich auch erkennen dass ein Stecker eingesteckt ist. Ich könnte mir Vorstellen dass das Model S nicht einschläft solange ein Kabel eingesteckt ist und das Ladeziel noch nicht erreicht ist. Wenn das so ist kann die Wallbox da nichts machen leider.

Klar, die App ist komplett optional. Die App ist nur eine Möglichkeit über das Internet auf die Webseite der Wallbox zuzugreifen.

Läuft jetzt wieder alles, sorry das es so lange gedauert hat!

Da passiert hinter den Kulissen viel, insbesondere beim Thema Batteriesteuerung sind wir sehr aktiv dran, siehe hier für Details: Bezüglich der 10 Stunden am Stück blockiert könntest du den Regelzeitraum verringern. Ein Preis-Schwellwert für das Heizungsmodul steht allerdings auch schon auf der TODO-Liste :).

Besten Dank, das ist in der nächsten Release-Firmware die voraussichtlich schon Montag oder Dienstag kommt auch gefixt. Du kannst da erstmal über Wallbox -> Ladestatus -> Details -> "neu starten" wieder rauskommen aus dem falschen Zustand.

Du könntest einmal unter Wallbox -> Ladestatus -> Ladeprotokoll ein Ladeprotokoll starte und dann stoppen + runterladen. Reicht wenn das 3s oder so läuft. Dann kann ich sehen ob sich der Widerstandswert ändert oder ob er konstant bleibt. Zur anderen Frage: Wenn du händisch 45 Sekunden wartest und dann einen Phasenwechsel machst wird trotzdem zusätzlich 15 Sekunden gewartet. Daher macht das mit den 60 Sekunden natürlich Sinn, da hatte ich auch nicht dran gedacht.

Aktuell nur in dem du die Ladung händisch stoppst, dann länger wartest und dann die Phasenumschaltung durchführst. Das einzige was mir sonst noch dazu einfällt: Beim Stoppen der Ladung öffnen wir das Schütz erst wenn das Auto dies mit dem Widerstand bestätigt (oder spätestens nach 6s). An der Stelle könnten wir zusätzlich darauf warten dass der Strom unter 20mA fällt. Die Gefahr hier wäre natürlich dass wir uns false-positives einhandeln durch Fahrzeuge bei denen es normal ist dass >=20mA gezogen wird nach Beenden der Ladung.

Ich glaube da brauchst du eine Script o.ä. welches die csv einliest und "transponiert" wieder ausgibt. Grob von der Vorgehensweise müsstest du: Den Inhalt der Spalte "VAR" durchgehen und speichern welche eindeutigen Variablen es gibt Eine neue Tabelle erstellen in der die eindeutigen Variablen zu Spalten werden und zusätzlich die Spalten TIME, RAW mit einfügen die Original-Tabelle nochmal durchgehen und jetzt von oben nach unten das was bei RAW steht in der Spalte zur Variable eintragen und zu TIME matchen. Ich kenne mich mit National Instruments DIADEM leider gar nicht aus, ich weiß nicht ob das damit möglich ist. Für ein kleines Python-Script (o.ä.) wäre das allerdings relativ einfach. Sowas könntest du dir vermutlich gut von ChatGPT vibe-coden lassen :).

Oh spannend, dass ist das gleiche Problem was Raudi in seinem Tavascan-Thread auch hatte. Die Firmware im Anhang behebt das. Im laufe der nächsten Woche gibt es ein neues Release der WARP3-Firmware, da ist dann der Fix auch mit drin. Ein gutes Indiz dafür dass der Tavascan und der ID.7 den gleichen Ladecontroller haben :). warp3_firmware_2_8_10_68ecfb90_ecf2e45644d063e_merged.bin

Auf jeden Fall sehr interessant. Danke für die Forschung die du da betreibst. Leider immer wieder ernüchternd wie unterschiedlich sich die Autos mit unterschiedlichen Ladecontrollern oder auch nur unterschiedlichen Ladecontroller-Firmwares verhalten... aber bringt ja nichts, wir müssen irgendwie das beste draus machen.

Hier dann einmal zum Vergleich wie es korrekt aussieht:

Im Ladeprotokoll kannst du sehen wie wir das PWM vom 26% auf 100% erhöhen (blau), das Auto reagiert sofort und legt den 2700 Ohm Widerstand an gelb). Ein bisschen verspätet hört das Auto dann auf Strom zu ziehen, die Leistung geht von 3400W auf 20W (rot). Dann wartet der WARP Charger noch 3 Sekunden und schaltet dann das Schütz aus -> Leistung geht auf 0. 15 Sekunden später legen wir dann wieder 26% PWM an. Darauf reagiert das Auto für ein paar ms mit dem 880 Ohm Widerstand, aber springt dann sofort zurück auf 2700 Ohm. Ab da kann die Wallbox dann nichts machen, wir dürfen das Schütz nur freigeben wenn die 880 Ohm angelegt werden. https://vislog.warp-charger.com/KCAN5nqc5SSPb3EFjTQVas?configuration=cp_pwm_duty_cycle%2Cpower%2Cresistance_cp_pe Der einzige Parameter an dem wir drehen können ist die Wartezeit, die hier aktuell 15 Sekunden beträgt.