MatzeTF

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

Inzwischen gibt es die Möglichkeit, die Strompreise direkt per API an Wallbox/WEM zu schicken. Dafür musst du nur bei den Einstellungen die Quelle auf „Push über API“ stellen und die Daten im passenden Format senden. Ein eigener Webserver ist nicht mehr nötig.

Ein häufiger Trugschluss. Ob du nun das Auto aus dem Speicher und das Haus aus dem Netz versorgst oder das Auto aus dem Netz und das Haus aus dem Speicher macht unterm Strich keinen Unterschied. Du hast prinzipiell in beiden Fällen die gleichen Verluste. Relevant ist das eigentlich nur, wenn man einen dynamischen Stromtarif hat. Wenn du die WARP am Laufen hast, versuch mal die angeblich nicht kompatiblen SMA-Geräte auszulesen. Eigentlich stellen die alle die gleichen Informationen zur Verfügung. Ich vermute, dass einen SBS 2.5 einfach noch keiner ausprobiert hat und wir dementsprechend nicht sagen können, ob er kompatibel ist. Bitte lies den mal aus und poste hier das Ergebnis, damit wir die Geräte ggf. mit in die Liste aufnehmen können.

Yes and yes.

This is a known problem with VW cars. You have to enable „Welcome charge“ or „Initial charge“ for your vehicle in evcc. That will fix it.

Energie, die bereits in den Speicher geladen wurde, gilt nicht als Überschuss. Wenn der Speicher als Zähler ausgelesen werden kann, kann man aber dem Auto oder dem Speicher Priorität geben. Hat das Auto Priorität, nimmt die Wallbox dem Speicher die Ladeleistung weg. Die Energie im Speicher wird dann nur zur Überbrückung bei zu wenig PV-Leistung genutzt, z.B. wenn gerade Wolken durchziehen. Wenn der Speicher nicht ausgelesen werden kann, kämpfen Wallbox und Speicher um den gleichen Überschuss und es kann passieren, dass der Speicher ins Auto entladen wird, da die Wallbox nur den ausgeglichenen Netzbezug sieht und den Überschuss dann für reinen PV-Überschuss hält.

Kann mir jemand erklären was es bedeutet KEINE Batteriesteuerung (BS) nutzen zu können!? Mittels Batteriesteuerung kann man dem Speicher verbieten zu laden, zu entladen oder beides, oder ihn zwingen zu laden oder zu entladen. Wenn man einen dynamischen Stromtarif hat, kann es z.B. sinnvoll sein, mittags billigen Netzstrom ins Auto zu laden und dafür dem Speicher das Entladen zu verbieten, damit abends, wenn der Netzstrom teuer ist, die Energie aus dem Speicher genutzt werden kann. Wenn du einfach nur PV-Überschussladen und dynamisches Lastmanagement nutzen möchtest, sollte die fehlende Batteriesteuerung kein Problem sein. Der Sunny Boy 1.5 muss auf keinen Fall getauscht werden, da dessen Erzeugungsleistung genauso egal ist, wie die des Tripower 6.0. Ich weiß gerade nicht, ob der Sunny Boy Storage 2.5 als Speicher ausgelesen werden kann, um das PV-Überschussladen zu verbessern, aber falls das nicht möglich ist, wäre es immer noch billiger, einen einfachen Stromzähler davor zu setzen (z.B. Elgris Smart Meter IoT), statt den deutlich teureren Wechselrichter zu tauschen.

Du legst nochmal eine identische Regel fürs Laden an. Wenn du also fürs Entladen eine Regel hast, die bei Schnellladen Entladen blockiert, legst du noch eine Regel an, die dann auch das Laden blockiert.

