MatzeTF

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

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.