rtrbt

Firmware: WARP2 2.8.10, WARP3 2.8.10

• Weiteres Problen behoben, durch dass eine CP-Trennung manchmal dazu führte, dass das Fahrzeug als getrennt betrachtet wurde (durch Update auf Ladecontroller-Firmware 2.2.16)

Download: WARP2 2.8.10 bzw. WARP3 2.8.10

Firmware: WARP1 2.8.9, WARP2 2.8.9, WARP3 2.8.9, WARP Energy Manager 2.4.9, WARP Energy Manager 2.0 1.3.9

• Hinzugefügt, dass Teile einer API mit einem URL- oder Topic-Suffix gelesen (nur über HTTP) und geschrieben (HTTP und MQTT) werden können
• Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: VARTA Element/Flex Batteriespeicher, Chisage ESS Hybrid-Wechselrichter
• SunSpec: Falsche Phase-zu-Phase-Spannungswerte für WattNode-Stromzähler erneut korrigiert
• Fortschrittsanzeige des Firmware-Updates verbessert
• Behoben, dass lastgemanagte Wallboxen nach 49 Tagen fälschlicherweise als "gestört" angezeigt wurden
• (Nur WARP1, WARP2, WARP3) Behoben, dass Fronttaster-LED-Steuerung per API nicht immer akzeptiert wurde, wenn der letzte Steuerbefehl auch über die API erhalten wurde
• (Nur WARP2, WARP3) Behoben, dass eine CP-Trennung manchmal dazu führte, dass das Fahrzeug als getrennt betrachtet wurde (durch Update auf Ladecontroller-Firmware 2.2.15)
• (Nur WARP2, WARP3) Unnötig lange Wartezeit nach Ende der CP-Trennung behoben (durch Update auf Ladecontroller-Firmware 2.2.15)
• (Nur WARP2, WARP3) Unterstützung für Eltako DSZ16DZE hinzugefügt

Download: WARP1 2.8.9 bzw. WARP2 2.8.9 bzw. WARP3 2.8.9 bzw. WARP Energy Manager 2.4.9 bzw. WARP Energy Manager 2.0 1.3.9

Als letzten Akt der Verzweiflung kann ich dir noch vorschlagen, dass du die LAN-(nicht WLAN-)Schnittstelle komplett deaktivierst. Laut Debug-Report hast du kein Kabel angeschlossen, aber die Initialisierungsreihenfolge der Schnittstellen ist interessant:

2025-08-30 07:12:59,651 | wifi             | Connected to 'Ironangel', b+g+n ch.6 HT20 WPS [DEI] -68dBm, BSSID 60:B5:8D:57:67:80
2025-08-30 07:12:59,663 | wifi             | Got IP address: 192.168.1.4/24. Own MAC address: 58:BF:25:B8:59:E4
2025-08-30 07:13:00,114 | ethernet         | Started
2025-08-30 07:13:00,392 | network          | Network connected (WiFi)

Ich habe das Timing hier nachgestellt und es hat dein Problem nicht verursacht, aber eventuell ist dein Setup so speziell, dass das trotzdem hilft.

Ja, die EVCC-Einrichtungsdoku ist ziemlich veraltet, müssen wir mal angehen.

Kannst du nochmal über den Fernzugriff einen Debug-Report ziehen?

Das klingt nach einem Problem mit den DHCP-Leases, aber laut Log hat die Wallbox die per DHCP zugeteilte IP nie verloren; seltsam. Aber hauptsache es funktioniert jetzt.

Gut dass du das herausgefunden hast, das hätte ich nicht aus der Ferne diagnostizieren wollen :D

On 8/27/2025 at 9:40 AM, Ironangel said:

Die IP ist immer die gleiche. 

Die 192.168.1.98?

Kurze Bestandsaufnahme:

• Du konntest mit http://192.168.1.98 auf die Wallbox zugreifen, bevor du den Fernzugriff/die App eingerichtet hast
• Die Wallbox kann sich zum Fernzugriffs-Server verbinden
• Die Wallbox kann deinen Shelly im lokalen Netz erreichen
• Du kannst weder vom Smartphone noch vom PC aus (die beide im gleichen lokalen Netz sind wie vorher) die Wallbox erreichen
• Die Netzwerkeinstellungen usw. auf der Wallbox sind wie ich sie erwarten würde (keine IP-Adresskonflikte, der Webserver-Port ist nicht verstellt usw.)