Der Unterschied ist halt, dass sich bei den 11 kW-Spitzen Netzbezug und Speicher/Wechselrichter augenscheinlich gleichzeitig ändern, was darauf hindeutet, dass die Änderung durch den Wechselrichter ausgelöst wurde. Bei der Grafik mit den Änderungen im Bereich von 100 Watt sieht es augenscheinlich so aus, dass sich zuerst der Netzbezug ändert und dann der Speicher/Wechselrichter. Das deutet auf einen gepulsten Verbraucher mit einem Verbrauch von ca. 100 W hin, der vom Speicher ausgeregelt wird und somit nichts mit den möglichen Timeout-Problemen zu tun hat, auch wenn die ähnliche Periodendauer der Schwankungen zugegebenermaßen auffällig ist.

Mit ladendem Auto im Bereich von 11 kW oder ohne Auto im Bereich von 100 W?

Ja, damit die Nacht komplett mit zum folgenden Tag zählt und nicht z.B. vor Mitternacht günstiger Netzstrom in den Speicher geschoben wird, wenn für den nächsten Tag viel PV-Ertrag vorhergesagt ist.

Siehe Anlage 4 der Ergänzungen zu den TAB 2023, Kapitel 6.5, insbesondere Abbildung 6. Die WARP4 ist $14a EnWG-konform und EEBUS-kompatibel. Dein Netzanschluss muss allerdings auch für $14a EnWG vorbereitet sein, damit dort vom EVU z.B. eine EEBUS-kompatible Steuerbox eingebaut werden kann, die dann ihre Kommandos an die Wallbox absetzt. Die Internetverbindung der Wallbox ist egal, da die Steuerung (immer?) nur über die Steuerbox des EVU läuft. Dass du wahrscheinlich noch keine Steuerbox bekommst und anscheinend auch noch nicht vorgegeben ist, wie die Steuerbox denn genau an die Verbrauchseinrichtung angeschlossen werden soll, ist dabei irrelevant. Hört sich bescheuert an, ist es aber auch. Edit: Da war elektron etwas schneller als ich.

Die Sonnenbatterie spricht leider kein Modbus/TCP und benötigt eine komplett eigene Anbindung, was aktuell sehr weit unten auf der langen Todo-Liste steht. Wenn du bisher einen Zähler für den Netzbezug angelegt hast, solltest du noch einen weiteren Zähler für den Batteriespeicher anlegen. PV-Überschussladen funktioniert besser, wenn beide Zähler verfügbar sind.

Kann es sein, dass du einfach vergessen hast, auf „Speichern“ zu drücken? Nachdem man einen Zähler hinzugefügt hat, muss man über der Tabelle auf „Speichern“ drücken und wird anschließend zu einem Neustart aufgefordert. Nach dem Neustart sollte der Zähler immer noch da sein und dann auch Werte anzeigen.

Ist bei dir unter Wallbox → Einstellungen der Fahrzeug-Weckruf aktiviert oder nicht? Für Fahrzeuge aus dem Hause VW muss der aktiviert sein.

Kannst du bitte trotzdem den Debug-Report mit eingerichteter Sonnenbatterie als Stromzähler hier hochladen? Du bist der Erste, der ein Problem mit der neuen Unterstützung für die Sonnenbatterie hat.

Bitte die korrekte IP eingeben, neustarten und nach einer Minute einen Debug-Report runterladen (unter System → Ereignis-Log) und hier anhängen. Was wird dir angezeigt, wenn du die IP der Sonnenbatterie im Browser öffnest?

Reihenklemmen und Controllerstapel tauschen funktioniert wahrscheinlich nicht, weil dann die Kabel zwischen Controllerstapel und den Schützen zu kurz sind. Den Controllerstapel um 180° drehen passt wahrscheinlich auch nicht, da die Hutschiene dafür in die falsche Richtung verschoben ist. Es könnte aber klappen, wenn du Schütze und Controllerstapel so wie sie sind nach links schiebst und das Ladekabel auch links ins Gehäuse führst. Könnte aber sein, dass dann zwischen Schützen und Ladekabel nicht genug Platz ist. Die Wallbox kommt problemlos damit klar, wenn der NFC-Leser fehlt. Falls du ihn zerstörungsfrei von der Gehäusewand bekommst, könntest du ihn aber auch oben ins Gehäuse kleben.