rtrbt

Leider sind die ganzen Features noch nicht so gut integriert, wie sie sein könnten, aber du kannst folgendes versuchen: Hinterlege den Strompreis als Preiskalender (unter Energiemanagement -> dynamischer Strompreis) Aktiviere die Ladeplanung (unter Energiemanagement -> Eco-Modus) Mache die Wallbox zum Lastmanager, wenn du das nicht schon für's PV-Überschussladen getan hast (Der Eco-Modus funktioniert nur mit) (unter Energiemanagement -> Wallboxen) Konfiguriere den Ladeplan auf Täglich bis 05:00 lade 5 Stunden und aktiviere ihn (auf der Statusseite) Das führt dazu, dass, wenn die Wallbox im Eco-Lademodus ist, von 00:00 bis 05:00 geladen werden. Dann legst du dir dazu folgende Automatisierungsregeln an: Das sollte in Summe dazu führen, dass du normalerweise im Modus PV bist. Wenn du ein Auto ansteckst, dessen SoC unter 40% ist, dann wechselt die Wallbox nach Eco + PV (was wegen dem Ladeplan von 00:00 bis 05:00 schnell lädt, sonst nur mit PV-Strom) und setzt das Ladelimit auf 60%. Wenn das Ladelimit erreicht wird, oder du das Auto abziehst, dann wechselt der Modus wieder nach PV. Wenn ich gerade nichts übersehen habe, dann sollte das funktionieren :D

Hm, wenn der mDNS-Task sich zerlegt, dann versuch mal, ob das Problem verschwindet, wenn du mDNS (und EEBus, das funktioniert ohne mDNS nicht) ausschaltest. Die Implementierung im ESP-IDF ist leider nicht so robust wie man hoffen würde.

Ohne Integration in andere Features hast du davon erstmal nichts. Wenn die Wallbox den SoC kennt, dann kann sie ihn aber in die Ladeplanung mit einbeziehen, oder du könntest dir Automatisierungsregeln anlegen, die den Lademodus wechseln wenn der SoC unter einem Schwellwert ist o.Ä. Du meinst per Tesla-API, statt per ISO 15118? Zweiteres haben wir ja schon, das führt bei den Teslas nur zu dieser ~30 Minuten Zwangspause. SoC-Auslesen per Tesla-API wird höchstwahrscheinlich implementiert werden. Zu viele unserer Kunden haben Teslas, als dass wir das ignorieren könnten.

Genau. Das ist sozusagen die andere Seite des Problems: Es gibt zwei Varianten, wie die Wallbox mit dem Auto kommunizieren kann, die ältere Variante per IEC 61851 (im Endeffekt durch Widerstände und ein Rechtecksignal) und die neue Variante per ISO 15118 (im Endeffekt eine echte Netzwerkverbindung). Den SoC auszulesen funktioniert nur mit der ISO 15118. Wenn man das tut, führt das aber beim Tesla dazu, dass er nach dem Auslesen des SoCs einschläft und nicht (bzw. erst nach 30 Minuten) wieder geweckt werden kann. D.h. man hat im Moment die Option den SoC nicht auszulesen, dann kann der Ladevorgang jederzeit beginnen, wenn PV-Überschuss vorhanden ist, oder man nimmt die 30 Minuten Pause in Kauf, kann dann aber den SoC auslesen.

Bezogen auf deinen Plan ist der interessante Punkt dieser: Stand jetzt müsstest du das 80%-Limit im Tesla selbst einstellen. Bei anderen Autos, bei denen die Wallbox den SoC (=State of Charge, also wie voll der Akku ist) auslesen kann, müsste man in dem Szenario das 80%-Limit nicht im Auto einstellen, sondern die Wallbox könnte selbst bei (ungefähr) 80% aufhören zu laden.

Prinzipiell ja, wir sollten aber eigentlich das alte Verhalten nicht gebrochen haben. Es gibt seit 2.8.11 zusätzlich zum globalen Lademodus, der für alle kontrollierten Wallboxen gilt (den du über power_manager/charge_mode_update schreiben kannst, wie bisher) auch die Option, den Lademodus für einzelne Wallboxen zu überschreiben (über charge_manager/charge_modes_update, was leider noch nicht dokumentiert ist, sehe ich gerade). Wenn beides verwendet wird (das Webinterface benutzt die gleichen APIs), dann gewinnt der letzte Aufruf. Wenn du also global auf PV umschaltest, aber danach die einzelne Wallbox (bei kontrollierte Wallboxen) auf Min+PV umschaltest, lädt sie mit Min+PV, das sieht dann so aus: (deshalb ist der PV-Button auch wieder anklickbar) Wenn du charge_manager/charge_modes_update nicht per MQTT geschrieben hast, dann ist das ein Bug. Welchen MQTT-Broker benutzt du? und häng bitte auch einmal einen Debug-Report an, vielleicht fällt uns dann noch etwas auf.

