rtrbt

Unter der Prämisse, dass EVCC nicht direkt mit dem Auto redet (dann müsstest du https://docs.evcc.io/docs/devices/vehicles#volkswagen-we-connect-id eingerichtet haben), sollte EVCC keinen Einfluss gehabt haben. CP-Trennungen sind auch in beiden Fällen nicht passiert. Ich fürchte, dass ist wirklich die Software des Autos. Habe spontan https://www.goingelectric.de/forum/viewtopic.php?f=100&t=14508 und https://www.goingelectric.de/forum/viewtopic.php?f=101&t=8525 gefunden. Bei manchen Leuten hilft wohl ein Software-Update, bei anderen macht es das schlimmer. Außerdem habe ich noch https://www.goingelectric.de/forum/viewtopic.php?t=31028&start=10 gefunden. Hast du nur eine Abfahrtszeit oder auch einen Mindestladestand konfiguriert?

Ich glaube Matze meinte, dass im Event-Log-Teil viele Ladevorgänge sind. Protokolliert ist in der Tat nur ein Ladevorgang. In dem sieht man folgendes: - Aus Sicht der Wallbox verbietet nur EVCC den Ladestart - 15 Sekunden nach Start des Protokolls hast du das Auto angesteckt - Nochmal 10 Sekunden später erlaubt EVCC den Ladevorgang - Ungefähr 0,4 Sekunden später fordert das Auto Strom an und beginnt zu laden. - Nach ~ 47 Sekunden fordert das Auto keinen Strom mehr an Prinzipiell hast du damit Recht. EVCC und Wallbox kommunizieren nur an das Auto ob und wenn ja wie viel Strom verfügbar ist. Wenn Strom verfügbar ist, dann muss das Auto signalisieren, dass es laden möchte und wenn es das tut, wird das Schütz geschaltet. D.h. in letzter Instanz entscheidet das Auto, wann es lädt. Eine Idee hätte ich noch: Die Wallbox hat eine CP-Trennung eingebaut. Damit können wir dem Auto vortäuschen, dass man das Kabel auf Wallboxseite abgezogen hat (Das Auto weiß nicht, ob die Wallbox eine Dose oder ein fest angebrachtes Kabel hat). Die CP-Trennung ist nützlich, weil damit manche Autos aufgeweckt werden können, falls deren Ladeelektronik im Stand-By ist. Wir versuchen das Auto aufzuwecken, wenn 30 Sekunden lang Strom verfügbar ist und das Auto keinen anfordert. Es kann jetzt sein, dass dein Auto "vergisst", dass es zeitversetzt laden soll, wenn die CP-Trennung passiert. Du kannst deshalb unter Wallbox -> Einstellungen den Fahrzeug-Weckruf deaktivieren. Dann wird eine CP-Trennung nur noch durchgeführt, wenn die Wallbox eine Phasenumschaltung durchführt.

Noch ein Punkt: Abhängig von deinen Großverbrauchern kann es sinnvoll sein, die WARP phasenrotiert anzuschließen. Damit einphasiges Laden nicht auf der gleichen Phase läuft wie die anderen Verbraucher.

Das sollte mit dem dynamischen Lastmanagement funktionieren: https://docs.warp-charger.com/docs/warp_charger/chargemanagement#funktionsweise Kurzer Überblick was dafür zu tun ist: Strom pro Phase am Hausanschluss messen (Wenn du schon die Leistung pro Phase misst, kannst du einfach durch 230V teilen, das ist gut genug, besser wäre natürlich die Phasenspannung zu benutzen) Auf der WARP einen API-Zähler einrichten (Tutorial hier: https://docs.warp-charger.com/docs/mqtt_http/examples/#api-zähler-für-pv-überschuss), der mindestens die drei Phasenströme als Werte hat: Per MQTT die Werte von deinem Hausanschlusszähler auf die WARP-API schieben: https://docs.warp-charger.com/docs/mqtt_http/api_reference/meters/#meters_X_update_any Dynamisches Lastmanagement einrichten, dabei musst du etwas an den Werten "Maximaler Strom am Netz­an­schluss", "Strom­beda­rf des größten Ein­zel­ver­brau­chers" und "Zu­sätz­li­che Si­cher­heits­mar­ge" spielen. Wenn du darunter "Debug" aufklappst, siehst du drei weitere Werte, vorallem wichtig ist "Zielstrom". Das ist der Strom, den die WARP am Hausanschluss versucht zu erreichen. Wenn dein Großverbraucher z.B. gerade 10 A zieht und der Zielstrom sind 18 A, dann versucht die WARP langfristig 8 A für das Auto zu erreichen. Das kannst du über Automatisierungs-Regeln bauen, z.B. so: Damit du auf 1,4 kW herunterkommst brauchst du zwingend eine Wallbox, die eine Phasenumschaltung hat (z.B. eine WARP3)! Mit drei Phasen kommst du nur auf 4,2 kW. Im Idealfall benutzt du Mosquitto o.Ä. als MQTT-Broker. Das MQTT-Plugin von ioBroker ist auf mehrere Weisen kaputt.

Hm, das ist hier: schonmal aufgekommen, aber war untergegangen. Ich habe gerade die Konfiguration der Suche repariert, jetzt wird die Ladecontroller (EVSE)-Unterseite auch indiziert:

Spezifisch: Wenn der Ladevorgang einmal vom Auto unterbrochen wurde (z.b. weil es voll ist, oder bei manchen Autos auch wenn die Zentralverriegelung geöffnet wird), dann wird ein Ladevorgang erst gestartet, wenn min. 9 A zur Verfügung stehen. Min+PV meldet in der Standardeinstellung aber nur 6 A.

Benutzt du yay nur zum Herunterladen aus dem AUR? Eigentlich sollte das Paket auch gebaut werden und der PKGBUILD führt build_src.py aus: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brickv (Zeile 21) Wenn du das Paket von Hand bauen willst, kannst du makepkg (ohne Parameter oder mit -si wenn du brickv auch installieren möchtest) benutzen: https://wiki.archlinux.org/title/Makepkg#Usage

Du kannst prinzipiell mit den Automatisierungsregeln den verfügbaren Strom des Lastmanagements setzen. Also kannst du z.b zwei Regeln wie folgt konfigurieren "Wenn Abschalteingang geöffnet, setze Lastmanagementstrom auf 32 A" und "Wenn Abschalteingang geschlossen, setze Lastmanagementstrom auf 12 A". (Disclaimer: Ob das mit der erlaubten Gesamtleistung so funktioniert weiß ich ad-hoc nicht, aber rein technisch ist das möglich)

Wenn du ein Originalgehäuse ohne Löcher möchtest, schreib eine Mail an info@tinkerforge.com und verweise auf den Thread hier. Wir haben noch ein paar ohne Bohrungen.

Ja, das sieht gut aus. Danke für den Test!

Ist dein Auto einfach voll? Ich sehe im Log folgende Ausgaben: 2024-10-21 17:16:32,499 | users | Charger state changed from 0 to 1 2024-10-21 17:16:40,499 | users | Charger state changed from 1 to 3 2024-10-21 17:16:40,583 | charge_tracker | Tracked start of charge. 2024-10-21 17:17:29,634 | users | Charger state changed from 3 to 2 2024-10-21 17:17:40,678 | users | Charger state changed from 2 to 1 0->1 heißt das Auto wurde angesteckt. 1->3 heißt der Lastmanager hat Strom freigegeben und das Auto hat sofort Strom angefordert, also wurde das Schütz geschaltet. (2 wurde übersprungen, weil das Auto sofort reagiert hat) 3->2 heißt, dass das Auto keinen Strom mehr anfordert. Typischerweise, weil es voll ist. 2->1 ist dann, dass der Lastmanager den Strom weggenommen hat, weil das Auto keinen wollte. Trotzdem hätte es so sein sollen, dass der Lastmanager wieder Strom zuteilt, das ist bei dir nicht passiert, weil Min+PV nie auf über 9 Ampere gegangen ist. Mit der Firmware im Anhang sollte das Problem weg sein. Dann sollte, wenn das Auto abschaltet und zwischen 6 und 9 Ampere verfügbar sind oder Min+PV aktiv ist, trotzdem Strom zugeteilt werden. warp3_firmware-NIGHTLY_2_6_1_6717a226_04aadc90170c8e4_merged.bin

Versuch mal dein Glück mit dieser Firmware. Du triffst vermutlich eine ganze Kette von Bugs u.A. folgende: 1. Das MQTT-Plugin von ioBroker hält sich auf mehrere Arten nicht an die MQTT-Spezifikation, siehe auch: (ich unterstelle dir mal, dass du ioBroker benutzt, sonst kann ich mir folgende Meldungen nicht erklären) 2024-10-21 13:47:18,257 | mqtt | Received message on unknown topic 'rtc/identity' (data_len=4) 2024-10-21 13:47:18,311 | mqtt | Received message on unknown topic 'charge_manager/available_phases' (data_len=12) 2024-10-21 13:47:18,619 | mqtt | Received message on unknown topic 'automation/timed_config_modified' (data_len=14) 2024-10-21 13:47:18,625 | mqtt | Received message on unknown topic 'automation/timed_config' (data_len=17) 2. Wir haben falsche Annahmen bezüglich der MQTT-Implementierung des Microcontrollers in der Wallbox getroffen 3. Die MQTT-Implementierung verkraftet nicht den ioBroker-Traffic und unsere falsche Annahme in Kombination. In Summe wird der RAM zugemüllt und nach kurzer Zeit können keine WLAN-Pakete mehr verschickt werden. Das dauert anscheinend ~ 80 Sekunden nachdem eine Verbindung aufgebaut wurde und der Microcontroller braucht bis zu 10 Minuten um sich davon zu erholen (also bis wieder eine WLAN-Verbindung aufgebaut werden kann). Wenn wieder eine Verbindung besteht, verbindet sich MQTT sofort neu und ioBroker bringt uns direkt wieder in den kaputten Zustand. Ich habe jetzt Punkt 2 gefixt, weshalb der RAM nicht mehr zugemüllt wird, sodass dein direktes Problem erstmal gelöst sein sollte. Prinzipiell solltest du entweder vom ioBroker-MQTT-Plugin auf einen echten MQTT-Broker (z.B. mosquitto) wechseln. (Das ist nicht nur meine Ansicht, dass das kein echter Broker ist, Zitat aus deren README: https://github.com/ioBroker/ioBroker.mqtt Alternativ solltest du zumindest "Publish own states on connect" in den Einstellungen des MQTT-Plugins deaktivieren. Dann sollten die Logmeldungen von oben auch verschwinden. warp2_firmware-NIGHTLY_2_6_1_671778fe_14b645f38e83042_merged.bin

Kannst du davon auch nochmal einen Debug-Report ziehen? Ich würde gerne sehen, ob die Verbindungsabbrüche den selben Fehlercode haben.

Hast du die ~ 5 Minuten vor 15:39 noch? Die wären vorallem der interessante Teil. Im Log steht folgendes: 2024-10-15 15:39:32,273 Hysteresis 4757 0: raw(5447 13920 13920 13920) min(5408 13920 13920 13920) spread(1547 13920 13920 13920) max_pv 5965 0: [ 0 0@1p;4220Wh] 1: don't have B1 1: 0: alloc_ge_thres 0 min_active 1 rot 0 keep_active 1 can p-switch 1 2: filtered 1 to 0, sorted to | 0 Calc Wnd 0 wnd_min (6000 6000 6000 6000) current_avail_for_3p 5447 0 (1p unknown rot) wnd_max (9060 9060 9060 9060) Wnd (6000 6000 6000 6000)->(9060 9060 9060 9060) 3: filtered 1 to 1, sorted to 0 | 3: wnd_min 6000 <= p1 raw 13920 3: wnd_min 6000 <= p2 raw 13920 3: wnd_min 6000 <= p3 raw 13920 3: wnd_min 6000 > max_pv 5965 3: shut down 0 Calc Wnd current_avail_for_3p 5447 Wnd (0 0 0 0)->(0 0 0 0) 4: don't have active chargers. 4: filtered 1 to 1, sorted to 0 | 4: Can activate 0? Does not improve spread Can't activate: p0 min 5408 < required 18000 4: No 4: 0 retrying 1p Does not improve spread Can't activate: p0 min 5408 < required 6000 4: No 5: have active chargers. 5: filtered 1 to 0, sorted to | 0 6: filtered 1 to 0, sorted to | 0 8: filtered 1 to 0, sorted to | 0 9: raw(5447 13920 13920 13920) min(5408 13920 13920 13920) spread(1547 13920 13920 13920) max_pv 5965 9: [ 0 ] PM PV m= 28w avl= -228w -991<< -991< -991< 5965 L1 m= 5536 p= 5441 err=26239 adj=26239 13920<<13920<16000 L2 m=-2818 p=-2801 err=34481 adj=34481 13920<<13920<16000 L3 m=-3051 p=-3040 err=34720 adj=34720 13920<<13920<16000 Das ist der Durchlauf des Verteilungsalgorithmus, der die Wallbox abgeschaltet hat + die erste Stromzählermessung danach. Kurzes Tutorial im Trace-Log-Lesen: Alles mit PM am Anfang sind die Stromzählerwerte + der Regler, der mit diesen Werten den PV-Überschuss bestimmt. Timestamp + alles mit einer Ziffer am Anfang sind der Verteilungsalgorithmus, die Ziffern sind die 9 Stufen (siehe auch hier: https://docs.warp-charger.com/docs/warp_charger/charge_management_details) Die Zeile "3: shut down 0" sagt, dass die nullte Wallbox (also die erste in Informatiker-Zählweise) abgeschaltet wurde, darüber steht "3: wnd_min 6000 > max_pv 5965". Das bedeutet, dass, damit die Wallbox aktiv bleiben darf 6000 mA PV-Überschuss verfügbar sein müssten (das ist wnd_min, also das Minimum des Verteilungsfensters), es standen aber nur maximal 5965 mA in den letzten 4 Minuten zur Verfügung. Zusammengefasst: Der PV-Überschuss war vier Minuten lang unter dem notwendigen Minimum um die Wallbox aktiv zu halten, also wird abgeschaltet.

Ah, ich glaube ich sehe das Problem: Du hast auf der Wallbox das Lastmanagement aktiviert. (D.h. unter Energiemanagement->Wallboxen Lastmanager ausgewählt). Das Lastmanagement steuert die Phasenumschaltung selbst und erlaubt deshalb EVCC nicht umzuschalten. Du hast aber nur eine Wallbox die vom Lastmanager gesteuert wird (den Manager selbst) und hast weder dynamisches Lastmanagement, noch PV-Überschussladen aktiviert. Also kannst du das Lastmanagement deaktivieren: es würde sowieso nichts anderes tun, als die 32 A sich selbst zuweisen. Danach sollte EVCC (ggfalls. nach einem Neustart) die Phasenumschaltung anbieten.

Nur um auf Nummer sicher zu gehen: Zieh mal einen Debug-Report von der Wallbox unter System->Ereignis-Log und poste die evcc.yaml. Nicht dass irgendetwas falsch konfiguriert ist.

Ungesundes und Monate altes Halbwissen: Als ich die Phasenumschaltung mit der WARP3 getestet hatte, musste ich EVCC einmal neustarten, damit der automatische Wechsel aufgetaucht ist. Ich konnte das dann aber nicht ad-hoc reproduzieren.

Was für ein Auto versuchst du denn zu laden? Edit: Sorry, wer lesen kann, ist klar im Vorteil. Dann würde ich das auch auf den VW-Notelademodus schieben.

Siehst du unter Wallbox->Ladestatus auch als "Erlaubter Ladestrom" z.B. 16 A? Und werden dir dort bei "Schützprüfung" beide Schütze als geschlossen angezeigt? (wenn du ganz auf Nummer sicher gehen willst: Was ist im Low-Level-Zustand auf der selben Seite das CP-PWM-Tastverhältnis? Bei 16 A sollten das 26,7 % sein) Wenn das alles passt, dann möchte dein Auto nicht mehr Strom beziehen. Prinzipiell ist es so, dass die Wallbox nur ein oberes Limit vorgibt und das Auto sich entscheiden kann weniger Strom zu ziehen. Eventuell hast du ein Ladelimit im Auto konfiguriert? Alternativ gibt es Autos, die, wenn der Stecker nicht richtig steckt bzw. nicht verriegelt werden kann, in eine Art Notlademodus wechseln. Dann würde ich aber erwarten, dass 4,1 kW bezogen werden.

Wir prüfen gerade, ob man das Problem direkt im Ladecontroller lösen kann.

OCPP 2.0 ist derzeit nicht geplant und macht ohne eine gleichzeitige ISO15118-Implementierung bzw. V2G auch wenig Sinn. (ISO15118 kann über OCPP 2.0 getunnelt werden) Hast du einen konkreten Use-Case dafür? Ich wüsste im Moment nicht, dass es OCPP-Backend-Server gibt, die 2.0, aber nicht 1.6 sprechen. Das wäre aber eine interessante Information, wenn du da mehr weißt.

Firmware: WARP1 2.6.1, WARP2 2.6.1, WARP3 2.6.1 Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: GoodWe Hybrid-Wechselrichter Registrierung des Fernzugriffs mit Safari repariert Benutzerinterface der Registierung des Fernzugriffs verbessert Benutzerinterface der Stromzähler-Unterseite verbessert Sichergestellt, dass Stromzählergraph nur angezeigt wird, wenn Zähler verbunden ist (Nur WARP3) Repariert, dass WARP Energy Manager einen WARP3 Charger zu einphasigem Laden gezwungen hat Repariert, dass Lastmanagement ein Fahrzeug nicht als voll erkannt hat, wenn der Ladevorgang sofort (durch einen A->C-Übergang) gestartet wurde (Durch Update auf Ladecontroller-Firmware 2.1.12 (WARP1) bzw. 2.2.6 (WARP2, WARP3)) Download: WARP1 2.6.1 bzw. WARP2 2.6.1 bzw. WARP3 2.6.1

Die Pin-Belegung kannst du im Schematic des Ladecontrollers nachsehen: https://github.com/Tinkerforge/evse-v3-bricklet/blob/main/hardware/evse-v3-schematic.pdf Von Pin 1 (links) an: 5V LED Rot LED Grün LED Blau Switch Ground Der Taster ist ein Öffner, d.h. wenn du Pin 5 und 6 verbindest, dann betrachtet der Ladecontroller den Knopf als nicht gedrückt, wenn du die Pins nicht verbindest, dann ist der Knopf gedrückt.

https://github.com/Tinkerforge/esp32-firmware/issues/36 steht auf der Liste, aber wie du siehst schon länger :D

Schon. Führt dann aber unter anderem dazu dass 1. die API an der Stelle auseinanderläuft zwischen den Wallbox-Varianten (das wäre hässlich aber notfalls verschmerzbar) und 2. dann wieder andere Leute hier im Forum sich beklagen, dass wir unnötig viel Traffic per MQTT rausschicken. API-Design ist schwierig (und bei der Wallbox definitiv nicht optimal, aber brechende Änderungen nach Jahren tun weh) und wir balancieren oft mehr Anforderungen, als man auf den ersten Blick sieht. Wir haben u.A. vor irgendwann in der Zukunft eine vereinfachte API zu entwickeln, als Alternative zum Vollausbau, der im Moment existiert (und teilweise auf die Anforderungen des Webinterfaces zugeschnitten ist). Eventuell können wir da auch eine einfacher zu benutzende Variante des Meldens von Zählerdaten einbauen. Um dein konkretes Problem zu lösen: Es gibt z.B. das final-Plugin für telegraph: https://docs.influxdata.com/telegraf/v1/plugins/#aggregator-final mit dem du anscheinend zwei Datenquellen zusammenlegen kannst. Dann hast du IDs und Messwerte auf einem "Topic" (oder wie das in Influx-sprech auch immer heißt) und das Plugin sollte für dich auch das Reihenfolgenproblem lösen. (Disclaimer: Ich bin kein Influx-Experte, aber es klingt als könnte das irgendwie funktionieren) Edit: Alternativ gibt es noch das merge-Plugin: https://github.com/influxdata/telegraf/blob/release-1.31/plugins/aggregators/merge/README.md damit hatte jemand, der deinen Use-Case hatte aber Probleme: https://community.influxdata.com/t/why-are-my-fields-from-mqtt-topics-not-merged/32929 und wurde auf das final-Plugin verwiesen.