rtrbt

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.

Es gibt ocpp/state und darin das Feld "connected". ocpp/state ist im Moment aber absichtlich undokumentiert, weil wir uns noch die Möglichkeit offenhalten wollen, die API zu ändern.

Fairerweise: Ich bekome es gerade nicht hin (ohne das Vorwissen einzusetzen, dass ich die API kenne), die Suche der API-Dokumentation davon zu überzeugen, mich zu evse/indicator_led zu führen. Mal sehen ob wir die Suche etwas tunen konnen. Edit: Ja, da ist irgendetwas mit der Suche kaputt. Ich kann nach beliebigen APIs suchen (z.B. nfc/config oder auch energy_manager/sdcard_state) aber nicht nach evse/ APIs. Die tauchen nicht auf.

(Achtung Totschlagargument! :D ) Das hat technische Gründe. Konkret: Der Mikrocontroller, den wir benutzen, hat nur begrenzt RAM. Deshalb müssen wir die Maximallänge von APIs beschränken, gerade von APIs die sich oft ändern, weil dann viele MQTT-Pakete generiert werden, die sich bei eventuell langsamen WLAN durchaus mal aufstauen können. Die IDs (die sich nur maximal einmal ändern sollten) und die Werte (die sich sekündlich ändern können) zu koppeln würde dazu führen, dass deutlich größere MQTT-Pakete generiert werden. Das wird auf einer WARP1 (die weniger RAM als eine WARP2 oder 3 hat) dann eng.

Das Lastmanagement ist in der frisch veröffentlichten Firmware 2.6.0 enthalten. Danke fürs testen!

Firmware: WARP 2.6.0, WARP2 2.6.0 und WARP3 2.6.0 Lastmanagement überarbeitet: Phasen werden unabhängig gesteuert Dynamisches Lastmanagement hinzugefügt Unterstützung von PV-Überschussladen mit mehr als einer Wallbox hinzugefügt Download: WARP 2.6.0 bzw. WARP2 2.6.0 bzw. WARP3 2.6.0

@pene8@dinkel1975 Testet bitte beide mal die Firmware im Anhang. Problem Nummer 2 sollte damit behoben sein. Das ist jetzt eine Firmware mit dem Stand von 2.5.0 + Lastmanagement-Beta, d.h. mit Fernzugriff usw., falls ihr damit spielen wollt. Edit: Veraltete Firmware entfernt.

Leider noch nicht. Es gibt ein offenes Issue dazu, damit wir das Problem nicht vergessen. https://github.com/Tinkerforge/esp32-firmware/issues/262 Erledigt, danke für den Hinweis :) https://github.com/Tinkerforge/esp32-firmware/commit/7478a93af5469069ae14c3d1070b3e304afc4d38

Du musst dir zwei Keypaare generieren (wie z.b. hier beschreiben: https://wiki.archlinux.org/title/WireGuard#Key_generation) und dann die entsprechenden Schlüssel verteilen. Wenn du zum Beispiel mit wg genkey | (umask 0077 && tee warp.key) | wg pubkey > warp.pub wg genkey | (umask 0077 && tee peer.key) | wg pubkey > peer.pub die Keys erstellst, dann musst du auf der Wallbox warp.key als eigenen privaten Schlüssel und als öffentlichen Schlüssel der Gegenstelle. Bei deiner Gegenstelle musst du dann peer.key als dessen privaten Schlüssel konfigurieren und warp.pub als öffentlichen Schlüssel (der Gegenstelle der Gegenstelle, also der Wallbox)

Firmware: WARP 2.5.0 neuveröffentlicht Das Fernzugriffs-Modul des Webinterfaces fehlte in der gestern veröffentlichten Firmware. Download: WARP 2.5.0

Firmware: WARP 2.5.0 Firmware-Update-Prüfung und -Download hinzugefügt Fernzugriff hinzugefügt Download: WARP 2.5.0

Firmware: WARP Energy Manager 2.2.0 Firmware-Update-Prüfung und -Download hinzugefügt Fernzugriff hinzugefügt Firmware-Updates signiert Fokusverlust bei Bearbeitung des Anzeigenamens repariert Übersetzung der Namen von heruntergeladenen Dateien repariert Sichergestellt, dass lange SSIDs nicht das Webinterface-Layout brechen Fehlermeldung hinzugefügt, falls Recovery-Seite das Zurücksetzen auf Werkszustand nicht starten kann MQTT-Automatisierungsregeln mit Präfix repariert Fehlenden Leistungsgraphen bei Victron Energy GX-Stromzählern behoben Download: WARP Energy Manager 2.2.0

Firmware: WARP 2.4.2, WARP2 2.5.0 und WARP3 2.5.0 (Nur WARP2/WARP3) Firmware-Update-Prüfung und -Download hinzugefügt (Nur WARP2/WARP3) Fernzugriff hinzugefügt Konfigurierbare Totzeit nach Erkennen eines NFC-Tags zum Ladestart hinzugefügt Blinken der LED bei Neustart der Wallbox hinzugefügt Firmware-Updates signiert (Nur WARP2/WARP3) Kompatiblilität der OCPP-Autorisierung verbessert Repariert, dass Wallboxen vom Lastmanager mehr als 32 Ampere zugeteilt wurden Generierung von leeren Ladelog-PDFs repariert Fokusverlust bei Bearbeitung des Anzeigenamens repariert Übersetzung der Namen von heruntergeladenen Dateien repariert Sichergestellt, dass lange SSIDs nicht das Webinterface-Layout brechen Fehlermeldung hinzugefügt, falls Recovery-Seite das Zurücksetzen auf Werkszustand nicht starten kann MQTT-Automatisierungsregeln mit Präfix repariert (Nur WARP1) Fehlenden Leistungsgraphen bei Victron Energy GX-Stromzählern behoben Download: WARP 2.4.2 bzw. WARP2 2.5.0 bzw. WARP3 2.5.0