rtrbt

On 11/6/2025 at 1:00 PM, ludwig said:

Die Firmware bekomme ich über die Aktualisierungssuche oder stellst Du sie hier im Forum bereit?

Die bekommst du über die Suche oder hier: https://www.warp-charger.com/downloads/

Ein EVSE-Ladeprotokoll brauchen wir nicht, da fehlen die relevanten Infos, die im Debug-Report (auch wenn du den erst bis zu eine Stunde später ziehst) enthalten sind. 

Ich habe gerade eine neue Firmware mit dem Bugfix veröffentlicht.

@ludwig Kannst du einmal nachsehen, ob es bei dir immer noch kaputt ist und wenn ja einen Debug-Report herunterladen (unter System -> Ereignislog) und hier posten?

Firmware: WARP1 2.8.12, WARP2 2.8.13, WARP3 2.8.13, WARP Energy Manager 2.4.11, WARP Energy Manager 2.0 1.3.11

• Falsche Lastmanagement-Allokationen behoben, die auftraten, wenn Phasenrotation nicht konfiguriert war
• Safari-Bug umgangen, der Firmware-Updates über den Fernzugriff gebrochen hat

Download: WARP1 2.8.12 bzw. WARP2 2.8.13 bzw. WARP3 2.8.13 bzw. WARP Energy Manager 2.4.11 bzw. WARP Energy Manager 2.0 1.3.11

Firmware: WARP1 2.8.11, WARP2 2.8.12, WARP3 2.8.12

• Sprach-spezifischen Dezimaltrenner in CSV-Ladelog repariert
• Behoben, dass die veraltete object_id auf Home Assistant-MQTT-Discovery-Topics geschickt wurde
• (Nur WARP2, WARP3) Wartezeit beim Phasenwechsel auf 60 Sekunden erhöht, um mit langsam schaltenden Fahrzeugen kompatibel zu sein (durch Update auf Ladecontroller-Firmware 2.2.18)

Download: WARP1 2.8.11 bzw. WARP2 2.8.12 bzw. WARP3 2.8.12

Wir fragen die Preise direkt von ENTSO-E ab, nicht über die Tibber-API

"Grundfunktionen" heißt alles passiert lokal auf deinem Gerät, außer

• Die Abfrage der Strompreise (die wir technisch gesehen nicht an Dritte weitergeben dürfen, außerhalb von "unserem" System) Wir können aber nicht verhindern, dass du mit deinem Browser auf api.warp-charger.com gehst, oder https://github.com/Tinkerforge/api.warp-charger.com auf einem Rechner deiner Wahl laufen lässt und bei deiner Wallbox/deinem WEM unter http://[dein_host]/day_ahead_prices/config die URL anpasst
• Die Abfrage der PV-Vorhersage: Da benutzen wir https://forecast.solar/ (wird nicht von uns betrieben). Du kannst da genauso unter http://[dein_host]/solar_forecast/config die URL anpassen
• Der Fernzugriff: Den hosten wir selbst auf my.warp-charger.com. Das ist im Endeffekt ein VPN (mit WireGuard im Browser!) + eine Schlüsselverwaltung dazu, bei der alles mit deinen Zugangsdaten (bzw. daraus abgeleiteten Keys) verschlüsselt wird, damit wir als Serverbetreiber nicht deinen Traffic sehen können. Darfst du auch gerne selbst hosten: https://github.com/Tinkerforge/esp32-remote-access (in dem Fall kannst du die Server-URL sogar im Webinterface unter System->Fernzugriff in den Experten-Einstellungen ändern)

Alles davon ist Opt-In, nichts sammelt deine Daten.

On 11/4/2025 at 7:06 AM, wuesten_fuchs said:

Ich nehme an, das ist ein Versehen und wird wieder korrigiert?

Korrekt. Das ist bei der Verschiebung des CSV-Exports vom Webinterface auf den Mikrocontroller kaputt gegangen. Fix kommt diese Woche noch.

Firmware ist veröffentlicht, der Fix hat es aber nicht ins Changelog geschafft. Sollte jetzt trotzdem funktionieren.

Firmware: WARP1 2.8.10, WARP2 2.8.11, WARP3 2.8.11, WARP Energy Manager 2.4.10, WARP Energy Manager 2.0 1.3.10

