MatzeTF

Bitte aktualisiere nochmal auf die neueste Firmware, reproduziere den Fehler und mach dann hier einen neuen Thread dafür auf und poste dort einen frischen Debug-Report, damit wir uns das ansehen können.

Bitte teste mal diese WEM2-Firmware. energy_manager_v2_firmware_1_8_6_6aedcdce_0b0c6b7db3b5423_merged.bin

Warum konnte das Auto nicht laden? Ging das mit dem oben beschriebenen Problem zusammen oder war das was anderes?

Bitte Lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Bitte lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an. Ansonsten kannst du mal unter Wallbox → Ladestatus den Slot der externen Steuerung freigeben. Wenn sich der Wert anschließend wieder auf irgendwas unter 32000 ändert, gibt es irgendwas bei dir, das die externe Steuerung beeinflusst.

Bitte lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Gegen 14:00 ist der Speicher voll und man sieht, dass die Speicherleistung reduziert wird und stattdessen ins Netz eingespeist wird (rot und orange runter). Gegen 14:45 schließt du dein Auto an und es beginnt zu laden (blau hoch). Die Ladeleistung scheint aber aus dem Nichts zu kommen. Zeitgleich mit der Ladeleistung müsste entweder die Speicherentladung oder der Netzbezug steigen, aber da ist gar nichts. Irgendwie ist deine Wallbox seltsam angeschlossen. Hängt die vor dem Netzbezugszähler oder hat die einen eigenen Netzanschluss mit EVU-Zähler? Wenn der ausgewählte Netzbezugszähler den Verbrauch der Wallbox nicht sehen kann, kann PV-Überschussladen nicht funktionieren.

Bitte lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an. Im Report sind maximal 45 Minuten der PV-Historie enthalten. Dementsprechend muss der Report innerhalb von 45 Minuten nach der Überschreitung runtergeladen werden.

Ja. Richte eine der mitgelieferten NFC-Karten als Gast-Karte ein und lagere sie in der Garage. Tipp: Nicht rechts oben auf die Wallbox legen, da sie dort manchmal vom NFC-Leser erkannt wird und dann seltsame Dinge passieren. 😉

Ja. Der WEM kann nur ein paar Stromzähler über Modbus/RTU (RS485) auslesen. Von Schneider Electric ist keiner dabei. Du hast prinzipiell diese Möglichkeiten: Es ist möglich, dem WEM-Bricklet beizubringen, den Zähler von Schneider Electric über Modbus/RTU auszulesen. Dafür müsstest du wahrscheinlich schon einiges an Programmierkenntnissen mitbringen, um dich da einzuarbeiten. Installiere einen Modbus/TCP-Gateway vor dem Zähler und konfiguriere dann die passenden Register über das Webinterface des WEM. Ersetze den Zähler durch einen anderen Zähler, der bereits unterstützt wird, wie z. B. das Elgris Smart Meter IoT. Wenn der WEM in der Nähe des Zählers installiert wird, kannst du auch einen der unterstützten Modbus/RTU-Zähler nehmen. Du ignorierst den Stromverbrauch der Wärmepumpe. Der WEM sammelt die Daten nur rein informativ und verwendet sie nicht für irgendeine Steuerung. Das Manual ist gerne mal veraltet. 🫣 Die Batteriesteuerung existiert bereits, allerdings gibt es aktuell noch keine Anbindung von FoxESS-Speichern dafür. Die ist noch in Arbeit und es gibt aktuell keine ETA.

Ja, sollte so sein. Ich weiß allerdings nicht, ob das schon mal jemand ausprobiert hat. „Kompatibel“ heißt in diesem Fall allerdings, dass der Zähler per Modbus ausgelesen werden kann. Die Stromanschlüsse sind anders angeordnet als bei dem Eltako-Zähler der WARP3. Dementsprechend sind die vorhandenen Leitungen nicht kompatibel (weil zu kurz) und du musst eigene Leitungen beschaffen. Auch das Modbus-Kabel der WARP3 ist zu kurz. Entweder bestellst du das entsprechende Kabel von den WARP4-Ersatzteilen, oder du musst das vorhandene Kabel selbst verlängern.