-> Das ist kein prinzipielles Netzwerkproblem der Wallbox, irgendetwas muss subtiler kaputt sein.

Um das weiter einzugrenzen:

• Kannst du die Wallbox-IP anpingen und bekommst Antworten?
• Wenn ja: Bekommst du eine Antwort wenn du z.B. auf http://192.168.1.98/info/version zugreifst? Müsste ungefähr so aussehen:

  {"firmware":"2.8.8+68935ab2","config":"2.8.4","config_type":"warp"}

• Wenn das auch geht: Kannst du auf die Recovery-Seite unter http://192.168.1.98/recovery zugreifen?

• Erreichst du mit dem gleichen PC/Smartphone das Webinterface von deinem Shelly?

Das muss sich @ffreddow nach seinem Urlaub mal ansehen. Eigentlich sollte es keinen Zusammenhang zwischen dem Fernzugriff und Modbus TCP geben, ich könnte nur wild spekulieren, dass der ioBroker Modbus-Adapter irgendwie die Wallbox überlastet und sie deshalb die Fernzugriffskommunikation nicht mehr schafft.

Die RS485-Kommunikation macht das https://github.com/Tinkerforge/warp-energy-manager-v2-bricklet und ist hier https://github.com/Tinkerforge/bricklib2/tree/master/warp implementiert (das ist nicht im Repo des Bricklets, weil die Implementierung die gleiche ist wie die vom EVSE >= 2.0 und WEM 1). Der ESP bekommt dann über die API des Bricklets die Zählerwerte.