Ich habe den Debug-Report in unser Plotting-Tool geworfen, das sieht auf jeden Fall spannend aus: Die blaue Kurve ist der PV-Überschuss, den die Wallbox glaubt am Netzanschluss zu sehen, die orange Kurve rechnet zusätzlich den Batteriespeicher mit ein. Da muss bei dir am 02.08. um ~ 19:13 bis 19:43 ein relativ starker, gepulster Verbraucher gelaufen sein, oder die Batteriesteuerung von FoxESS ist sehr interessant. Abgesehen davon hast du noch eine relativ alte Firmware (2.9.0) laufen. Aktualisier bitte einmal auf die Firmware, die ich angehangen habe, das ist 2.12.1 + ein noch nicht veröffentlichtes neues Feature: Wenn du das gleiche Problem mit der neueren Firmware reproduzieren kannst, zieh nochmal einen Debug-Report, dann sind auch der Live- und 48-Stunden-Verlaufsgraph aller konfigurierten Stromzähler enthalten. Dann sehen wir hoffentlich genauer, wo die Peaks entstehen. warp3_firmware-NIGHTLY_2_12_1_6a71b2ab_45eb8b7d60a1a1a__merged.bin

Hm, das kann ich hier nachstellen. Fixen wir mir der nächsten Firmware, sorry.

Möglicherweise hattest du dann einfach bisher immer PV-Überschuss, wenn du laden wolltest. Stell am besten den Standardlademodus auf "Unverändert", dann nimmt die Wallbox nach dem Neustart den Lademodus, den du davor auf der Statusseite ausgewählt hattest.

Ich vermute, dass du das Lastmanagement falsch konfiguriert hast: Du hast das dynamische Lastmanagement aktiviert (d.h. die Wallbox überwacht die Phasenströme am Netzanschluss), hast als ma­xi­ma­len Strom am Netz­an­schluss 16 A konfiguriert (das scheint mir sehr wenig zu sein) und als Strom­be­darf des größten Ein­zel­ver­brau­chers (damit ist nicht die Wallbox sondern der größte andere Verbraucher gemeint!) ebenfalls 16 A angegeben. Damit erlaubst du der Wallbox nur dann zu laden, wenn am Netzanschluss maximal 0,4 Ampere Bezug gemessen werden (in der Berechnung gehen noch 40% erlaubte Überlast ein, die wir in 30 Sekunden wegregeln können, deshalb die krumme Zahl). Im Endeffekt also nur wenn gerade PV-Überschuss da ist, egal welchen Lademodus du wählst.

In der Werkseinstellung funktioniert das genau so. Auto anstecken und los gehts. Das ist an sich egal, wenn die Ladebuchse näher bei der Wallbox ist, musst du natürlich weniger Kabel abwickeln.

Wenn 50five OCPP 1.6J unterstützt (wovon ich ausgehe, das ist die häufigste Variante vom Protokoll), spricht technisch nichts dagegen. Ich finde ad-hoc aber keine Dokumentation von 50five bzgl. OCPP. (Kurzer Rant) Erfahrungsgemäß sind OCPP-Backend-Betreiber etwas schwierig und erlauben oft nur Wallboxen, die auf einer "Kompatibilitätsliste" stehen, obwohl OCPP ein offenes Protokoll ist. Das ist ungefähr so, als ob eine Webseite nur bestimmte Handy-Hardware erlauben würde.

Ja, das würde dann vermutlich passieren. Tun wir, es wird immer genau ein Wert auf 0 geregelt: Wenn die Batterie bevorzugt wird, dann ist das der Wert des Grid-Zählers. D.h. wir verbrauchen nur den PV-Überschuss, den die Batterie nicht nimmt. Wenn die Batterie nicht bevorzugt wird, dann ist das Grid-Zähler - Batteriezähler. D.h. wir nehmen der Batterie den Strom weg, den wir als PV-Überschuss betrachten. Im Fall, dass der Batterieüberschuss sich dann nicht zum Grid verschiebt (weil der Wechselrichter am Limit ist), ist das kaputt. Die gute Nachricht ist: Ich hatte beim Schreiben dieses Posts eine Idee, wie wir das eventuell einfach reparieren können und damit auch den Fall der erzwungenen Batterieladung. Ich bin aber nicht der lokale Regelungstechnikexperte, also will ich nicht zu viel versprechen :D