Deswegen ja auch „wenn du die WARP am Laufen hast“. 😉 Ist mit dem letzten Satz zugegebenermaßen leicht falsch zu verstehen.

Mit der WARP. Richte den Wechselrichter entsprechend der Anleitung für den Sunny Boy Storage 3.7 ein.

Gute Frage. Die offensichtlichen Kandidaten wie Protokolle, Wertehistorien der Stromzähler und TLS-Zertifikate wurden schon in den PSRAM bzw. IRAM ausgelagert. Spontan fallen mir gerade keine Weiteren ein. Was ich spontan gefunden habe, was zusätzlich zu deiner Konfiguration (mDNS + MQTT) definitiv DRAM braucht (Liste erhebt keinen Anspruch auf Vollständigkeit): WLAN: Meiner Erfahrung nach sollten für eine stabile Verbindung 32 WiFi-Buffer á 1534 Bytes – also 49088 Bytes – frei sein. OCPP: 8 KiB dauerhaft EEBUS: 5 KiB pro Peer dauerhaft Sonnenbatterie-Stromzähler: 3 KiB dauerhaft Ladeprotokoll-Generator: 6 KiB temporär Da wir davon ausgehen, dass eigentlich nie alle Funktionen gleichzeitig genutzt werden, sollten bei aktiviertem mDNS und MQTT noch mindestens 50 KiB DRAM frei sein. Der größte freie Block sollte mindestens 8 KiB groß sein, was bei 50 KiB gesamt aber kein Problem sein sollte.

Das ist aktuell nicht möglich. SLAAC ist immer aktiv und darüber wird der Gateway konfiguriert. DNS-Auflösung funktioniert nur über IPv4, aber ausgehende Verbindungen können dann trotzdem über IPv6 aufgebaut werden. Wir hoffen, dass mit dem nächsten großen Bibliotheksupdate weitere IPv6-Features nutzbar werden und dann nicht nur statische Gateway- und DNS-Konfiguration möglich ist, sondern auch DHCPv6. Wann das Update kommt, weiß ich aber noch nicht. Über SLAAC wird der Wallbox übrigens auch immer eine Adresse zugeteilt. Du kannst zusätzlich statische Adressen vergeben, wenn du die Wallbox darüber ansprechen möchtest. Für ausgehende Verbindungen ist das aber nicht nötig; die benutzen einfach die per SLAAC vergebene Adresse.

Der SoC kann aktuell nur während einer DC-Ladung ausgelesen werden. Wenn die Option für den SoC aktiviert ist, startet die Wallbox nach dem Anschließen des Fahrzeuges eine DC-Ladung, liest den SoC aus, und beendet die DC-Ladung wieder, um dann eine AC-Ladung freizugeben. Einige Fahrzeuge nörgeln dann wegen der abgebrochenen DC-Ladung. Daran lässt sich leider aktuell nichts ändern.

Beachte diesen Punkt: Wenn du das Gleiche machen willst, wie @Stone, brauchst du einen zusätzlichen Zähler, der nur die Wallboxleistung misst. Zum Berechnen des SoC kannst du weder den Wechselrichterzähler, noch den Hauptzähler verwenden. Ein Shelly Pro 3EM kostet dich ca. 125 € und dazu kommt noch der Einbau in der Unterverteilung, falls da Platz ist. Selbst mit dem von uns favorisierten Elgris Smart Meter IoT statt dem Shelly bist du immer noch bei 95 € plus Einbau. Einfacher und unterm Strich wahrscheinlich auch nicht wirklich teurer bist du mit der Pro dabei.

