@maltes Sehr schönes Projekt. Kannst Du bitte kurz erläutern wie Du die Daten aus dem Victron Smartsolar in Deinen ESP32 bekommst? Hast Du dessen serielle Schnittstelle angezapft? Ich überlege hier eine kleine Firmware für den ESP8266 zu programmieren, um die Daten über WLAN abholen zu können. Aber ich muss das Rad nicht unbedingt neu erfinden.
Ja das läuft über die serielle Schnittstelle. Der ESP32 stellt diese Informationen dann auch über eine REST API und MQTT bereit. In Home Assistant kann man das auch einbinden, da gibt es wohl eine Auto Discovery Lösung für (die ich nicht nutze)
Die credits für die Implementierung gehen aber an andere 🙂
Ich kümmere mich gerade darum das ich die Nulleinspeisung ausschalten kann. Ich lade gelegentlich mein E-Auto Nachts mit günstigem Strom und dann darf der Speicher nicht laufen. Der würde aufgrund der Größe verlieren 🙂 Da muss der Raspberry PI der das Laden steuert das verhindern.
Und dann hätte ich gerne noch einen Modus bei dem, bei voller Batterie, den Wechselrichter entsprechend der PV Leistung einspeisen kann.
Es ist ein Projekt 🙂
Mir fällt auf das ich die UI Ergänzungen nie gezeigt habe:
Die wesentlichen aktuellen Daten landen jetzt oben in der Übersicht
Hallo zusammen,
ich bin ganz neu hier im Forum und echt erstaunt über den Erfinder-Reichtum hier. Habe direkt diesen Thread gefunden, den ich sehr spannend finde, da ich auch gerade plane, eine Grundlasteinspeisung mit einem Hoymiles 600 realisieren.
Wir haben seit 01/2023 eine 12,4 kWP PV Anlage ohne Akku.
Der Plan sieht etwa wie folgt aus:
- Zum Start ein Pylontech (US3000C oder US5000C) als Akku
- Einspeisung über HM 600
- Alles geregelt über OpenDTU
- Laden des Akkus über ein Ladegerät, wenn PV-Überschuß vorhanden. SmartMeter ( Huawei DTSU666-H) ist vorhanden und wird über Solaranzeige ausgelesen, Werte stehen per MQTT zur Verfügung
- später will ich noch Laden über 3 zusätzliche PV-Module + einen passenen Smartsolar (150/35)? nachrüsten
Jetzt zu meiner Frage:
Ich habe hier gesehen, dass man mit OpenDTU-on Battery auch das Huawei R4850G2 per CAN steuern kann. Was mir noch nicht klar ist: Wie erfolgt die Umsetzung der Ladelogik (Konstant-Strom-Phase, Konstant-Spannung-Phase, incl. der Schwellwerte für Spannung etc.)? Muss ich da auf Basis der von OpenDTU per MQTT verschickten Infos (siehe "Huawei AC Charger Topics") eine Logik außerhalb von OpenDTU implementieren? Bei mir könnte ich das z.B. in Node-Red realisieren. Lieber wäre es mir aber, wenn die Logik direkt auf dem ESP mit OpenDTU realisiert wäre. Dann wäre sicherer für den Fall, dass z.B. mal das Netzwerk ausfällt oder Prozesse auf dem Server hängen bleiben (z.B. MQTT, Node-Red o.ä.). Dann könnte der ESP ganz alleine die Steuerung übernehmen, ohne auf andere Komponenten angewiesen zu sein.
Wenn man das selbst implementiert: Gibt es irgendwo eine Dokumentation, wie dein LiFePo Ladevorgang aussehen muss?
Vielen Dank für Eure Hilfe,
Carsten
Um die Frage etwas zu präzisieren:
In den technischen Daten des US5000C steht:
- Entladespannungsbereich: 44,5 – 53,5V
- Ladespannungsbereich: 52,5 – 53,5V
Ist es ausreichend, wenn man:
- die Entladung stoppt, wenn der Akku eine Spannung von 44,5V (untere Grenze Entladespanung) oder etwas darüber erreicht
Für die Ladung:
- Netzteil einschalten (MQTT Topic: huawei/cmd/power 1)
- Ladespannung begrenzen auf max. 53,5V (MQTT Topic: huawei/cmd/limit_online_voltage 53,5)
- Ladestrom entsprechend PV Überschuss regeln (MQTT Topic:huawei/cmd/limit_online_current ), dabei die Stromstärke berechnen als I = PV Überschuss / Ladespannung. Hysterese einbauen, damit nicht zu oft nachgeregelt wird
- Laden stoppen, wenn die Batterie die Ladeschlussspannung erreicht (MQTT Topic: battery/current liefert 53,5V) . Zum Stoppen:
- huawei/cmd/limit_online_current auf 0 setzen
- Netzteil ausschalten (MQTT Topic: huawei/cmd/power 0)
Hey @cacu15
Was du beschreibst ist 98% korrekt. Die kleine Ergänzungen sind:
- Bei der Ladespannung sollte man sich m.E. an den Empfehlungen von Victron orientieren: https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom
- Das Entladen wird entsprechend dem State of Charge gestoppt. Das bekommt diese Lösung über den CAN bus von der Pylontech Batterie.
Mein Plan ist es das openDTU irgendwann auch noch die Regelung des Huawei Netzteils übernehmen kann. Davor standen jetzt aber aus meiner Sicht noch diverse Probleme (MQTT Steuerung des Power Limiters, refactoring). Im Grunde bin ich damit auch etwas weiter und es gibt diverse pull requests von mir. Ich bin aber gerade nicht sicher ob meine Änderungen am Power Limiter akzeptiert werden (habe bisher kein Feedback). Evtl. muss ich die in meinem Repo maintainen. Da gibt es auch einen Branch mit einem Dokumentationsupdate.
Bei Interesse:
https://github.com/MalteSchm/OpenDTU-OnBattery/tree/master
Apropos: Ich bin irgendwo mal gefragt worden ob man nicht die Leistung des Energy Meters im Webinterface anzeigen kann. Das ist auch umgesetzt (genauso wie die Leistung die das Huawei Netzteil liefert)
Das Entladen wird entsprechend dem State of Charge gestoppt. Das bekommt diese Lösung über den CAN bus von der Pylontech Batterie.
Weißt du zufällig ob das auch mit Victron funktioniert übers Cerbo GX und einem Smart Shunt?
Can Bus Schnittstellen hat das Cerbo ja auch...
Achtung, einige meiner Angaben stammen von nicht kalibrierten oder geeichten Geräten. Bei Risiken und Nebenwürgungen schreiben sie die Packungsbeilage und vertrauen sie nicht meinen Angaben oder denen ihres Spirituellen Führers! Denn für jede Lösung haben wir ein Problem. Vertrauen sie auf ihren Fehler und genießen sie die Reise. Alle Angaben ohne Gewehr!
Ja das wäre noch die Königsklasse, mit dem Huawei den Überschuss automatisch in den Akku laden, und ebenfalls automatisch Nulleinspeisung mit dem Hoymiles parallel. Ich hab es per Node-Red gelöst, läuft ganz gut.
@ste2k Du hast das schon in Node-Red? Dann wäre es super nett, wenn Du Deinen Flow mal teilst, dann muss ich nicht bei 0 anfangen. 
P.S. Habe jetzt gleich einen großen Teil der Bauteile bestellt, dann kann es bald losgehen. Nur das Netzteil ist etwas schwer zu finden. Aber auch ohne gibt es ja genug zu basteln.
@maltes Hallo, ich habe mir eine OpenDTU OnBattery zum Testen auf Lochraster aufgebaut. Ist es richtig, dass TX des Ladereglers (VE direct) an PIN22 (RX) des ESP32 angeschlossen werden muss? Muss ich noch irgendwo irgendwas an der Device Config der OpenDTU ändern, damit die Daten des Ladereglers eingelesen werden oder ist dieser Pin by default konfiguiert, wenn ich VE direct aktiviere?
Du brauchst einen Logic level Shifter. Ist der verbaut?
Seit gestern ist ein Dokumentationsupdate online das ich geschrieben habe. Da wird die Hardware genauer erklärt.
In diesem Branch: https://github.com/helgeerbe/OpenDTU-OnBattery/tree/development
Die Beschreibung: https://github.com/helgeerbe/OpenDTU-OnBattery/blob/development/docs/hardware_flash.md
Logic Level Shifter hatte ich auch erst nicht. Das hat mich mehrere Stunden gekostet 
Grüße
Malte
Das hilft mir schon mal sehr, vielen Dank, Malte!
Ich habe gesehen, dass in den Device Profiles ein Profil für das Olimex ESP32-EVB (siehe Bild) enthalten ist. Das wäre evtl. in so weit interessant, weil dieses Board zum einen 2 Relais enthält, von denen man 1 nutzen könnte, um das Huawei Netzteil zu schalten. Zum anderen ist ein CAN Interface enthalten, was einem evtl. die Bastelei mit der Modifikation des CAN Interfaces sparen würde.
Hat irgendwer schon Erfahrung mit diesem Board im Einsatz mit OpenDTU?
Gruß, Carsten
Interessant das kannte ich nicht.
Ohne SW Änderungen funktioniert der CAN bus nicht weil der interne CAN Controller im ESP32 für die Pylontech Batterie benutzt wird. Das Huawei hängt an einem externen Controller der über SPI angeschlossen ist. Das ist wegen den unterschiedlichen Geschwindigkeiten bei beiden Geräten erforderlich
Ich hatte mal Code der den internen Controller benutzt hat. Das war vor der Integration mit -onBattery
Glaub schon das man das zum Spielen bringen kann aber da hast du schneller noch so ein MCP2515 CAN Controller dran gelötet
@maltes
OK, aber den CAN Controller auf dem Board müsste ich doch dann für den Pylontech Akku verwenden können anstatt des SN65HVD320 Transceivers. Dann spare ich mir immer noch diese separate Karte. Ich habe mir jetzt eh' dieses Board + ein Olimex ESP32-POE bestellt. Ich probiere einfach mal aus, ob ich mit dem CAN Transceiver auf dem Board dann mit dem Pylontech reden kann. Dann spare ich immer noch eine CAN-Karte und eine Relais Karte + den Level Shifter zum Ansprechen des Relais.
Wenn es nicht klappt, dann nehme ich eben das ESP32-POE Board 😉