laubblaeser

Ahoi, habe gerade gesehen, dass heute wieder eine neue Firmware für Warp und WEM rauskamen. Würde die gerne installieren, um in den Genuss der Bugfixes und neuen Features zu kommen, aber dann würde ich die schöne Implementierung des Plenticore aus der Testfirmware verlieren. Gibt's schon ein ETA für die Liveschaltung der hier erprobten Dinge? Wenn das noch länger dauert, würde ich mal überlegen, ob ich zurück auf den stable Kanal wechsle und dann meine eigene Steuerung reimplementiere. Danke für kurze Info hierzu. :)

Starke Sache! Ich kann das auch so bestätigen, dass alles funktioniert wie erwartet (eben mit den bekannten Quirks). Erzwungenes laden und entladen sowie blockieren in allen Kombinationen funktioniert mit eurer Testfirmware exakt so gut wie ich es zuvor auch händisch bei mir konfiguriert hatte. :)

Zuerst einmal vielen Dank für das heutige Update. Da sind wirklich tolle Verbesserungen und neue Module drin! Beim Modul Kalenderpreise (z.B. für §14a EnWG Modul 3) im Menü für den dynamischen Strompreis ist mir aufgefallen, dass das Interface eine (einfach und gut gestaltete!) Auswahl nach Wochentagen und Uhrzeiten erlaubt, aber nicht nach Quartalen. Viele VNB unterstützen variable Netzentgelte nur für 2 oder 3 von 4 Quartalen, mglw. auch mit unterschiedlichen Zeiten pro Quartal. Wäre es möglich, so eine quartalsweise Einstellung hinzuzufügen, damit man nicht händisch quartalsweise die Kalenderpreise ein- und ausschalten muss?

Ich habe es mit 5 Sekunden probiert und das funktionierte wie erwartet.

Danke. Erste Tests sehen schon mal gut aus. Du hast eine Wiederholungszeit von 20s eingestellt. Das könnte möglicherweise zu lang sein, um alle mögkichen Einstellungen des Watchdogs aufzufangen. Spräche technisch etwas dagegen, die Wiederholung in der Batteriesteuerung auf 1 Sekunde zu setzen? Außerdem habe ich versucht, den separaten Watchdog über Register 1288 (RW) zu verändern und auf den dort angegebenen Minimalwert von 30s einzustellen (= 0, 30). Das führt zu einem Modbus Fehler, als ob sich das Register nicht beschreiben ließe. Irgendwo macht Kostal hier Quatsch. Wir können uns demnach aber wohl erst mal drauf verlassen, dass der Watchdog für die 1280er Register immer auf dem Default von 60s stehen wird.

Ich habe hierzu eine Anfrage an den technischen Support von Kostal gestellt, da es mir stark nach einem Bug riecht. Mal sehen, ob und wie sie darauf antworten werden.

@photron Ich bräuchte die Beta bitte wie erwähnt für den WEM2, sonst kann ich deine Einstellungen nicht testen.

Die Sperre über 1034 funktionierte zuvor einwandfrei. Die 0,5 A Entladung bei Schnellladung passiert nur bei Nutzung der 1280/1282 Register.

Ups, sorry für die false attribution. Ich wusste nicht, welcher Nickname zu wem gehört und hab stumpf geraten, weil du hier im Forum so aktiv bist. 😅

Hier geht's voran, aber noch ist nicht alles geklärt. Nach Rücksprache mit @MatzeTF habe ich andere Register (1280, 1282) genutzt, die mit einer neueren Firmware Version des Plenticore G3 hinzugefügt wurden. Dadurch wird z.B. das Laden mit AC Überschuss nicht mehr verhindert, wenn man das Entladen per Batteriesteuerung verhindert. Bisherige Tests sehen in der Hinsicht gut aus. Leider scheint der Wechselrichter trotzdem eine Batterieentladung von bis zu 0,5 A (= ca. 320 W in meinem Fall) zu nutzen, auch wenn er das eigentlich gar nicht soll. Das scheint eine komische Eigenheit der Kostal Firmware zu sein, denn eigentlich ist die Entladeleistung ja von uns auf 0 W gesetzt worden. Ich denke, hier müsste man mal mit Kostal in Kontakt treten, was das soll. Ärgerlich ist es für mich jetzt auf jeden Fall, da die Batterie sich bei Nutzung dieser Register auch dann langsam entlädt, wenn ich das Auto für eine Schnellladung angesteckt habe. Das soll ja echt nicht der Fall sein...