Ich habe mir irgendwann Anfang der Woche den zu dem Zeitpunkt aktuellen Stand angesehen. Auf den ersten Blick finde ich die Sachen jetzt nicht wieder. Wahrscheinlich existieren die jetzt nicht mehr. Leider hast du nicht unser Repository geforkt sondern ein neues Repository angelegt, sodass ich das nicht einfach mit unserem vergleichen kann. Das hat da nichts zu suchen. Ich weiß auch nicht, was das verbessern soll, wenn die gleichen Daten weiterhin per HTTP verfügbar sind. Stattdessen wird da von Telemetrie geredet. Bei uns werden aber gar keine Telemetriedaten gesammelt. Die KI ist da anscheinend sehr auf einem typischen kommerziellen Pfad unterwegs. Das ist auch Unsinn. Die Firmware ist bereits darauf ausgelegt, dass du eine eigene Firmware erzeugen und einspielen kannst, wenn sie nicht von uns signiert ist. Ansonsten hättest du gar nicht deine erste eigene Firmware einspielen können. Ich bezog mich auf Änderungen im esp32_common-Modul, die aktuell aber anscheinend auch nicht mehr vorhanden sind. Das lässt sich leider auch nicht verhindern, da für die Bluetooth-Hardwareeinheit zwei große Blöcke Speicher bereits zur Compilezeit reserviert werden und dann nie für etwas anderes genutzt werden können. Die KI hat leider auch nicht unser Test-Framework verstanden und hat sich stattdessen was ganz Eigenes ausgedacht. 🙈 Wenn deine Wallbox am Kabel hängt, muss dich das natürlich nicht aufhalten. Die Buffer für LAN-Kommunikation sind auch alle statisch im DRAM reserviert, sodass du dir da nicht in den Fuß schießen kannst. Die WLAN-Buffer müssen auch in den DRAM und werden da allerdings dynamisch angelegt, sodass sie dort mit dem Bluetooth-Modul konkurrieren und es bei zu wenig DRAM zu Verbindungsproblemen kommen kann, ganz unabhängig von WiFi-Coexistence.

Interessant wäre das vielleicht, nur sehe ich leider einige Probleme. Ich habe mal grob über verschiedene Änderungen in deinem Fork gesehen und musste feststellen, dass deine KI die halbe Firmware auf links gedreht und an verschiedenen Stellen rumgepfuscht hat, die ich für problematisch halte. Anscheinend ging es darum, irgendwelches Tesla-Schlüsselmaterial zu schützen. Dafür hat jetzt z.B. der integrierte Webserver und dessen Authentifizierung einen Tesla-Modus. Außerdem wurde einfach das Herunterladen vor Coredumps entfernt, was für uns keine Option ist, da das ein extrem wichtiges Feature zum Debuggen im Feld ist. Zusätzlich wurden auch noch seltsame Änderungen im Zusammenhang mit der Hardwareverschlüsselung und -signierung Secure Boot gemacht und wenn ich das richtig sehe, bist du nur knapp daran vorbeigeschrammt, deine Wallbox zu bricken. Deine KI hat netterweise darauf hingewiesen, man solle die Firmware doch nur einspielen, wenn man eine Möglichkeit zum Wiederherstellen hat. Diese Möglichkeit gibt es aber nicht, da die Wallbox aufgrund der Cyberresilienz-Verordnung explizit keine derartige Hardware-Schnittstelle nutzbar haben darf, sobald sie die Fertigung verlassen hat. Vielleicht ließen sich diese ganzen seltsamen Änderungen beseitigen, aber unabhängig davon besteht das Problem, dass Bluetooth auf dem ESP extrem viel DRAM frisst, selbst wenn man die Funktion gar nicht nutzt. Die KI hat dir die Lösung dafür als „gezielte Auslagerung geeigneter Verwaltungsdaten in [den] PSRAM“ verkauft, aber tatsächlich wird praktisch alles in den PSRAM verschoben, was verschiedene Funktionen deutlich verlangsamt. Bekanntermaßen werden dadurch Firmware-Uploads deutlich langsamer und möglicherweise steht das im Zusammenhang mit den gelegentlichen Hängern oder Neustarts beim Firmware-Upload, die du beobachtet hast. Da es – wie gesagt – keine Wiederherstellungsmöglichkeit gibt, falls der Firmware-Upload nicht mehr funktioniert, halte ich das für sehr problematisch. Dazu kommen dann noch Probleme mit WiFi-Coexistence. Meistens funktioniert das, aber der ESP hat damit angeblich auch manchmal Probleme. Da Nutzer oft genug WLAN-Probleme haben, möchte ich das ungern schlimmer machen. Das ist jetzt übrigens keine komplette Liste aller möglichen Probleme sondern nur die Dinge, die ich mir etwas genauer angesehen habe. Die Bluetooth-Module selbst habe ich mir genauso wenig angesehen wie die „Clean-Room-Implementierung“ der Tesla-Anbindung, die sich sehr nach „Abgeschrieben vom Klassenkameraden“ anhört, oder die Tests, mit denen sich die KI selbst bescheinigt, alles richtig gemacht zu haben. In Anbetracht der verschiedenen Probleme halte ich es für sinnvoller, auf ISO 15118-20 zu warten, statt uns für immer Bluetooth mit all seinen Problemen ans Bein zu binden. Du darfst natürlich gerne weiterhin deine eigene Firmware nutzen und hier posten.