D.h. du müsstest dir die Bricklet-Firmware so umbauen, dass du entweder beliebige Daten vom ESP aus anfragen kannst (lass dich vom https://github.com/Tinkerforge/rs485-bricklet inspirieren, meines Wissens ist die Implementierung in der Bricklib ein spezialisierter Fork davon) oder du implementierst den zweiten Zähler spezifisch in der Bricklet-Firmware und schickst die Werte von beiden Zählern.

Das ESP-Ende der Kommunikation ist das meters_em-Modul: https://github.com/Tinkerforge/esp32-firmware/tree/master/software/src/modules/meters_em

Noch ein allgemeiner Gedanke: Der SDM630 hat ziemlich viele Werte die wir lesen, wenn du dazu noch einen zweiten Zähler liest, solltest du mal nachsehen, ob du die Baudrate des ganzen Systems hochdrehen kannst, sonst wird die Aktualisierungsrate vermutlich relativ schlecht. Der SDM630 kann anscheinend bis zu 38400 Baud.

Als Alternative zur Bricklet-Firmware-Hackerei könntest du dir in den WEM2 noch ein RS485 Bricklet reinwerfen (man muss ja auch was verkaufen :P ) und dann das gute alte Meters RS485 Bricklet-Modul aus WARP1-Zeiten verwenden. Das hat den Vorteil, dass du dann beide Zähler parallel auslesen kannst, musst das aber getrennt verkabeln.

Im Log springt uns nichts auffälliges an.

Wie versuchst du auf die Wallbox zu kommen, mit dem Hostnamen? Funktioniert es wenn du per http://192.168.1.98 (laut dem Debug-Report, die IP kann eine andere sein wenn du die Wallbox neugestartet hast o.Ä.)  oder per http://dein-hostname.localdomain auf die Wallbox gehst? (Alternativ nur mit dem Hostnamen wenn du normalerweise die IP benutzt) Kannst du mit deinem PC die Wallbox anpingen?

War auch mein erster Gedanke, funktioniert aber nicht immer: Das dynamische Lastmanagement arbeitet pro Phase, das gewünschte Limit ist aber phasenübergreifend.

Wenn ich aber gerade darüber nachdenke: Ist dein Limit wirklich ungefähr im Bereich < 5 kW? Dann ergibt es ja kaum Sinn die Wallbox dreiphasig laufen zu lassen (Minimalstrom sind immer 6 A, d.h. bei drei Phasen 230 V * 3 Phasen * 6 A = 4140 W). Wenn du die Wallbox nur einphasig anschließt und die Phasenrotation konfigurierst, dann könntest du in der Tat das dynamische Lastmanagment benutzen.

Hat dein Browser dir ein https:// eingefügt? Manche Browser machen das gerne wenn sie eine Seite aus anderen Gründen (z.b. weil man gerade nicht im WLAN war) erreichen können. Wenn ja, lösche mal das s vor dem Doppelpunkt.

Nur zum Verständnis der Daten: Zumindest in den letzten zwei Diagrammen und auch in den Debug-Reports dazu sind das jeweils zwei Peaks zwischen denen der Zählerwert ganz kurz wieder auf den "erwarteten" Wert geht. Hast du zwei Strings an deinem Wechselrichter angeschlossen? Dann sehen wir da vermutlich, dass der  ShadeFix erst den einen String und dann den anderen String testet.

Das ist tendenziell eine Frage für @MatzeTF, er ist aber noch im Urlaub. Wir melden uns nächste Woche noch einmal.

Hm ich fürchte, dass muss sich @MatzeTF mal detailliert ansehen, der ist aber noch im Urlaub. Er wird sich melden.

Das ist ein bekanntes Problem, für das wir im Moment leider keine Lösung haben: https://github.com/Tinkerforge/esp32-firmware/issues/342 Irgendwie implementiert Safari auf iOS die Digest Authentication nicht richtig. (das betrifft dann auch alle anderen Browser weil Apple der Meinung ist, keine anderen Browser-Engines zuzulassen) Langfristig wollen wir auf eine andere Variante des Logins umsteigen, aber es ist noch niemand dazu gekommen, das zu implementieren.

Wir hatten das gleiche Problem in der Tat schon mal: https://github.com/Tinkerforge/esp32-firmware/issues/338 und hatten dann die erlaubte Headergröße auf 1536 und später anscheinend auf 2047 Byte erhöht. Kannst du nachsehen, wie groß die Header sind, wenn du die Cloudflare-Auth aktiviert hast?

Laut der PDF gibt es das Register 1080 "Battery management mode" mit den möglichen Werten (Note 4 auf der nächsten Seite):

4 Battery management modes
0x00 No external battery management
0x01 External battery management via digital I/O
0x02 External battery management via MODBUS protocol

Das Register ist read-only, also muss es irgendeinen anderen Weg als Modbus geben, wie du das aktivieren kannst. Du kannst aber z.B. mit GModbus das Register lesen. Wenn das schon auf 2 steht, hast du ein anderes Problem.

On 7/30/2025 at 12:40 PM, eweri said:

Jetzt habe ich mich nicht mit dem MQTT-Protokoll beschäftigt. Ist es vorgesehen, dass eine Meldung gesendet wird, wenn der Stecker gezogen wird?

Die Wallbox schickt sofort wenn sie merkt, dass der Stecker gezogen ist eine MQTT-Nachricht. Sofort heißt in dem Fall nach spätestens einer Sekunde, es sei denn du hast das MQTT-Sende-Intervall versetellt.

Wenn du das Problem nochmal erzeugen kannst, zieh bitte mal sowohl einen Debug-Report von der Wallbox, als auch das EVCC-Log. Dann sehen wir vielleicht mehr.

Hm, weil bei dir die 32 A einphasig voll ausgefahren werden, kommt die Umschaltung auf dreiphasig in der Tat erst sehr spät: Das PV-Überschussladen versucht Schaltvorgänge zu minimieren, deshalb bleibt es möglichst lange einphasig. Weil bei dir die 32 A einphasig voll ausgenutzt werden, muss die Wallbox 4 Minuten lang (das ist die Wolkenfilterzeit wenn der Filter auf mittel steht) mehr als 32 A * 230 V = 7360 W sehen, damit sie umschaltet.

Die Idee dahinter ist, dass wenn wir auf dreiphasig umschalten und dann der Überschuss fällt, wir spätestens bei 4140 W wieder auf einphasig schalten müssten (weil 6 A der Minimalstrom ist, den man dem Auto vorgeben kann -> 6 A * 3 Phasen * 230 V = 4140 W), oder Strom aus dem Netz beziehen.

Sobald wir die Schieflastvermeidung umgesetzt haben, wird das aber vermutlich so passieren, wir werden dann einphasig ja nur noch maximal 4600 W (20 A * 230 V) los und müssten dann auf dreiphasig wechseln.

On 7/29/2025 at 10:01 AM, MichiLo said:

Ich habe nun das Problem, das die Umschaltung zwischen 1-phasig und 3-phasig erst sehr spät erfolgt.

Prinzipiell muss mehrere Minuten lang genug Überschuss für den dreiphasigen Betrieb verfügbar sein (das ist Teil des Wolkenfilters), damit umgeschaltet wird. Das kann unintuitiv spät sein (ich arbeite gerade daran, dass das Lastmanagement/PV-Überschussladen sich im Webinterface mehr erklärt).

Zieh im Zweifel mal einen Debug-Report, damit kann ich ~ eine Stunde in die Vergangenheit die Entscheidungen des PV-Überschussladens nachvollziehen.

On 7/29/2025 at 10:01 AM, MichiLo said:

Bei schwankendem Wetter ein tolles Feature bis 7kW 1-phasig PV-Überschuss-Laden zu können. Das sprengt natürlich jetzt die Schieflast im Privathaushalt. Gibt es irgendwo eine Option 1-phasig Max 16A, 3-phasig max 32A einzustellen?

Das ist prinzipiell geplant, gibt es aber noch nicht. Habe mal ein Issue dafür angelegt. https://github.com/Tinkerforge/esp32-firmware/issues/424

On 7/27/2025 at 5:44 PM, Jkw said:

Ich habe mir doch noch die Firmware durchgelesen. Vermutlich würde es reichen 

Quote

#define CHARGING_SLOT_OCPP 11

Auf 6 zu ändern oder? Dann würde sowohl NFC wie auch OCPP jeweils den gleichen slot freischalten. Ist schon sehr hacky vermutlich tut's aber, meinste du nicht auch?

Ganz so einfach ist das leider nicht: Wenn OCPP nicht freigibt, wird der maximale Ladestrom mehrfach pro Sekunde auf 0 mA geschrieben:https://github.com/Tinkerforge/tfocpp/blob/8f315f5ea976e00a3f177a983b62871ad4f8e200/src/ocpp/Connector.cpp#L66

Ohne dass ich das jetzt genau durchdacht habe müsstest du zusätzlich zumindest noch hier: https://github.com/Tinkerforge/esp32-firmware/blob/19ec67bc6b041a01d6a573fb1f3bb8c5bdb968e0/software/src/modules/ocpp/ESP32Platform.cpp#L672 mittracken, ob der letzte Übergang von 0 mA nach >= 6000mA durch OCPP verursacht wurde (wenn nicht, dann war es wohl NFC) und nur wenn das der Fall ist, erlaubst du OCPP wieder 0 mA zu schreiben um den Ladevorgang zu stoppen, sonst ignorierst du das. Ggfalls musst du noch mehr Hacks einbauen, damit das immer funktioniert.

On 7/24/2025 at 2:39 PM, MichiLo said:

Ich schätze weil das Auto nur mit 16A lädt und die Differenz zum Zähler nicht kleiner wird.

Genau. Wenn du eine Wallbox mit Zähler hättest, könnte das PV-Überschussladen jetzt sehen, dass dein Auto nur 16 A zieht und würde sich dann einpendeln. Ohne Zähler pendelt es sich dann bei den 32 A ein.

Edit: 32 A zeigen wir immer einfach als "freigegeben" an, eben weil das das größte Limit ist, dass die Wallbox kennt. Das ist zum Beispiel bei den Ladeslots praktisch, die nur entweder "freigegeben" (= 32 A) oder "blockiert" (= 0 A A) sind.

Der maximale Gesamt­strom für das Lastmanagement (unter Energiemanagement -> Wallboxen) ist auf 16 A konfiguriert, das sorgt dafür, dass das Lastmanagement nie mehr als 16 A verteilt. Wenn die Zuleitung zur Wallbox das erlaubt (wovon ich ausgehen würde, sonst hätte dein Elektriker die Schiebeschalter in der Wallbox falsch eingestellt), solltest du den maximalen Gesamtstrom auf 32 A erhöhen können.