• (Nur WARP2, WARP3) Monatlichen E-Mail-Versand des Ladelogs über den Fernzugriff hinzugefügt
• (Nur WARP2, WARP3) Unterstützung der Phasenumschaltung über OCPP hinzugefügt
• Lastmanagement-Statusseite überarbeitet
• Informationen über Lastmanagement-Entscheidungen hinzugefügt
• Hinzugefügt, dass Lademodus für einzelne Wallbox pro Ladevorgang überschreibbar ist
• Hinzugefügt, dass Lademodus optional persistent sein kann
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Hinzugefügt, dass Ladeplan des Eco-Modus persistent ist
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Hinzugefügt, dass Eco-Ladeplan-Plots bei Klick vergrößert werden
• Schlüsselgenerierung zur WireGuard-Unterseite hinzugefügt
• (Nur WARP1, WARP2, WARP3) Überprüfung der Versorgungsspannung hinzugefügt
• Modbus TCP: Sungrow Batterieleistungs- und -energiewerte repariert
• Modbus TCP: Goodwe Wechselrichter- und Netzenergiewerte repariert
• Modbus TCP: Fox ESS H3 Batteriewerte repariert; Unterstützung für zweite Batterie hinzugefügt
• Sichergestellt, dass Lastmanagement nicht zu viel Strom allokiert, wenn ein Fahrzeug keinen Strom bezieht
• Sichergestellt, dass Lastmanager beim Neustart nicht alle laufenden Ladevorgänge stoppt
• (Nur WARP1, WARP2, WARP3) Modbus TCP-Server: Lesen bekannter Register ist jetzt immer erlaubt, selbst wenn das zugehörige Feature nicht verfügbar ist
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Sichergestellt, dass Eco-Ladeplan-Entscheidungen nur zwischen 15-Minuten-Slots geändert weden
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Behoben, dass Abfrage von dynamischen Strompreisen, Firmware-Updates und PV-Prognose, sowie Verbindungen zum Fernzugriff nur funktionierten, wenn Netzwerklatenz unter 50ms lag
• Behoben, dass automatische Kanalwahl des WLAN-Access Points den ersten WLAN-Verbindungsversuch gestört hat
• (Nur WARP1, WARP2, WARP3) Behoben, dass über API vorgetäuschte NFC-Tags nicht im Webinterface angezeigt wurden
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Fehlermeldung, wenn dynamische Strompreise nicht verfügbar sind, verbessert
• (Nur WARP1, WARP2, WARP3) Behoben, dass Ladestatus-Automatisierungsbedingungen fälschlicherweise nach Neustart ausgelöst wurden
• Sichergestellt, dass ein nicht funktionaler Web Server zu einem Rollback auf die letzte Firmware führt
• (Nur WARP2, WARP3) Wartezeit beim Phasenwechsel auf 45 Sekunden erhöht, um mit langsam schaltenden Fahrzeugen kompatibel zu sein (durch Update auf Ladecontroller-Firmware 2.2.17)
• (Nur WARP2, WARP3) Konfigurierbare Wartezeit beim Phasenwechsel hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.17)
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Unterstützung für Eltako DSZ16DZE hinzugefügt
• (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Unterstützung für Iskra WM3M4C hinzugefügt
• (Nur WARP2, WARP3) Sporadisch angezeigten Fehlerzustand 5 behoben (durch Update auf Ladecontroller-Firmware 2.2.17)
• (Nur WARP2, WARP3) Robustheit der Phasenumschaltung verbessert(durch Update auf Ladecontroller-Firmware 2.2.17)

Download: WARP1 2.8.10 bzw. WARP2 2.8.11 bzw. WARP3 2.8.11 bzw. WARP Energy Manager 2.4.10 bzw. WARP Energy Manager 2.0 1.3.10

Kannst du nochmal mit der Firmware im Anhang testen? Mit der kannst du unter Wallbox -> Einstellungen die "Wartezeit bei Phasen­umschaltung" einstellen. Standardwert sind 45 Sekunden. Reichen 45 Sekunden bei dir, oder musst du auf 60 Sekunden erhöhen?

warp3_firmware-NIGHTLY_2_8_10_6904e3be_ee6c990911f5cea_merged.bin

Nochmal zum rekapitulieren: Hast du mit der Firmware die immer 60 Sekunden zum Phasenwechsel braucht, noch das Problem, dass die Willkommensladung immer dreiphasig sein muss? Oder hat sich das mit den längeren Phasenwechseln behoben?

The MQTT module for ESP32 bricks is not an implementation of the MQTT bindings (https://www.tinkerforge.com/en/doc/Software/API_Bindings_MQTT.html#api-bindings-mqtt) that allow you to control Bricklets via MQTT. You have to run the MQTT bindings on some PC, Raspberry Pi, etc. and can then use the unmodified ESP32 firmware to control attached Bricklets.

If you want to build a custom firmware, you have to implement / pass-through calls to the Bricklets yourself, as is described here: https://www.tinkerforge.com/en/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html This is not very convenient, but currently there is no complete implementation of the MQTT bindings that can run on the ESP32 brick directly.

On 10/23/2025 at 11:00 PM, Raudi said:

Ob wohl, ist denn bei einem Neustart wirklich die Bedingung erfüllt von "Getrennt" auf "Beliebig"?

Ist sie im Moment, das ist aber ein Bug. Wird mit dem nächsten Firmware-Release gefixt.

Mit ISO 15118 kann man außerdem

• weniger als 6 A Ladeleistung freigeben -> besseres PV-Überschussladen
• (manche) Autos erkennen, ohne dass man ein NFC-Tag ö.Ä. verwenden muss, siehe z.B. https://docs.evcc.io/docs/features/vehicle#erkennung-via-plug--charge
• eventuell auslesen, was die maximale Ladeleistung des Autos ist -> besseres Lastmanagement
• möglicherweise verhindern, dass Autos so einschlafen, dass man sie nicht wieder aufwecken kann -> das ist auch relevant für's PV-Überschussladen

On 10/21/2025 at 10:14 AM, Raudi said:

Mich würde ja mal interessieren, ob ihr dieses Problem auch in dieser Art bei einem anderen Auto der ID Serie reproduzieren könnt.

Wir haben hier einen älteren Enyaq, einen Born, einen neueren ID.3, einen ID.Buzz und seit neustem zwei Elroqs und ich wüsste nicht, dass wir spezifisch dieses Problem schon einmal hatten. Fairerweise laden die aber fast immer an WARP2, also Wallboxen ohne Phasenumschaltung.

Der ID.3 hatte einmal Probleme mit der Phasenumschaltung, denen wir aber bisher noch nicht nachgegangen sind, weil sie nicht wieder aufgetreten sind.

Ich habe mit dem ID.3 gerade nochmal genau das versucht, was du beschrieben hattest, also

• einphasig laden (da waren noch 32 A eingestellt) für 5 Minuten
• 5 Minuten Ladepause
• einphasig laden 6A für 5 Minuten
• einphasig laden 16A für 2 Minuten
• umschalten auf dreiphasig

Das hat funktioniert. Ist also anscheinend nicht bei allen VWs identisch kaputt.

Sieht gut aus! Je nachdem ob du das Regel-Intervall von EVCC umgestellt hast (https://docs.evcc.io/docs/reference/configuration/interval, Standardwert sind 30 Sekunden) solltest du die Verzögerung um ein paar Sekunden (z.b. auf 35) erhöhen. Wenn du richtig Pech mit dem Timing hast, könnte es sein, dass EVCC die "pv"-Nachricht sieht, bevor es die Information auswertet, dass ein Auto angesteckt ist.

Vielleicht kannst du dich da kreativ raushacken. Eine Idee: Du kannst auf der Wallbox Automatisierungsregeln anlegen und EVCC hat eine MQTT-API (siehe hier https://docs.evcc.io/docs/integrations/mqtt-api#loadpoints). Du könntest also folgendes bauen:

- Wenn ein Auto angesteckt wird (das sieht die Wallbox sofort und EVCC mit einer Latenz von bis zu 30 Sekunden), setzt du den Lademodus von EVCC auf Schnell (in der Erwartungshaltung, dass EVCC dann dreiphasig laden wird)
- Nach X Minuten (also eine zweite Regel mit der gleichen Bedingung, aber einer Verzögerung von X * 60 Sekunden) setzt du den Lademodus wieder auf PV
z.B:

Die Namen der Lademodi sind bei EVCC anscheinend nur in der REST-API dokumentiert, hier: https://docs.evcc.io/docs/integrations/rest-api einmal nach /mode suchen.

Damit dir das dreiphasige Willkommensladen dann nicht zu viel aus dem Netz zieht, kannst du noch zwei Regeln mit identischer Bedingung anlegen, die den Ladestrom auf 6 A begrenzen bzw. nach X Minuten dann wieder auf 32 A freigeben (das ist ein von EVCC unabhängiges Limit)
z.B:

Problematisch daran ist, dass es im Moment ein hartes Limit für die MQTT-Automatisierungsregeln gibt, ein Topic darf maximal 32 Zeichen lang sein. D.h die ID des Loadpoints musst du in der EVCC-Konfiguration eventuell zusammenkürzen.

On 10/17/2025 at 12:01 PM, yvo said:

And that in contrast to other Bricks, an ESP32 Brick connected to USB will not show up as Brick in a Brick Viewer connected to localhost.

This sentence is worded somewhat misleadingly: ESP32 Bricks (and ESP32 Ethernet Bricks) don't show up as Bricks in the list of connected devices if connected via USB:

They still show up in the "Updates / Flashing" window under Bricks:

If you (re)flash the ESP32 Ethernet firmware here, this will also do a factory reset.

Das geht den Menschen wie den Leuten :D https://github.com/Tinkerforge/esp32-firmware/commit/82e9b46b 

Hast du daran gedacht in der ::setup-Methode deines Backend-Moduls initialized = true zu setzen? Das macht die Standard-Implementierung von IModule für dich, aber wenn du ::setup überschreibst, musst du das selbst machen. Das NavbarItem ist so gebaut, dass es den Eintrag versteckt, wenn das Backend-Modul nicht initialisiert werden konnte.

On 10/3/2025 at 1:57 PM, MatzeTF said:

Wenn ich mir die Nachrichten so ansehe, kann es natürlich sein, dass ioBroker unerwartet die Ladung über "stop_charging" beendet.

Sollte nicht: Dieses Verhalten des ioBroker-MQTT-Plugins ist der Grund warum wir leere Nachrichten nicht mehr auf "payload-losen" Topics erlauben, sondern etwas fordern, das nach JSON riecht.

Und es kam in dem Fall eine leere Nachricht an:

Topic evse/stop_charging is an action. Ignoring empty message.

On 9/30/2025 at 9:07 PM, ThomasR said:

Wäre halt prima gewesen das Regelwerk als eigenen Lademodus hier wiederzufinden und auch über die API oder einem Request zu Verfügung gestellt zu bekommen.

Über die API kannst du da im Moment nicht viel tun, ggfalls flexibilisieren wir das irgendwann. Du könntest aber folgendes machen: Die dynamischen Strompreise werden von api.warp-charger.com abgerufen, konkret https://api.warp-charger.com/v1/day_ahead_prices/de/60min

Der Host ist Teil der Konfiguration der dynamischen Strompreise: https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/day_ahead_prices/#day_ahead_prices_config_any

Du könntest also theoretisch einen kleinen Webserver aufsetzen, der statt einem dynamischen Strompreis immer deinen Nachttarif zurückgibt.

On 9/29/2025 at 7:55 PM, ThomasR said:

Das für jeden Tag zu machen ist schon strange 😆 und dürfte auch die Anzahl der Regeln überschreiten (max. 14?).

Wenn ich die Regeln richtig verstehe ist also in folgenden Intervallen der Strom günstig:

Mo 22:00 bis Di 06:00
Di 22:00 bis Mi 06:00
Mi 22:00 bis Do 06:00
Do 22:00 bis Fr 06:00
Fr 22:00 bis Sa 06:00 (das ist der folgende Tag vom Freitag, der ein Wochentag ist)
Sa 13:00 bis Mo 06:00 (Sa 13:00 bis 24:00 und So 00:00  sind der gleiche Zeitpunkt, Regel 3 gilt bis 06:00 des folgenden Tags, also Montag)

korrekt? (Feiertage ignorieren wir mal :D)

Dann hast du also jeden Tag von 22:00 bis 06:00 günstigen Strom und zusätzlich noch Sa von 13:00 bis 22:00 und So von 06:00 bis 22:00

Das sollte also mit folgenden Regeln gehen:

Jeden Tag 22:00 Lademodus auf Schnell
Wochentags (gibt es als Extra-Eintrag bei der Tages-Auswahl der Zeitpunkt-Bedingung) 06:00 Lademodus auf PV
Samstags 06:00 Lademodus auf PV
Samstags 13:00 Lademodus auf Schnell (das wird dann Montag 06:00 aufgehoben)

On 9/29/2025 at 7:55 PM, ThomasR said:

Will ich im Sommer aber nur mit PV Überschuss laden und nicht den NT-Zeitraum nutzen, müsste ich ja alle Regeln wieder löschen. Deaktivieren geht leider nicht.

Das stimmt. Alternativ könntest du als Standard-Lademodus Schnell benutzen und den im Sommer auf PV umstellen, dann machen die ganzen Regeln im Sommer nichts mehr.

Button heißt in dem Fall der Fronttaster. Du solltest dann noch unter Wallbox -> Einstellungen die Taster­ein­stellung auf "keine Aktion" setzen. Sonst wird der Ladevorgang beendet wenn du den Taster drückst.

Alternativ kannst du als Bedingung der 1. Regel auch folgendes einstellen (blah ersetzen durch was auch immer du willst :D ), dann hast du einen Link den du im Webinterface auch anklicken kannst.