JSON „null“ bedeutet „Wert unverändert lassen“. 0 bedeutet blockiert. Wenn du die externe Steuerung komplett freigeben möchtest, musst du 32000 senden (das Maximum). Die Lademodi kannst du nur nutzen, wenn das Lastmanagement aktiv ist. Den PV-Modus gibt es nur, wenn PV-Überschussladen aktiv ist. Beides ist in deinem Fall nicht sinnvoll bzw. nutzbar, sodass du die Lademodi der Wallbox nicht nutzen kannst.

Ich glaube, du wirfst gerade PV-Überschussladen und SoC-Berechnung in einen Topf. Wenn du die Werte des Hauptzählers (vom EVU) ausliest, kannst du sie per API an die Wallbox schicken. Damit kann sie dann PV-Überschussladen machen. Der SoC des Fahrzeuges kann entweder von der Wallbox selbst aus dem Fahrzeug gelesen werden und dann bei einer Pro mit dem integrierten Zähler selbst hochgerechnet werden. Alternativ kannst du die SoC-Werte aus der Cloud des Fahrzeugherstellers auslesen und an die Wallbox schicken, was du aber gerade vermeiden willst. Es ist nicht möglich, den SoC mit Hilfe des Hauptzählers hochzurechnen.

Wenn ich das richtig sehe, hast du eine WARP3 Smart, also ohne Zähler. Dementsprechend ist die tatsächliche Ladeleistung nicht bekannt. Wenn du ein Bisschen Programmierkenntnisse mitbringst, kannst du dir allerdings ein Script basteln, das die Wechselrichterleistung in einen Phasenstrom umrechnet und dann auf die API der externen Steuerung schreibt. Dann schaltest du bei der Wallbox PV-Überschussladen und Lastmanagement aus und es wird gar nichts geregelt sondern nur gesteuert und die tatsächliche Ladeleistung ist egal. Die Phasenumschaltung kannst du dann per Webinterface selbst machen, musst allerdings die Anzahl der Phasen auch in deinem Script beachten. Bonus: Zieh fürs Haus einfach immer 300 W oder so von der PV-Leistung ab.

Nein, das ist leider nicht möglich. Für PV-Überschussladen muss der tatsächliche Überschuss am Netzanschluss bekannt sein, damit dieser auf null geregelt werden kann. „PV-Laden“ (oder wie man das nennen soll) ist damit nicht möglich, da den Wechselrichter auf null zu regeln keinen Sinn macht. Den Sungrow-Wechselrichter kann man auch im Modus „Netzbezug“ auslesen, da man daran einen eigenen Netzbezugszähler anschließen kann. Hybrid-Wechselrichter mit Batteriespeicher brauchen den, um den Speicher regeln zu können. Bei Wechselrichtern ohne Speicher kann man manchmal trotzdem einen Zähler anschließen, um die Netzbezugswerte in der App vom Wechselrichter anzuzeigen. Bei dir ist aber offensichtlich kein Zähler angeschlossen.

Wenn kein Auto laden will, erteilt EVCC keine Ladefreigabe und blockiert entsprechend die Wallbox. Wenn du dann EVCC beendest, bleibt die Wallbox blockiert. Weil schon öfters Nutzer in genau das Problem gelaufen sind, gibt es den Knopf zum Freigeben. 😉

Hast du mal EVCC oder Steuerung über die API oder sowas ausprobiert? Auf jeden Fall ist die externe Steuerung aktuell blockiert. Geh mal auf Wallbox → Ladestatus und drück bei der Ladestromgrenze der externen Steuerung auf „Freigeben“.