Joa, dein genannter Workaround ist in etwa so gut wie der von mir genannte. 😅 Mal vorsichtig gefragt: Spräche denn von eurer Seite etwas gegen diese Funktion, z.B. Produktvision oder ähnliches?

Nein, du täuschst dich ganz und gar nicht. Das MQTT Auto-Discovery des Warp Charger steht solide da und funktioniert einwandfrei, soweit ich das beurteilen kann. Mir geht's hier um den WEM, also den Warp Energy Manager. Schade, dass das noch warten muss, @MatzeTF . :(

Sorry für die Nekromantie, aber das ist der sinnvollste Thread, den ich zu dem Thema finden konnte. Es sind jetzt drei Jahre vergangen und der WEM steht bereits auf ganz anderen Füßen. Wäre es wohl denkbar, die MQTT Auto-Discovery Funktion auch hier hinzuzufügen? Das würde viele speziellere use cases einfacher möglich machen, denke ich, da man mittels Skripten in der eigenen Heimautomatisierung steuern könnte. Das betreffende github issue ( https://github.com/Tinkerforge/esp32-firmware/issues/218 ) ist ebenfalls seit Jahren sehr still.

Wäre es wohl möglich, in der Batteriesteuerung eine manuelle Aktivierung der Ladezustände außerhalb der Automatisierungsregeln hinzuzufügen? Sozusagen einmal auszuführende Regeln, die die langfristigen Regeln zeitweise überschreiben. Alle use cases dafür aufzuführen, überschreitet etwas mein heutiges Tippbudget, aber als Beispiel würde ich gerne sporadisch eine 100% Beladung der Batterie mit Netzstrom vornehmen, um das BMS mit den notwendigen Spannungswerten der Zellen zu versorgen, damit Balancing gestartet werden kann. Die auswählbaren Regeln in der Automatisierung geben so etwas zur Zeit nur indirekt her, wenn eine immer greifende Laderegel aktiviert wird, was dann aber einen Neustart des WEM nötig macht.

Vielen Dank für euren Einsatz über die Feiertage!

Heute ist es wieder der Fall. Hier mal die letzten paar Zeilen des aktuellen Ereignislogs: 2026-04-05 13:44:27,949 | remote_access | Management request failed with internal error: ESP_ERR_HTTP_CONNECT (10) 2026-04-05 13:45:02,694 | remote_access | Connecting to Management WireGuard peer my.warp-charger.com:51820 2026-04-05 13:45:03,329 | remote_access | Management connection connected 2026-04-05 13:45:24,634 | day_ahead_prices | No prices available yet 2026-04-05 13:49:24,014 | day_ahead_prices | DAP download failed: ESP_ERR_MBEDTLS_SSL_HANDSHAKE_FAILED (0x801A); X509 - Certificate verification failed, e.g. CRL, CA or signature check failed (0x2700) 2026-04-05 13:49:24,036 | day_ahead_prices | Error while downloading day ahead prices: ESP_ERR_HTTP_CONNECT (0x7002) 2026-04-05 13:50:19,877 | uptime_tracker | Wrote last uptime to flash 2026-04-05 14:45:24,756 | day_ahead_prices | No prices available yet 2026-04-05 15:45:24,902 | day_ahead_prices | No prices available yet 2026-04-05 16:27:39,372 | day_ahead_prices | DAP download timed out 2026-04-05 16:45:25,089 | day_ahead_prices | No prices available yet 2026-04-05 17:08:39,502 | day_ahead_prices | DAP download timed out Was läuft da wo schief und was kann ich tun, damit es nicht mehr passiert? Danke für hilfreiche Tipps! :)

