Deye Hybrid Angebote Deye Zubehör Produkte Angebot: Deye Schulung
Hallo wir haben seit Mai einen Deye hybrid 12k mit 15,55 kWp auf Nordseite & Südbalkon, da kommen realistisch max. 10kW runter. 50 kWh Batterie hängen dran - bisher praktisch keinen Strom mehr eingekauft, trotz Wärmepumpe und E-Auto. Na ja, im Winter werden wir definitiv nicht autark sein können.
Ich möchte den Deye 12k gerne über Modbus steuern - bspw. um den Akku in "Billigzeiten" (dyn. Strompreise, Tibber) zu laden. Dazu hab ich mir einen Ethernet-RS485 Umsetzer Ebyte E810-DTU V2.0 gekauft.
Mittlerweile kann ich zumindest mal von Deye lesen: bspw. akt. SOC oder Ziel-SOC für die in Time-Of-Use definierten Zeiten uvm.
Was nicht klappt: schreiben. Ich brech mir hier die Finger. Ohne Fehlermeldung geht´s nur, wenn ich von unit-ID 1 lese, aber auf unit-ID 0 schreibe. Lesen (FC 3) klappt wie gesagt, aber beim scheinbar fehlerlosen schreiben (FC 6) geht das ins Nirvana - die Werte bleiben auf dem alten Stand.
Hat hierzu jemand eine Idee?
Ansonsten klappt mittlerweile das lesen der Preise von Tibber, das suchen des günstigsten Zeitbereiches...und nun müßte ich eigentlich nur 1 Wert schreiben können & wäre happy.
Zugegebenermaßen breche ich mir als alter C-Programmierer mit Node Red, Java Script und JSON auch noch etwas die Finger. Ist nicht so wirklich meine Welt.
Deye12k,+ SMA Tripower 6.0 + 45kWh DIY + Epever als Gen Lader 6kVA
16kWp, BEV, 8kW Abregelung > EVU, Home Assistant
Au Backe. Kaum das Problem hier geschildert bin ich selbst über die Lösung gestolpert.
Beim schreiben auch nur 1 Wertes auf den Deye darf man nicht FC 15 = Preset Single Register nehmen (was eigentlich logisch ist!!!), sondern man muß FC 16 = Preset multiple Registers nehmen. Die Anzahl dann auf 1 und schon flutscht es.
Da haben die Damen&Herren Deye-Entwickler wohl eine Abkürzung genommen. Na ja -sonst ist das echt ne tolle Kiste.
So, abschließend noch ne Info.
Betrifft evtl. eher das BMS der Batterien als den Deye, folgende Beobachtung:
Nachts, kleiner Verbrauch, Batterie SOC auf 72%.
Dann über Modbus das laden über Grid mit 12kW aktiviert: SOC springt auf 81%. Nanu, wieso denn?
Ein paar Minuten laden lassen, SOC jetzt bei 83%.
Laden über Grid wieder abgeschaltet, SOC springt auf 75%.
Oha. Ich denke, das kommt vom BMS - kann datt Ding nicht rechnen und peilt den SOC über die Spannung an? Das wäre ja echt unterirdisch. OK, Billig-Batterie von Titan Solar, aber m.E. hat die das vielgenutzte Seplos bzw. Pylontech BMS (Einstellung am Deye 00, über CAN).
Wenn jemand dazu was weiß: immer her damit.
Ansonsten kann ich den Rest jetzt in Ruhe weiterentwickeln.
Später werde ich mir das BMS-Thema noch mal vorknöpfen; ich hab eigentlich erwartet, im Deye meine 5 Stk. 10kWh-Batterien einzel zu sehen. Aber nö, das BMS gibt nur den Gesamtstand durch. Wenn das jetzt wirklich eher spannungsbezogen ist, kann ich genau so gut auf User Battery umstellen und mir die Spannungswerte selbst setzen.
Ist schon seltsam, daß statt des erwarteten Maximal-Entladestroms von 1.000A sogar 1.025A angegeben werden, beim Ladestrom statt der erwarteten 500A "nur" 475A. OK - eigentlich wurscht bei 12kW, d.h. um die 240A rein oder raus. Trotzdem komisch, jede Batt hat eigentlich 100A Lade- und 200A Entladestrom.
@ginnes Hallo, wäre es sehr unverschämt, wenn ich dich bitten würde einen Node Red Flow zu posten, wie Du das umgesetzt hast?
Vom Prinzip her vermute ich, dass Dein Umsetzer Modbus RTU vom Deye bekommt, dieses in Modbus TCP wandelt und Du dann die Daten in Node Red einliest. Nimmst Du die "node-red-contrib-modbus" nodes? Aber wie gesagt, ein Bild (äh flow) sagt mehr als tausend Worte. Ganz toll wäre natürlich, wenn Lesen und Schreiben nachvollziehbar wären.
Hattest Du einen speziellen Grund, warum Du genau diesen Umsetzer gewählt hast?
Auf jeden Fall finde ich Dein Vorhaben extrem spannend! Ist das nicht auch etwas für ein eigenes "how to"?
Genau, ich nutze den node-red-contrib-modbus - hab mir erst mit anderen, viel einfacher aussehenden die Finger verbrannt. Node Red läuft bei mir auf der Kommandozeile unter Windows (später auf einem virtuellen PC, der ohnehin in der NAS 24/7 läuft). Das Interface hab ich einfach per 485-auf-IP gefunden und mir ein billiges rausgesucht; übrigens möchte das als Versorgung 8...28V haben und der freundliche Deye bietet ja innen 12V an, die man dazu nutzen kann.
Das MODBUS schreiben war jetzt der letzte Knackpunkt, alles andere funzt...muß aber noch sauberle fertig programmiert werden; auch ein schönes Dashboard soll noch rein um SOC, Temperatur, Health-Status usw anzuzeigen. Loggen werde ich einfach per csv-Datei, die minütlich gefüllt wird. Dachte erst an SQ-Lite o.ä. - aber nö, keep it small & simple.
Das mit der Ladestrategie über Grid ist nen knifflige Sache - ich denk, hier kann man sich zu Tode entwickeln mit Wettervorhersage usw. Aber Verbrauchsvorhersagen sind ja auch knifflig mit E-Auto, und dann liegt eben trotz Sonne doch Schnee auf der Dach...
Ich fang jetzt mal einfach damit an: in teuren Zeiten (Preis über Mittelwert) setze ich einfach den Soll-SOP runter - dann wir nix aus dem Netz geholt. Zudem suche ich den billigsten 5-h-Block: in diesem setze ich den Soll-SOP hoch, dann wird nachgeladen. In dieser Zeit kann ich den Speicher von leer auf voll bringen. In Zeiten unter dem Mittelpreis aber außerhalb des 5-h-Billigblockes setze ich den Soll-SOP auf Mittelwert: also nachladen nur wenn´s eng wird. Bin der Meinung, dieser einfache Ansatz sollte die 80/20-Regel treffen und schon viel einsparen. Das Ganze mach ich mit der ersten Zeile in Time-Of-Use, die geht von 00:00 bis 23:55. Jetzt brauche ich also nur stündlich den Soll-SOP setzen, fertig. Die zweite Zeile steht auf 23:55 bis 00:00 (in dieser Zeit fahre ich blind mit Festwert SOC), die restlichen Zeilen stehen auf 00:00 bis 00:00 und damit ungenutzt.
Wenn Interesse besteht kann ich gerne den Flow bekanntgeben, sobald er fertig ist. Aber wie gesagt: ich bin eigentlich C-Programmierer, einem Java-Jünger stehen da vielleicht die Haare zu Berge 😆
Allen viel Freude beim basteln, das macht einfach Spaß das Hirn mal für was Vernünftiges einzusetzen.
@ginnes Ich melde schon mal Interesse an! Mich würde es schon freuen, wenn Du bei Gelegenheit die Grundlegenden Flowteile zur Verfügung stellen könntest. Das ich mich mit SPS Programmieren und dem Schreiben und Lesen der Register auseinander gesetzt habe ist leider schon laaaange her. Ich habe wahrscheinlich mittlerweile mehr vergessen als ich je wusste. Node Red geht mittlerweile so. Externe Kommunikation läuft jedoch bei mir hier via MQTT. Das wäre aber hier ja "durch die kalte Brust ins Auge" wenn ich Daten aus dem Deye haben möchte.
Was Deine merkwürdigen Stromwerte angeht: Ich habe doch richtig verstanden, dass Du 5 Batteriepacks parallel angeschlossen hast. Jedes Pack hat ein eigenes Seplos BMS. Ein Pack ist "Master" und die anderen 4 "Slave" seriell verbunden. Sind die "BMSse" die 10E Version? Wenn die Adressierung auf "Auto" steht und alle DIP Schalter auf "OFF", würde ich folgende Werte erwarten:
Du hast im BMS eingestellt:
Charging overcurrent warning = 100A
Discharging overcurrent warning = -200A
Die Anzeige am Deye (bzw. das was das BMS dem Deye sagt)
Charging current = (Charging overcurrent warning / 2) x Anzahl der Packs = (100A / 2) x 5 = 500A
Discharge current = (|Discharging overcurrent warning| -10A) x Anzahl der Packs = (|-200A| - 10A) x 5 = 950A
Solltest Du ein 10C oder D haben, gibt es eine andere Formel. Die müsste ich bei Bedarf raussuchen.
Ggf. kannst Du auch deine BMS Einstellungen posten / schicken, ich schaue gerne mit drüber.
Programm scheint jetzt zu laufen - aber bevor ich da was rausposaune erst mal ein paar Tage fehlerfrei laufen lassen...
Das mit den Batterien ist zwar bissle komisch, aber stört mich jetzt nicht so; es wundert halt ein bisschen. Adressierung der Batterien wie in der Doku aufsteigend. BTW: die Doku weiß nix davon, daß man einen Batteriepack "über Kreuz" anschließen sollte und die mitgelieferten Kabel waren nix für 12kW.
@Lc625: wenn Du fast schon Node Red Profi bist - brech mir grad die Finger mit dem Dashboard: da sind alle Elemente untereinander, ich schaff´s nicht die besser über den Bildschirm zu verteilen. Ich nutze node-red-dashboard, das Layout scheint einspaltig und basta. Angehängt ein Bild vom oberen Teil des Dashboards, drunter kommen noch ein paar weitere Anzeigen.
Irgend ne Idee?
@ginnes Profi.......Ha Ha Ha! Also das Dashboard ist m.E. nicht wirklich das Allerschönste. Bisher habe ich aber alles abbilden können, was ich wollte. Zu Deinem Thema: Bei Node Red kann man keine fixe Aufteilung für ein spezielles Display vorgeben. Die Regel wie Node Red es handhabt ist folgende: Alle Tabs werden in der Reihe von oben nach unten nacheinander dargestellt. Die einzelnen Gruppen in jedem Tab werden dann entsprechend der Reihenfolge in der "Baum Ansicht" in Node Red im Dashboard erst von links nach rechts und dann von oben nach unten dargestellt. Die einzelnen Elemente einer Gruppe werden von oben nach unten dargestellt. Das Ganze so wie die einzelnen Gruppen / Diagramme etc. entsprechend des aktuellen Zooms des anzeigenden Bildschirmes passen.
Was heisst das für Dich? Wenn Du den Zoom der Anzeige Deines PC verkleinerst (z.B. 100% auf 50%) passen mehrere Diagramme nebeneinander. Oder hast Du alle Charts in eine Gruppe gepackt? Dann mach mal 3 Gruppen mit je einem Chart in dem entsprechenden Tab.
Wie gehe ich (für mich) vor: Ich bastel mir die Tabs auf dem Bildschirm, den ich am meisten für die entsprechende Anzeige benutze in dem Standardzoom (z.B. 100%). Damit ich so viele Gruppen wie gewünscht nebeneinander bekomme, schiebe ich den Regler "Breite" bei den Eigenschaften der Gruppe solange hin und her bis es passt. Etwas Übersicht bekommt man, wenn man an der ein oder anderen Stelle einen Spacer einfügt.
Ich habe das Dashboard bisher immer als "Dreingabe" und Node Red selbst als "maximal aufgebohrte eierlegende Wollmilchsau SPS" verstanden. Ich würde sagen, wenn man es so richtig "schön" haben möchte, muss man Home Assistant o.ä. verwenden. Aber auch das geht wohl nicht ohne Einarbeitung und irgendwie scheint die Zeit dummerweise begrenzt zu sein...
Ich hoffe, das ist nachvollziehbar. Sonst gerne Rückfragen.
@lc625 Bingo, danke Dir!
Man kann sich beim arrangieren ja echt den Finger in der Nase brechen & hübsch isses auch nicht. Aber immerhin.
Sodele, scheint jetzt zumindest mal für einige h ohne Probleme zu laufen; mag sein, daß noch was auftaucht.
Mal ehrlich: als C-Programmierer auf Java Script zu gehen - argl ärks, was ist das denn? Ich liebe klare Typdefinitionen, ich liebe es wenn Variable nur dann verwendet werden können wenn sie zuvor definiert wurden. Und zwar genau so wie sie definiert wurden, bspw. als integer, string, aber nicht als "ja irgendwie sowas ähnliches halt eben". OK, genug gemeckert...
Meine grundlegende Strategie ist sehr einfach: ausgehend vom Mittelpreis eines Tages gibt es darüber: teuer, da wird der Ziel SOP runtergesetzt - ergo nix eingekauft. Unter dem Mittelpreis ("günstig") wird evtl. gekauft....aber in dem billigsten 4h-Block wird der Speicher vollgeknallt weil Ziel-SOC hoch. Daher diese 3 SOC Definitionen,siehe Slider.
Im Moment nur Testbetrieb, weil der SOC (50 kWh Batterie) momentan ohnehin allenfalls nach Auto laden auf 60% fällt. D.h. die Regelung kommt noch nicht zum tragen. Ich hab freilich mal rumgespielt an den Schiebereglern...das funzt. OK: nachdem es nun funzt: Java Script ist vielleicht doch nicht soo s... 😋
Programmieraufwand? Siehe Bilder...
Die Bilder sind nachts aufgenommen, daher kein Solar Ertrag. Der Mondschein reicht einfach nicht 🤔
@ginnes Wie? Kein Solarertrag bei Neumond? Ich vermute das liegt an NodeRed! Hättest Du mal alles in C gemacht...
Spaß beiseite, ich finde das echt Klasse ohne es vollständig durchschaut zu haben. Sieht so aus, daß Du aber schon die aktuellen Strompreise reinholst, oder? Mit den Reglern stellst Du ein, zu wieviel % der Akku bei welchem (relativen) Strompreis geladen werden soll? Schreibst Du das Ergebnis Deiner Logik dann über den Knoten "Deye SOC" in den Deye und da in das Untermenue "Workmode" oder über die Batteriesetting "Use Batt %"?
Ich höre jetzt mal auf. Da kommen zu viele Frage. Kannst Du die Flows als JSON zur Verfügung stellen? Da kann ich mich dann in aller Ruhe durchbeißen. Deine privaten Daten darfst Du natürlich behalten 😉 !
Aber eine Frage hätte ich dennoch: Liest / Schreibst Du die Daten über den BMS Port oder über den Modbus Port?
Nee, bisher sind es noch nicht die rellen Strompreise . Ich hole sie schon über die richtige Schnittstelle von Tibber, bekomme aber mit meinem Test-Account aktuell nur Demo-Daten - das wird dann bald anders. Den Ziel-SOP schreibe ich in die erste Zeile der Time-Of-Use, die zweite geht fest eingestellt von 00:00 bis 23:55 (mir wurscht). Die anderen sind mit 00:00 bis 00:00 disabled, siehe Bild.
D.h.: Ich muß immer nur 1 Wert auf immer dasselbe Register 166 schreiben. Um Mitternacht synce ich dann noch die Uhr.
Am Deye nutze ich den Modbus Port - dabei nur die 485-Anschlüsse nutzen, die CAN Leitungen nicht beschalten. Also Kabel basteln...hab gelesen, daß das sonst Probleme gibt.
Deye auslesen & Ziel-SOC in % schreiben und Dashboard mach ich jede Minute; beim SOC schreiben reicht eigentlich auch jede h, wenn ich aber mit den Slidern was verstelle wird es so nach 1min upgedatet.
Tibber lesen initial & dann 1 mal am Tag um 22:00, da stehen auch die Preise für morgen schon zur Verfügung; Mitternacht dann Preisliste umkopieren und Deye Uhr syncen.
Dazu gibts aktuell noch einiges an Logging und Debug-Status-Ausgaben, die ich in txt bzw. cvs Dateien schreibe...kann jeder halten wie er lustig ist.
Sonst Update:
Hier kann man sehen, daß Sonne doch besser ist als Mondschein 🤗
Ansonsten kamen noch n paar Sachen hinzu. Goldene Schleifchen.
Was ich mir noch nicht erklären kann: bei ca. jedem 10. Durchlauf bricht der Flow einfach ab. Keine Fehlermeldung, der Catch Node wird nicht aktiviert. Workaround: Wiederhole daher alle 10sec bis zum erfolgreichen Durchlauf. In ca. 90% diese Fälle reicht 1 Wdh. Nicht schön, keine Ahnung wieso, sind ja immer dieselben Daten. Will das noch verfolgen bevor ich weiter rausgebe...
Danke für's Update. dann werde ich mich noch etwas gedulden. Aber wieder etwas gelernt: Bisher wusste ich nur, dass der Deye Schwierigkeiten bekommt, wenn am BMS Port neben den CAN Pins auch noch Geplapper über die 485 Pins reinkommt. Danke für den Tipp. Nichts geht schneller als ein Kabel zu basteln um den Fehler nicht irgendwo anders zu suchen.
