rtrbt

Eventuell benutzt EVCC den korrekten Energiewert, aber auf dem WARP Charger siehst du noch den Import+Export-Wert. Wir hatten das kürzlich geändert, weil sich herausstellte, dass man je nach Situation (z.B. 1- vs 3-phasiges Laden) einen minimalen Export (~0,1%) misst. Details stehen in diesem Blogpost ganz unten:https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/

Das Problem ist, dass die LAN-Verbindung abggerissen ist. Danach versucht die Wallbox weiterhin Lastmanagement-Pakete zu verschicken, da die aber nicht übertragen werden können, stauen sie sich auf der Wallbox auf. Irgendwann ist der Sendebuffer voll und dann entstehen die "Failed to send state: Not enough space (12)"-Meldungen. Das ist nicht kritisch, aber etwas unschön, dass das Ereignis-Log damit zugemüllt wird. Eventuell können wir das etwas sauberer behandeln. Der Ladevorgang wurde nach 30 Sekunden unterbrochen, da die Wallbox den Lastmanager nicht mehr erreichen konnte. Damit in dieser Situation keine Überlast erzeugt wird, versucht ein Lastmanager alle Wallboxen zu stoppen, wenn die Verbindung zu mindestens einer unterbrochen ist _und_ alle Wallboxen stoppen den Ladevorgang von sich aus, wenn 30 Sekunden lang keine Daten vom Lastmanager empfangen wurden.

Für die Nachwelt: Hat sich geklärt: https://github.com/evcc-io/evcc/issues/13590 war das Problem.

Das ist gut möglich. Starte mal ein Ladeprotokoll und gehe dann von 16A bis 6A alle 10-15 Sekunden ein Ampere runter. (Am besten ohne deinen dynamischen Boost-Modus ;) ) Ich würde erwarten, dass du dann im Protokoll beim gemessenen CP-Widerstand siehst, dass er nach steigt, wenn der erlaubte Strom sinkt. Wenn du das für ID.4 und Zoe machst, können wir nochmal nachkalibrieren.

Das muss ich mir nochmal in Ruhe ansehen, komme aber gerade nicht dazu. Ich melde mich nächste Woche nochmal.

Noch eine Ergänzung dazu: Wenn die Wallbox das erste Mal einen Zähler sieht, aktiviert sie die Zählerüberwachung. Danach sind Ladevorgänge nur noch möglich, wenn der Zähler ausgelesen werden kann. D.h. wenn jemand den Zähler ausbaut ö.Ä. blockiert die Wallbox das Laden. Die Zählerüberwachung kannst du im Webinterface deaktivieren, falls du deine WARP3 Pro auf eine Smart downgraden willst, oder der Zähler wirklich kaputt ist.

Stimmt, das war noch privat. Sollte jetzt sichtbar sein.

Ab dem nächsten EVCC-Release musst du das Energy Manager Topic nicht mehr eintragen, WARP3 wird dann separat unterstützt: https://github.com/evcc-io/evcc/commit/dcb1f5c313d6ff3db8c78e4d309842ef5dc3aeb6

Das ist weniger eine Begründung, warum du das nicht tun solltest und mehr eine Erklärung, warum man das Offset des Boost-Modus nicht konfigurieren kann. Wenn ich einen Worst-Case konstruieren sollte, wäre das vermutlich, dass du für einen Zoe R135 kompensierst (sagen wir mal + 1,5A), und dann ein Model 3 (falls es das mit 22kW-Lader gibt, das habe ich gerade nicht im Kopf) anschließt: Das Model 3 zieht gerne mal 0,5A mehr, als du vorgibst, d.h. du könntest 2A über der Vorgabe liegen. Wenn dein LSS funktioniert und nicht rausfliegt, sollte (Achtung! Bin nur Software-Entwickler, kein Elektriker) nichts passieren, aber wenn dein Haus abbrennt oder deine Milch sauer wird, ö.Ä. bist du schuld :D

Je nachdem welche Art Zoe das ist musst du möglicherweise sehr stark korrigieren: Das ist der Ideale Ladestrom vs. was die Autos wirklich ziehen (die Daten rauschen etwas :D ). Wenn du selbst drin rumzoomen willst: https://github.com/Tinkerforge/warp-charger/blob/master/tools/current_ramp/allowed_vs_effective_3.gp D.h. wenn du z.b. einen R135 (gelb einphasig, orange dreiphasig) auf 16A zwingen willst, müsstest du ~ 17,25A vorgeben. Das ist aber wenn du ein anderes Auto anschließt viel zu viel. Der Boost-Modus so wie wir ihn implementiert haben ist genau so viel mehr, wie die Spezifikation das erlaubt.

Sorry, the WARP3 firmware release took a bit longer than expected. Please test the attached brickd package (you can install it with sudo dpkg -i brickd_2.4.5+snapshot~e70c9c6_arm64.deb ) I've rewritten the HAT specific code to use the GPIO's names (those will hopefully never change!) instead of their numbers. brickd_2.4.5+snapshot~e70c9c6_arm64.deb

Firmware: WARP3 2.3.0 Erstes Release Download: WARP3 2.3.0

Firmware: WARP 2.3.0 und WARP2 2.3.0 (nur WARP2) PV-Überschussladen hinzugefügt (nur WARP2) “Limitiere auf 4200 W (§14 EnWG) wenn geöffnet/geschlossen” als Konfiguration des Abschalteingangs hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.3) (nur WARP2) Konfiguration der angeschlossenen Phasen hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.3) Unterstützung von MQTTS und MQTT über WS(S) hinzugefügt HTTP-Automatisierungsbedingung hinzugefügt Modal für WLAN-Scan-Ergebnisse hinzugefügt SunSpec: Unterstützung mehrerer Geräte im selben Registersatz hinzugefügt SunSpec: Unterstützung mehrerer Instanzen des selben Models in einem Gerät hinzugefügt SunSpec: Boot-Scan-Robustheit verbessert SunSpec: Skalierung des Leistungsfaktors repariert WiFi Enterprise: EAP-TLS-Verbindungen mit Client-Key repariert (nur WARP2) Repariert, dass Netzwerkeinstellungs-Reset mit dem Front-Taster nicht die HTTP-Anmeldung deaktiviert hat (nur WARP2) DSZ15DZMOD-Unterstützung der veralteten Stromzähler-API repariert Automatische Kanalauswahl des WLAN-Access Points repariert Anzeige aktiver Phasen bei negativem Phasenstrom repariert (nur WARP2) OCPP-Crash repariert, der auftrat, wenn vor Firmware 2.2.1 OCPP nie verwendet wurde (nur WARP2) Latenz von Leistungs- und Phasenstromwerten des angeschlossenen Zählers verbessert Lastmanagement: Steuerzykluszeit auf 5 Sekunden reduziert Lastmanagement: Spielraum des Phasenstroms verdoppelt wenn exakt eine Wallbox lädt Modulname zu Ereignislog-Nachrichten hinzugefügt Menüstruktur des Webinterfaces überarbeitet Label/Inhaltsteilung auf Status- und Unterseiten vereinheitlicht Platzhalter eingefügt, wenn Zeit der Echtzeituhr nicht gestellt ist Anzeige deaktivierter Automatisierungsbedingungen und -aktionen hinzugefügt Download: WARP 2.3.0 bzw. WARP2 2.3.0

No, because Brick Daemon ignores the configured GPIO numbers if a HAT is detected.

It seems like kernel 6.6 changed the GPIO numbers again. https://github.com/raspberrypi/linux/issues/6037 We have to update Brick Daemon for the new GPIO numbers, probably next week.