Circa ab 14:00 bis 14:30 Uhr bekam ich die Fehlermeldung beim Aufrufen des API Links. Ich hatte im WEM stets nur die 15 Minuten Variante eingestellt. (Den Test mit den 60 Minuten hatte ich händisch über den Link probiert, aber das tut hier nur randseitig was zur Sache.) Ich hatte bis kurz nach 14:00 Uhr noch Daten im System, auf deren Basis ich eine Änderung in der Batteriesteuerung vorgenommen habe. Nach dem obligatorischen Neustart des WEM kamen dann circa 30 Minuten keine Preise mehr rein (hatte testweise auch noch alle paar Minuten einmal neu gestartet) und die vorher vorhandenen Daten für den Rest des Tages waren verschwunden. War also der Ablauf aus Entwicklersicht so zu erwarten? Ich hätte als User eher nicht gedacht, dass die Preisdaten nach einem Neustart verschwinden und danach scheinbar kurzfristig nicht mehr abrufbar waren.

Die API gibt gerade {"error":"Data not found"} aus, wenn man https://api.warp-charger.com/v1/day_ahead_prices/de/15min aufruft. Auch die 60 Minuten Variante ist wohl kaputt. Meine Automatisierungen zur preisgestützten Batterieladung funktionieren jetzt nicht, da gar keine Daten mehr im WEM vorliegen. Bis 14 Uhr waren noch die heutigen Preise vorhanden, jetzt gar nichts mehr. Was kann ich in so einer Situation tun? Eine API fällt mal aus, keine Frage, aber zwei Anregungen dazu: Könnte man eine Fallback API einrichten, falls der eine Server mal streikt? Können bitte bestehende Werte für den laufenden Tag beibehalten werden, anstatt sie direkt zu verwerfen? Beides könnte zur Resilienz des Systems beitragen.

Moin @Andy569 , dazu gibt's schon ein Thema, schau mal hier: https://www.tinkerunity.org/topic/13620-kostal-plenticore-g3-hybrid-wr/ Ich nutze den WEM2 und die WARP3 im Zusammenspiel mit einem Kostal Plenticore G3 und kann alle möglichen Daten davon ansehen (ausgelesen über Sunspec). Die Einrichtung war äußerst unkompliziert. Die Batteriesteuerung ist noch nicht offiziell in der Firmware hinterlegt, aber ich habe schon eine Konfiguration selbst erstellt, die größtenteils funktioniert (siehe Thread oben).

Ich würde gerne etwas präziser die Dauer der günstigen Stunden im Ladeplan auswählen. Wäre es möglich, dort auch eine Abstufung in Viertelstunden einzuführen, wie es sie auch bei den günstigen Stunden für die Batteriesteuerung gibt?

Und es liegt wohl am LAN3 Port der Fritzbox. Umgesteckt auf LAN1 läuft alles einwandfrei. Also mit dem Support rumschlagen, weil die weniger als ein Jahr alt ist. 😩

Jupp, das scheint es zu sein. Den Router erreiche ich vom Switch aus auch nur mit Paketverlust, alle anderen Geräte am Switch einwandfrei. Danke für die Idee mit dem Laptop, da hätte ich jetzt sicher wieder ne Stunde für gebraucht, um auf die Idee zu kommen. 😅

Klasse, dankeschön. Gibt's irgendwo eigentlich einen öffentlichen Bugtracker oder eine Roadmap für kommende Releases?

Ich habe eine Regel per Schalter im Interface deaktiviert. Diese wird jetzt mit blauem Streifen als Aktiv angezeigt, obwohl sie a) gar nicht aktiviert werden soll und b) gerade die darauffolgende Regel aktiv ist, welche wiederum keinen blauen Streifen in der Anzeige hat.

Hm, Schiete. Soweit ich das gerade richtig sehe, sind alle Geräte, die per Kabel am Switch im Keller hängen, so schlecht erreichbar. Ich befürchte gerade fast, dass der Switch von Batterie oder Leitungen um sich herum gestört wird. :/