rtrbt

Statt dass du mit einer Automatisierung die MQTT-Nachricht schickst, kannst du evse/button_state verwenden. Wenn du da prüfst, ob sich die "button_release_time" geändert hat, sollte es deutlich unwahrscheinlicher sein, dass du einen Knopfdruck verpasst.

Unabhängig von App vs Browser (dass die App Links immer im Browser öffnet ist ein bekanntes Problem, das werden wir irgendwie angehen): Wenn du auf der WARP4 den Lademodus änderst, dann sollte sich der angezeigte Lademodus für diese Wallbox unter kontrollierte Wallboxen ändern. Dieses Überschreiben des Lademodus gilt aber nur für den aktuellen oder nächsten Ladevorgang.

Der Lademodus aller kontrollierten Wallboxen (das ist bei dir nur die eine, skaliert aber auch auf größere Ladeparks) bleibt gleich, wird aber anklickbar. Wenn ich z.B. bei wallbox-cp1 auf PV klicke passiert folgendes

vorher (Lademodus aller Wallboxen auf Eco + PV):

nachher (cp1 im PV-Modus -> gewählter Lademodus aller Wallboxen bleibt Eco+PV, ist jetzt aber klickbar um cp1 wieder nach Eco+PV bekommen zu können):

Die ganze Ladeparksteuerung ist im Moment etwas unübersichtlich, das ist bekannt, und das werden wir mittelfristig angehen.

Wenn sich das ganze bei dir so verhält wie oben beschrieben, dann ist alles gut™. Wenn nicht, triffst du eventuell einen Bug.

Es sieht im Moment so aus, als ob sich Wallbox und Auto über ISO 15118 nicht einig worden, nach dem Neustart ging es aber. Kannst du zusätzlich noch einen Debug-Report anhängen (den kannst du unter System -> Ereignis-Log ziehen)? Genau der Protokoll-Teil, der hilfreich wäre ist leider im Ladeprotokoll nicht enthalten. Dann haben wir ein Log von der erfolgreichen Aushandlung.

Danach müsstest du das Problem noch einmal erzeugen und dann noch einen Debug-Report ziehen, dann können wir vergleichen.

On 9/1/2026 at 3:41 PM, paulipaul said:

Oder habe ich die Option falsch verstanden?

Nein hast du nicht, der unveränderte Lademodus ist in Firmware 2.12.2 leider kaputt. Mit der nächsten Firmware (die voraussichtlich noch diese Woche erscheint), wird das gefixt.

Dreh mal den Schukostecker. Wenn L und N vertauscht sind funktioniert der PE-Check nicht richtig. Funfact: Wir haben bei den Testkisten, die wir intern benutzen, eine Lampe eingebaut, die leuchtet, wenn man den Stecker gedreht hat. Das passiert doch öfter als man bei einer 50:50 Chance glauben würde.

Wenn du Filterregeln der Form "wenn Dienst X vorhanden, lass alles von diesem Gerät durch" bauen kannst, dann häng dich auf _tf-warp-cm._udp

Das ist der Dienst für die Auto-Discovery von Wallboxen, die unser Lastmanagementprotokoll sprechen können

Ja, das läuft über mDNS. Das sollte einfach der _http._tcp Service sein. Ein Beispiel von der Wallbox auf meinem Tisch:

Kann es sein, dass irgendetwas den Ladevorgang per MQTT unterbricht? (einfachster Test: schalte MQTT auf der Wallbox aus und versuche dann zu laden) Ich sehe im Ladeprotokoll, dass die Wallbox über die Ladestromgrenze der manuellen Freigabe blockiert wird, das kann auch per API ausgelöst werden. Gerade bei der schlechten WLAN-Verbindung, die andauernd abreißt, könnte ich mir vorstellen, dass deshalb irgendeine steuernde Software verwirrt ist und per MQTT stoppt.

Das war ein Bug, sorry. Der Fix: https://github.com/Tinkerforge/esp32-firmware/commit/bef2b2e0d853fc35b161c8ffb0e40de48ebdcf74 wird mit der nächsten Firmware veröffentlicht.

Auch für die Nachwelt: Das Webinterface benutzt die selben APIs, die du auch benutzen kannst. D.h. du kannst über den Browser-Inspektor immer nachsehen, was das Webinterface aufruft. (Es gibt aber ein paar undokumentierte APIs, die das Webinterface braucht. Was nicht dokumentiert ist können wir jederzeit brechen)

On 8/17/2026 at 11:10 PM, pvbastla said:

Bin ich zu blöd ;-)

Nein, aber ich, sorry :D

On 8/17/2026 at 11:10 PM, pvbastla said:

Oder habt ihr da eine andere Version?

Ja, stellt sich raus, ich habe dir Funktionen empfohlen, die wir noch nicht veröffentlicht haben. Mit dem nächsten Firmware-Release (voraussichtlich noch im August) wird das so funktionieren, wie ich's beschrieben hatte. (und Vehicle wird dann auch Fahrzeug heißen)

Kannst du die Gerätesuche nochmal ausführen und danach einen Debug-Report ziehen? Im Report stehen möglicherweise relevante Details.

On 8/12/2026 at 2:33 PM, matthias said:

BTW: Die Warp entriegelt auch, wenn sie nicht mit EVCC verbunden ist. Das Verhalten tritt halt nur auf, wenn die Warp über EVCC lädt und gesteuert wird.

Im Idealfall ziehst du von beiden Varianten (also mit EVCC und ohne) jeweils ein Ladeprotokoll (unter Wallbox -> Ladestatus) von einem kompletten Ladevorgang. Also

• Protokoll starten

• Auto anstecken

• eine Minute laden lassen

• Knopf drücken

• warten bis das Kabel entriegelt (oder eben nicht)

• Protokoll stoppen

Da müsste es dann ja einen Unterschied geben, den wir hoffentlich in den Protokollen sehen.

On 8/6/2026 at 5:29 PM, pvbastla said:

Ist denn eine "Erweiterung" der Automatisierungen mittelfristig geplant, dass man da etwas flexibler werden kann, oder wird das für euch oder andere Kunden zu kompliziert?

Mittel- bis langfristig haben wir Pläne. Ob das dann eine Erweiterung der Automatisierungsregeln wird oder ob wir z.B. eine Scriptsprache wie MicroPython oder Berry einbetten ist aber noch unklar.

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.

On 8/4/2026 at 4:07 PM, harterch said:

Welche Vorteile hat würde mir ein funktionierendes Auslesen des SoC bieten?

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.Ä.

On 8/4/2026 at 4:07 PM, harterch said:

Ist geplant, das Auslesen des SoCs noch zu implementieren?

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.

On 8/4/2026 at 2:34 PM, harterch said:

Das bedeutet de facto hab ich keine Einschränkungen, wenn ich die 80% sowieso im Tesla einstelle und dieser dann den Ladevorgang unterbricht?

Genau.

On 8/4/2026 at 2:34 PM, harterch said:

Und was hat es mit dem Titel des Threads "PV-Laden startet nicht automatisch bei Tesla" auf sich? Ich stecke an und es beginnt nicht zu laden?

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:

On 8/4/2026 at 1:49 PM, harterch said:

sollen dann geladen werden, bis die 80% Ladelimit erreicht sind.

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.

On 8/2/2026 at 5:53 PM, wolle said:

Bevor es ans Debugging geht: hat sich zwischen Version 2.8 und 2.12 etwas an dem Steuerungskonzept für den Lademodus geändert?

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.

On 7/28/2026 at 2:05 PM, msi said:

Bei 63A fliegt die Hauptsicherung raus, dann nehme ich das mal.

...und es funktioniert, das Auto lädt. Problem scheint gelöst!

Möglicherweise hattest du dann einfach bisher immer PV-Überschuss, wenn du laden wolltest.

On 7/28/2026 at 2:05 PM, msi said:

Kann man das der Warp3 irgendwie beibiegen, bei "Min+PV" zu bleiben?

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.

On 7/20/2026 at 11:57 AM, autolader said:

Muss man an der Warp4 eine Taste drücken, damit der Ladevorgang startet oder reicht das Einstecken des Ladekabels und dann wird mit einem Standard-Ladeprogramm begonnen? Ich brauche keine Auto- oder Personenidentifizierung, ich bin der alleinige Nutzer der Wallbox, von Ausnahmen (Besuchern) die kostenlos laden dürfen mal abgesehen.

In der Werkseinstellung funktioniert das genau so. Auto anstecken und los gehts.

On 7/20/2026 at 11:57 AM, autolader said:

Gibt es eine Empfehlung für die Position der Wallbox/Warp4 relativ zur Ladebuchse am Auto? Also in der Form: X Meter vor/hinter der Ladebuchse

Das ist an sich egal, wenn die Ladebuchse näher bei der Wallbox ist, musst du natürlich weniger Kabel abwickeln.