Korrekt. Ist die Mail jetzt, da die Remoteverbindung wieder funktioniert, rausgegangen?

Da ist die Dokumentation leider schneller als die Firmware: Die MQTT-Discovery für den Energy Manager ist fast fertig™ und sollte es ins nächste oder spätestens übernächste Firmware-Release schaffen.

Der Text ist etwas knapp formuliert aber korrekt. Es geht konkret darum, dass die WARP3/WARP4 (nur Pro, weil wir dafür die Zählerwerte brauchen) automatisch auf einphasig umschaltet (also das L2/L3-Schütz abfallen lässt), wenn sie feststellt, dass das Auto nur einphasig lädt. Die Idee ist, dass das 1. bei unserem Lastmanagement hilft und 2. gerade im Sommer die Wärmeentwicklung in der Wallbox deutlich reduziert. EVCC kommt mit dem Feature nicht klar, weil es davon ausgeht, dass eine (beliebige) Wallbox nicht von sich aus umschaltet. Deshalb war es eine ganze Zeit lang so, dass man, damit EVCC funktioniert im Wallbox-Webinterface unter Wallbox -> Einstellungen den "Auto­ma­ti­schen Phasen­wechsel" deaktivieren musste. Im Zuge der Umstellung der EVCC-WARP-Anbindung von MQTT auf WebSockets (hier: https://github.com/evcc-io/evcc/pull/26970 ) wurde aber eingebaut, dass EVCC selbst diese Einstellung umschreibt, damit der Nutzer das nicht manuell machen muss.

Das ist genau das Problem: Dein Wechselrichter kann maximal 10 kW wechselrichten Dein Batteriespeicher ist DC-seitig am Wechselrichter angeschlossen. D.h. wenn der Wechselrichter (wie bei dir ab 12:28:30) in sein 10 kW-Limit läuft, dann geht der restliche DC-Strom (1,3 kW) in den Batteriespeicher Das PV-Überschussladen ist darauf konfiguriert, dass (wenn der Batterie-SoC > 50% ist) die Wallboxen zu bevorzugen sind, d.h. wir betrachten den Batteriebezug als Überschuss, den wir ins Auto bekommen wollen Dem Auto werden also 1,3 kW mehr erlaubt, als notwendig wäre um den Netzzähler auf 0 zu bekommen Der Wechselrichter kann diese 1,3 kW nicht liefern, weil er am Limit läuft -> Es werden 1,3 kW aus dem Netz gezogen Das ist also ein Modellierungsproblem bei uns: Damit das PV-Überschussladen mit dem Fall umgehen kann, müssten wir wissen, dass Die Batterie DC-seitig am WR angeschlossen ist und wenn das der Fall ist, dann müssen wir die Maximalleistung des Wechselrichters kennen Ich finde leider den Thread nicht mehr, in dem @MatzeTF schonmal darüber gestolpert ist (und er ist im wohlverdienten Urlaub). Eventuell gibt es da einen Hack, der dir hilft.

2026-07-18 19:23:43,402 | ethernet | Disconnected 2026-07-18 19:23:43,404 | ethernet | Was connected for 1296 seconds. 2026-07-18 19:23:47,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 19:23:47,915 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1 2026-07-18 19:27:49,403 | ethernet | Disconnected 2026-07-18 19:27:49,404 | ethernet | Was connected for 241 seconds. 2026-07-18 19:27:51,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 19:27:51,912 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1 2026-07-18 19:34:17,403 | ethernet | Disconnected 2026-07-18 19:34:17,404 | ethernet | Was connected for 385 seconds. 2026-07-18 19:34:19,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 19:34:19,911 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1 2026-07-18 19:45:49,403 | ethernet | Disconnected 2026-07-18 19:45:49,404 | ethernet | Was connected for 689 seconds. 2026-07-18 19:47:49,403 | ethernet | Lost IP address. 2026-07-18 19:49:49,404 | ethernet | Lost IP address. 2026-07-18 21:14:53,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 21:14:53,910 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1Im Log sehe ich, dass die LAN-Verbindung sehr oft verloren geht und dann (außer beim letzten Mal) nach zwei Sekunden wiederkommt. Kann es sein, dass eins der Kabel zwischen Fritzbox und Wallbox schlecht sitzt oder einfach defekt ist? Möglicherweise auch ein Switch o.Ä.?

Wenn du die Wallbox gerade erreichen kannst, lade mal einen Debug-Report (unter System->Ereignis-Log) herunter und hänge ihn hier an.

Hier gibt es übrigens eine Anleitung zum Einrichten und Schreiben eines API-Zählers: https://docs.warp-charger.com/de/docs/interfaces/mqtt_http/examples#api-z%C3%A4hler-f%C3%BCr-pv-%C3%BCberschuss

Bist du dir 100%ig sicher, dass das Kabel nicht abgezogen wurde? Ich sehe im Log nicht welchen Tag du meinst, aber z.B. am 08.07. wurde das Auto relativ oft abgezogen: 2026-06-23 15:53:10,205 | users | Charger state changed from 2 to 0 2026-06-25 17:59:47,424 | users | Charger state changed from 0 to 2 2026-06-26 10:03:07,881 | users | Charger state changed from 2 to 0 2026-07-02 13:39:34,867 | users | Charger state changed from 0 to 2 2026-07-02 15:23:54,013 | users | Charger state changed from 3 to 0 2026-07-02 17:01:57,961 | users | Charger state changed from 0 to 2 2026-07-02 18:02:24,027 | users | Charger state changed from 3 to 0 2026-07-04 08:58:43,785 | users | Charger state changed from 0 to 2 2026-07-04 12:23:09,982 | users | Charger state changed from 2 to 0 2026-07-04 19:57:12,178 | users | Charger state changed from 0 to 2 2026-07-06 07:48:51,083 | users | Charger state changed from 1 to 0 2026-07-07 10:19:50,162 | users | Charger state changed from 0 to 2 2026-07-07 11:38:27,598 | users | Charger state changed from 3 to 0 ---(Ab hier der 08.07)--- 2026-07-08 15:16:52,567 | users | Charger state changed from 0 to 2 2026-07-08 18:43:07,784 | users | Charger state changed from 3 to 0 2026-07-08 18:43:48,882 | users | Charger state changed from 0 to 1 2026-07-08 18:44:08,018 | users | Charger state changed from 3 to 0 2026-07-08 18:44:25,124 | users | Charger state changed from 0 to 1 2026-07-08 20:24:35,299 | users | Charger state changed from 3 to 0 2026-07-08 20:27:53,471 | users | Charger state changed from 0 to 2 2026-07-08 23:51:28,793 | users | Charger state changed from 1 to 0 2026-07-08 23:51:48,907 | users | Charger state changed from 0 to 2 2026-07-08 23:57:49,254 | users | Charger state changed from 1 to 0 2026-07-08 23:57:52,371 | users | Charger state changed from 0 to 1 2026-07-09 00:05:36,724 | users | Charger state changed from 1 to 0Edit: Charger-State 0 ist "kein Auto angesteckt" D.h. in dem Log-Ausschnitt sind alle Absteck (... to 0) und Ansteck (from 0...)-Vorgänge zu sehen

Firmware: WARP1 2.12.1, WARP2 2.12.1, WARP3 2.12.1, WARP4 2.12.2, WARP Energy Manager 2.8.1, WARP Energy Manager 2.0 1.7.1 (Nur WARP4) ISO 15118-Kompatibilität mit Hyundai Inster verbessert (Nur WARP4) Melden des iso_15118-Features für bessere Kompatibilität mit EVCC hinzugefügt (Nur WARP4) Lesen/Schreiben des ISO 15118-PIBs robuster gemacht (Nur WARP4) Behandlung der Übergänge zwischen ISO 15118 und IEC 61851 verbessert Berechnung fehlender Zählerwerte auf ein- und zweiphasige Stromzähler erweitert CPU-Idling hinzugefügt um Leistungsaufnahme um 3 bis 10% zu reduzieren (Nur WARP2, WARP3, WARP4, WARP Energy Manager, WARP Energy Manager 2.0) Maximale Zertifikat(sketten)-größe auf 10179 Bytes erhöht (Nur WARP1) Maximale Zertifikat(sketten)-größe auf 4352 Bytes erhöht (Nur WARP2, WARP3, WARP4, WARP Energy Manager, WARP Energy Manager 2.0) "Zuletzt gesehen"-Wert von nicht-lokal gesehenen NFC-Tags repariert (Nur WARP2, WARP3, WARP4, WARP Energy Manager, WARP Energy Manager 2.0) Sichergestellt, dass Löschen eines Benutzers auch dessen NFC-Tags löscht Umbenennen des unbekannten Benutzers repariert (Nur WARP2, WARP3, WARP4) Behoben, dass Trennen der OCPP-Verbindung manchmal für immer blockierte (Nur WARP1, WARP2, WARP3, WARP4) Ladelog-Filter "kontrollierte Wallboxen" repariert "Fernzugriff schließen" für kommende iOS-App 2.0.0 repariert (Nur WARP4) Fahrzeugweckruf in Kombination mit ISO 15118 repariert (durch Update auf Ladecontroller-Firmware 2.2.24) Download: WARP1 2.12.1 bzw. WARP2 2.12.1 bzw. WARP3 2.12.1 bzw. WARP4 2.12.2 bzw. WARP Energy Manager 2.8.1 bzw. WARP Energy Manager 2.0 1.7.1

Musst du auch nicht. Eigentlich solltest du auf weatherpi/callback/outdoor_weather_bricklet/SEM/station_data bzw. /sensor_data die Daten bekommen. Wenn ich mich richtig erinnere bekommst du aber nur ein Paket alle 45 Sekunden, öfter schicken die Sensoren/Stationen nicht. Laut Log wurde um 13:55:40,153 einmal station_data ge-publisht, d.h. das funktioniert soweit. Du musst dich erst auf weatherpi/response/outdoor_weather_bricklet/SEM/get_station_identifiers subscriben, damit du die Antwort nicht verpasst und dann auf weatherpi/request/outdoor_weather_bricklet/SEM/get_station_identifiers eine leere Nachricht publishen. Im Endeffekt das gleiche Vorgehen wie in folgendem Beispiel get_color: https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html#requests-und-responses

Firmware: ESP32 Brick 2.2.0, ESP32 Ethernet Brick 2.2.0 Unterstützung von TLS 1.3 hinzugefügt Hinzugefügt, dass die meisten Konfigurationen ohne Neustart geändert werden können Statusinformationen zu vielen Unterseiten hinzugefügt Status-Widget hinzugefügt Dark Mode zum Webinterface hinzugefügt Logo auf kleinen Bildschirmen zentriert Gerätesuche-Dialoge vereinheitlicht Sichergestellt, dass bei Neustart über die System-Unterseite auch alle Bricklets neugestartet werden Hinzugefügt, dass Teile einer API mit einem URL-Suffix gelesen und geschrieben werden können WLAN-Verbindungsaufbau beschleunigt WLAN-Netzwerksuche beschleunigt (Nur ESP32 Brick) Anzeige der MAC-Addresse und BSSIDs zu den WLAN-Unterseiten hinzugefügt (Nur ESP32 Ethernet Brick) Anzeige der MAC-Addresse und BSSIDs zu den Ethernet- und WLAN-Unterseiten hinzugefügt Behoben, dass automatische Kanalwahl des WLAN-Access Points den ersten WLAN-Verbindungsversuch gestört hat Hostnamen- und IP-Adress-Validierung verbessert Erkennung von Netzwerkadress-Fehlkonfigurationen erweitert Sichergestellt, dass Netzwerkschnittstellen nicht aus Versehen deaktiviert werden können Robustheit von WireGuard verbessert Sichergestellt, dass Debug-Report niemals WireGuard-Keys enthält Schlüsselgenerierung zur WireGuard-Unterseite hinzugefügt WireGuard-MTU konfigurierbar gemacht Crashes, die durch (neu-)verbinden von WireGuard verursacht wurden, behoben Robustheit von Webserver und Web Sockets gegen Verbindungsabbrüche verbessert Crash repariert, der auftrat, wenn während eines Neustarts ein weiterer HTTP-Request empfangen wurde Login-Dialog für Firefox und Chrome auf iOS repariert Fortschrittsanzeige des Firmware-Updates verbessert Sichergestellt, dass ein nicht funktionaler Web Server zu einem Rollback auf die letzte Firmware führt Bei unerwarteten Neustarts wird eine Warnung angezeigt Warnung hinzugefügt, falls sich Webinterface- und Browser-Sprache unterscheiden Absturz in der allgemeinen Konfigurationsbehandlung behoben mDNS-Spam behoben (Nur ESP32 Ethernet Brick) Ethernet-Initialisierung beschleunigt (Nur ESP32 Ethernet Brick) Sichergestellt, dass LAN-Verbindung immer vor WLAN-Verbindung bevorzugt wird (Nur ESP32 Ethernet Brick) Priorisierung der Netzwerk-Interfaces repariert Übersetzungen verbessert Zeitzonen-Datenbank aktualisiert Download: ESP32 Brick bzw. ESP32 Ethernet Brick

Firmware: WARP4 2.12.1 Seltenes Problem der Firmware-Aktualisierung behoben Download: WARP4 2.12.1