Ich meine nicht die Installation - das werde ich machen… sondern ob es damit gelingt den Standby Verbrauch des WR runterzufahren und alle Messwerte beizubehalten bzw. das auch mit angeschlossenem Load funktioniert ohne dass dieser weggeschaltet wird…
Standby Verbrauch bleibt gleich, ca. 40-50W. Das ist dann das gleiche als wenn man per ModBus den Deye/SunSynk in den StandBy Modus bringt. Auch dort kann man weiter per ModBus zugreifen. Es gibt aber Forenbeiträge im Netz die behaupten das der Deye bestimmte Werte dann fehlerhaft messen würde.
Bei mir war das DRM Modul auch nicht dabei. Kann man das generell nachträglich fordern?
Ist das der Inverter switch? Der geht bei mir einfach wieder an und der Inverter läuft in den Fehler F19.
Warum stellst das um? hat doch damit nix zu tun, ist ja nur im Display so verbunden. Hat mit der Funktion nix zu tun. no Battery setzen reicht voll aus.
Fordern kann man immer, ob man es bekommt ist was anderes. Soweit ich weiß, kostet es aber einiges... was ist da so tolles drauf was das >50€ bringt?
Ich werde dass dann per HA lösen, damit kann man ja die Einspeisung auch Regeln. Halt die 4 Eingänge auswerten und Wert per Modbus setzen.
Wer weiß, was uns zukünftige Änderungen der PV Regeln bringen, da ist es besser vorbereitet zu sein. Für eine Zwangsabschaltung oder -reduzierung wird das DRM Modul sicher eher akzeptiert, als eine selbstgebastelte Modbus Lösung.
Ich bin mit Deye in Kontakt, die wollen mir das Board schicken. Allerdings aus China, da in Deutschland aktuell nicht mehr vorhanden. Dafür aber kostenlos. Ich bin gespannt.
Hört sich gut an...
Ich nutze ein EMS, so lange da nicht auch wieder Steine und Stöcke in den Weg gelegt werden per Gesetzt, ist das Ergebniss dann entscheident. Da mit der Alten Regelung dann aber entschädigt werden muss, wird es wohl eher die Neuanlagen betreffen. Ich warte erst mal ab was kommt.
Hallo Zusammen,
ich habe schon länger zwei Deye 3P, 1x LV 1xHV mit Batterien, aber fange erst seit Jahresanfang damit an den ganzen Kram in HA zu integrieren und zu automatisieren. Bin beruflich vom Fach.
Erstmal bin ich sehr dankbar für alle tollen und sehr qualifizierten Beiträge hier. 
Ich lese hier nächtelang, es ist spannender als jeder Krimi für mich und ich habe aktuell eine sehr steile Lernkurve.
Allerdings sind es unfassbar viele Informationen und Zusammenhänge und ich vermute, dass nur wenige so verrückt sind wie ich und das alles von Anfang an zu lesen. Das schreit nach einem git repo “Deye-Docu” oder einem Deye-Wiki in dem man das mal halbwegs strukturiert zusammenfasst, oder? Gibt es sowas schon irgendwo und ich war zu blind im Netz unterwegs?
Was einem fehlt zum Einstieg wäre:
Gründe warum man den Deye in HA automatisieren will:
- Deye hat relevante Verlustleistung - die will man minimieren
- Man möchte den Energiefluss überwachen können und Verbraucher smart steuern
Wie steuere ich den Deye am besten an? Welche Vor und Nachteile haben die Optionen (Zuverlässigkeit, nur lesen / auch schreiben, Antwortzeiten, Anzahl der Entitäten…):
-
Solarman Stick Deye-Cloud integration
-
“solarman-sticklogger” ohne cloud integration mit
- Solarman Stick (proprietäres solarman protokoll port 8899)
- ESP32 Modbus-over-TCP Kopplung
- Waveshare Modbus-over-TCP Kopplung
- Modbus RTU USB-Stick
- Elfin EE11a oder EW11a Modbus-over-TCP Kopplung
-
kellerza/sunsynk + MQTT ohne cloud integration mit
- ESP32 Modbus-over-TCP Kopplung
- Waveshare Modbus-over-TCP Kopplung
- Modbus RTU USB-Stick
- Elfin EE11a oder EW11a Modbus-over-TCP Kopplung
Links zu Videos / Anleitungen für möglichst jede dieser Varianten
Firmware Versionen und ihre bekannten Eigenheiten, aktuell am meisten empfohlenen Kombinationen HMI / Main
- im github hinterlegte codes / yaml Dateien mit Doku für welche Steuerungsszenarien die sinnvoll sind.
Eigentlich müsste man nur die Beiträge hier strukturiert in ein git (GitHub) übertragen. Das hätte diverse Vorteile;
- Die alten Hasen verlieren selbst nicht mehr irgendwann den Überblick
- Neueinsteiger finden sich schneller zurecht und weniger geben auf
- Die Basis der Nutzer von aktiven Deye Nutzern wird größer und es gibt insgesammt mehr Problemlösungen, Erkenntnisse und Code.
- Die selbstbestimmte und digital souveräne klimaneutrale Stromerzeugung wird unterstützt.
Meinungen?
Mit WLAN geht es auch. Also ohne USB-Adapter und dem Klimbim. Auch ohne Internetanbindung.
Ja, ich bin auch der Meinung dass es dazu eine Anleitung geben sollte, aber der Aufwand… wenn du dir den antun wolltest, ich würde, sofern ich kann, auch was beisteuern an Arbeit und Zeit. Vor allem haben wir auch verschiedene Deye und Geräte, auch für Leute mit anderen Geräten wären Anleitungen zu HA und Automatisierungen interessant oder auch visualisierungen Schritt für Schritt. Denn es mangelt eher an solchen Schritt für Schritt Anleitungen, leicht, einfach, nachvollziehbar. Oder halt Beispieldateien mit vorgefertigten yaml und dann gibt es eine Zuweisungs-Yaml in welcher man einfach nur die vorhandenen Werte von Akku,WR,PV,was-auch-immer nachtragen kann. Also eine Pointer-Datei. Der Rest ist dann automatisiert.
In dem letzten Jahr sind meine HA-Automationen zum Steuern des Akkus immer komplexer geworden, obwohl ich da schon einiges entkoppelt habe. Seit dem letzten Winter habe ich das ganze dahingehend erweitert, dass wie von vielen hier besprochen die Batterie abgeworfen wird. Wir heizen mit einer gut dimensionierten WP, die im Winter mehr oder weniger durchläuft, und so ziemlich alles aufnimmt, was vom Dach kommt.
Setup: Der Deye 12k wird mittels HA-Add-on über Modbus angesprochen.
Es gibt drei grundsätzliche Arbeitsmodi:
- Force Calibration: Wenn die Batterie entweder zu lange nicht auf 100% war, oder die Spannung unter einen kritischen Wert fällt, wird Target Prog-Capacity auf 100% gesetzt, und langsames Laden aus dem Netz erlaubt.
- Normal: Die Batterie lädt morgens und abends langsam, und nur Mittags schnell mit etwa 0,25C. Dabei wird versucht, nur so viel zu laden, wie voraussichtlich benötigt wird (höchster DoD der letzten Woche plus ein Puffer). Einmal pro Woche wird 100% angepeilt. Die Idee ist, den durchschnittlichen SOC möglichst niedrig zu halten, und sich quasi “nebenbei” netzdienlich zu verhalten.
- Winter: Darum geht es hier eigentlich. Der Winter-Modus wird getriggert, wenn mehrere Tage hintereinander nur sehr wenig eingespeist wurde (Day Grid Export).
- Wenn Nachts der SOC der Batterie unter einen Schwellwert fällt, wird sie deaktiviert.
- Wenn Tagsüber bei deaktivierter Batterie relevante Mengen an Energie eingespeist werden, wird sie wieder aktiviert.
- Bei aktiver Batterie ist die Ladeleistung im Gegensatz zum Normalbetrieb kaum begrenzt, um so viel einzuspeichern wie möglich.
- Wird trotz aktiver Batterie zwei Tage eine relevante Menge an Energie in Netz gespeist, deaktiviert sich der Wintermodus wieder.
Das lief den letzten Winter sehr zuverlässig, und seit ein paar Wochen sind wir wieder im Normalbetrieb. Die Fehlermeldung nach Abschalten der Batterie, und dass der Deye bei deaktivierter Batterie nicht alle Verbrauchswerte anzeigt, ist zwar nicht schön, lässt sich aber verkraften.
Insgesamt hat sich für die gesparte Energie die ganze Arbeit zumindest was die Einsparungen angeht wahrscheinlich nicht gelohnt, aber man hat ja auch Spaß dran ;). Es stellt sich allerdings die Frage, ob ein anderes System (z.B. evcc) die Umsetzung erleichtert hätte.
Vielleicht hilft das ja dem einen oder anderen. Die konkrete Implementierung hier zu posten wäre wohl totaler Overkill, das ist mittlerweile auch ein ziemlich komplexes System mit diversen Helpern, Automationen und Template-Sensoren geworden. Dabei war die Aufteilung in mehrere Automationen wahrscheinlich sogar das, was das ganze noch handhabbar hält, in einer einzigen Automation möchte ich mir das absolut nicht vorstellen 
Eine sonnige Woche euch allen und LG!
Edit: Ach so, ganz vergessen, Danke an alle, die hier bisher berichteten! Der Input unter anderem in diesem Thread war super wertvoll, und hat mir sehr weitergeholfen. Das war auch der eigentlich Grund, warum ich einmal Feedback geben wollte 
1 „Gefällt mir“
Moin amiko, wie hast du das gemacht? Habe Firmware 1135 drauf und kann am WR nur auf 000 stellen. Funktioniert nicht wirklich gut? Habe ich eine Einstellung übersehen?
Ich hätte gerne deine Lösung für meine Anlage übernommen, wenn ich deine Implementierung bekommen hätte 
Musst du mit einem Register Befehl machen
Ja, ich hatte über eine Veröffentlichung schon nachgedacht. Allerdings ist das wirklich wild gewachsen, und vieles ist (leider) direkt über die UI gemacht worden, also ist das Teilen des Codes per yaml schwierig.
Wenn es einen konkreten Teil gibt, der dich interessiert, kann ich das aber gerne einmal exportieren und dir zukommen lassen, schreib mich einfach an
Eine Open-Source-Version ist auch weiterhin denkbar, aber aktuell habe ich dafür echt nicht die Zeit. Ein “einfaches” EMS-AddOn für HA hätte wahrscheinlich schon ein paar Menschen, die sich dafür interessieren. Mir war wichtig, dass das alles ohne KI und Internet-Quellen deterministisch mit einfachen Regelkreisen läuft, wahrscheinlich bin ich damit nicht alleine. Gleichzeitig ist das System sehr auf meinen Use-Case zugeschnitten. Zuletzt habe ich noch eine WallBox eingebunden (für Überschussladen, aus dem Akku laden, und bis zu einem bestimmten Zeitpunkt x% ins Auto laden), und muss mich in den nächsten Monaten irgendwann um EnWG §14a kümmen…