Habe HA, Deye 12k und 6x Pylontech US3000C. Ich kann aus dem Deye die Register bis ca. 650 auslesen/schreiben (über DSUB-Stecker (LSW oder LSE oder RS232/Modbus) oder RJ45-Buchse (RS485/Modbus)). Habe dazu die Integration von StephanJoubert verwendet und geändert/erweitert.
Aus den sechs Pylontech-US3000C kann ich die Werte einzelner Batterien auslesen (über RJ45-Anschluss der ersten Batterie (B/RS485/Modbus)).
Die Daten beider Gerätetypen kann ich in HA anzeigen/auswerten.
Wollte jetzt die Verwendung zweier Umsetzer vermeiden und die Batteriedaten aus dem Deye holen. Die Register oberhalb von 10000 konnte ich über RJ45/RS485/Modbus nicht auslesen. Über DSUB/RS232/Modbus konnte ich die Register 10000 bis 10031 mit stimmigen Werten auslesen. Die nachfolgenden Bereiche enthalten bei mir allerdings nur Nullen.
Daher die Frage: gibt es einen Weg, über nur eine technische Schnittstelle an die Daten von Deye UND Batterien zu kommen (RJ45/BMS/CAN habe ich noch nicht probiert z.B.)? Oder eine zweite Frage: werden die Register für die Batterien in der Konstellation grundsätzlich nicht verwendet?
Seit dem letzten Firmware-Update klappt die BMS-Kommunikation nicht mehr. Könnte ich wohl zurecht fummeln, aber will ich das? Reagiert der Deye, wenn 1 von 3 Akkus ausfällt? Oder sollte ich das lieber über Home Assistant steuern, indem ich die Akkus einzeln über BT eingebunden habe? Wäre dazu nicht eine Zelldrift-Auswertung in HA besser um den (Ent-)Ladestrom zu steuern?
oh oh, mehrere Packs und keine BMS Verbindung ist unvorteilhaft. Wenn ein oder zwei Pack ausfallen, sind ja 1/3 oder 2/3 nur noch Ladeleistung möglich, woher soll der WR das wissen? Könntest mit HA auch setzen, aber das wäre mir zu unsicher... stell dir vor, der WR ballert mit 240A auf einen Akku...
Wenn die Verbindung BMS-WR sauber läuft, reduziert der automatisch den Strom und bei OV Warnung senkt er noch weiter ab.
Aus diesem Grund gilt: mehrere Akkus am WR ohne aktives BMS, also am WR zB. den AGM Spannungsmodus eingestellt, das man dort die Werte so einstellen sollte als ob nur ein einziger Akkupack angeschlossen ist. Und dann die Maximalwerte des kleinsten Akkupacks. Wenn man also 2 Packs dran hat und beide können für sich mit 100A geladen/entladen werden dann sollte man am WR auch nur 100A Ent-/Ladestrom einstellen. Mehr nicht. So kann der WR nicht die Akkus überlasten und alles bleibt sicher. Hält man sich nicht daran und stellt zb. 200A ein, weil man ja zwei Akkus a 100A in parallel betreibt, dann hat man im Falle des Ausfalles eines Akkus eine Fehlerkaskade zu befürchten. Dh. der zweite Akku schaltet sich auch wegen Überlastung durch den WR ab. Am Ende hat man also einen fehlerhaften Akku und einen überlasteten Akku die beide sich abgeschaltet haben und am WR hat man nun keinen Akku mehr am Laufen.
Na ja, nicht sinnvoll, aber wenn du das so machst, deine Entscheidung.
Warum soll man das stroh dumm betreiben, wenn das BMS und der WR es besser können?
Die Kommunikation funktioniert prinzipiell mit den Komponenten, fällt die Kommunikation aus, geht erst mal nix, was der Sicherheit dient.
Dem werde ich nicht widersprechen Meine Erklärung sollte nur zeigen wie man es machen könnte wenn man auf den "Luxus" eines BMS und Kommunikation mit dem WR verzichten will. Viele "Experten" meinen das sie im AGM Modus des WR trotzdem die Akkus mit voller Leistung nutzen können. Das dies falsch ist wollte ich nur klarstellen.
Ich widerspreche auch nicht, habe aktuell aber nicht die Zeit, zu analysieren, warum die neue Firmware (2005-1151-1807, 1001-C04D) nicht mehr LiBMS 'versteht'. Diese Kontrollinstanz fehlt natürlich.
Die Sicherheit ist trotzdem gegeben: Im Deye sind 150A (Ent)Ladestrom eingestellt. Die 3 Packs von Yixiang haben den JK-Inverter mit 200A, eingestellt auf max. 150A. Bei LF280k-Zellen gerade mal 1/2C. Da können sogar 2 Packs ausfallen ohne das Überlast entstünde.
Die eigentliche Überlegung ist, die Ladeströme anhand der Zelldrift zu regulieren. Bei jeder meiner 3 Yixiang-Boxen driftet immer Zelle 9 davon (konstruktionsbedingt??). Bei 2 Packs deutlich, bei 1 minimal aber sichtbar. Je größer der Strom desto größer die Drift. Die Drift explodiert gerade zu von 50mV auf > 100mV wenn man in Richtung 3,4V bzw. 3,1V ankommt. Ich bin mir nicht sicher, was der Deye letztlich über die BMS-Kommunikation wirklich regelt (nehme gerne Links dazu aber ich bezweifle, dass er auf Zelldrift reagiert. Deswegen denke ich eher daran, über HA-Automation die Ladeströme zwischen 0 und 150A abgestuft anhand der Zelldrift anzupassen. Sonst komme ich nie ins auf 100% SOC/RVC.
Zelle 9 ist diejenige die am unteren Querverbinder liegt und dort am Querverbinder gemessen wird. Also linke Seite 8 Zellen in Reihe, rechte Seite 8 Zellen in Reihe und beide Reihen an der 9'ten Zelle querverbunden. Also dort bei der nächsten Öffnung des Akkus mal nachziehen und schauen ob das BMS Kabel richtig sitzt.
Das mit der Zelle 9 habe ich auch festgestellt, aber nachziehen hat nicht geholfen... der Widerstand Zelle 8/9 ist höher als bei den anderen... werde die Zelle mal messen, aber da die Zellen eh umziehen in ein anderes Blech werde ich dort das ganze mal beobachten und analysieren. Aber viele haben das Problem an Zelle 9 mit der Drift... Das ist ja auch die Stelle, die vom BMS doppelt gemessen wird, warum auch immer die das dort doppelt messen.
Hallo Grüß euch,
der beitrag ist ja schon ganz schön lang.
Bis vor 13 tagen hab ich mein HA mit daten aus dem deye über den Rs48-ttl ESP32 Adapter gefüttert. Bis dahin liefs problemlos da ich den solarmandongle eigentlich weg haben wollte.
Der Provisorische Bastelentwurf liefert aktuell viele CTC fehler so das ich den Rs TTL adapter tauschen möchte aber das dauert da ich momentan nicht hinkomme.
Ich hab mir nun diese Sunsynk Addon im HA von Keller installiert was auch ganz flott (in minuten abständen oder mehr) die Daten bereitstellt.
Doch ich habe hier trozdem fehler.
das Addon Startet und läuft nach einer zeit kommt dann
sowas
06:10:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
06:15:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
06:18:46 ERROR Error reading: CRC validation failed. (retry 1)
06:25:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
06:30:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
06:35:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
06:38:46 ERROR Error reading: CRC validation failed. (retry 1)
06:40:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
06:45:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
06:47:40 ERROR Error reading: CRC validation failed. (retry 1)
06:48:31 ERROR Error reading: CRC validation failed. (retry 1)
06:56:40 ERROR Error reading: CRC validation failed. (retry 1)
07:00:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
07:00:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
07:00:45 ERROR Error reading: CRC validation failed. (retry 1)
07:05:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
07:10:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
07:15:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
07:15:50 ERROR Error reading: CRC validation failed. (retry 1)
07:15:52 ERROR Error reading: CRC validation failed. (retry 2)
07:25:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
07:43:00 ERROR Error reading: CRC validation failed. (retry 1)
07:45:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
07:50:00 ERROR (2 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
07:59:45 ERROR Error reading: CRC validation failed. (retry 1)
08:10:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
08:17:46 ERROR Error reading: CRC validation failed. (retry 1)
08:20:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
08:23:55 ERROR Error reading: CRC validation failed. (retry 1)
08:27:55 ERROR Error reading: CRC validation failed. (retry 1)
08:28:50 ERROR Error reading: CRC validation failed. (retry 1)
08:30:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 18 registers from 0 poll_need_to_read
08:30:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
08:35:00 ERROR (1 in 5 min) OSError in callback read_deye: timeout reading 1 registers from 0 poll_need_to_read
08:38:55 ERROR Error reading: CRC validation failed. (retry 1)
08:38:57 ERROR Error reading: CRC validation failed. (retry 2)
08:45:45 ERROR Error reading: CRC validation failed. (retry 1)
08:45:47 ERROR Error reading: CRC validation failed. (retry 2)
08:57:00 ERROR Error reading: CRC validation failed. (retry 1)
Kann sich wer einen reim drauf machen?
und wie bekomme ich unnötige Sensoren Raus und Nötige da in die Integration:)
ich bin für jede Hilfe dankbar
schöne grüße
Conci
Eben. Da ich das Problem an 3 Boxen gleichzeitig sehe (unterschiedlich stark, aber immer Zelle 9) , denke ich, dass das konstruktionsbedingt ist. Den Querschnitt von 25mm² zwischen 8 und 9 werde ich mal bei Zeiten vergrößern. Versuch macht kluch ':O)
Hallo,
sorry , habe keine Ahnung wo soll ich mit meine Frage hin,
Habe ein Problem, aber nicht mit der App, da wird alles korrekt angezeigt und ohne Unterbrechungen, Problem ist oder bei Home Assistant (Einstellungen?) oder Server bei Deye Cloud App, zu Problem: es gibt seit ca. 1 Monat immer wieder Unterbrechungen im Datenverkehr zwischen App Server und solarman/ Home Assistant, auf ein Mal zeigt alles, was zu deye gehört in Home Assistant als „unbekannt“, aber jedes Mal nach 00:00 Uhr funktioniert wieder einwandfrei, nach langer Suche habe eine verdächtige Stelle gefunden, wenn Tagesproduktion erreicht 99-100kwh an diesem Tag, gibt's sofort eine Unterbrechung von Datenverkehr, (vielleicht auch ein Zufall, aber das ist das einzige was ich gefunden habe), wenn Tagesproduktion nicht erreicht 100kwh, dann gibt's auch keine Unterbrechungen.
Hallo zusammen, ich nutze die HA Integration “ha-solarman” von David Rapan.
Bin kürzlich vom WLAN-Logger auf die Modbus-RTU-Verbindung über TCP (Waveshare) umgestiegen und jetzt habe ich ein kleines Problem. Ich kann die Entitäten für die einzelnen Batterien nicht mehr auslesen (ich habe 4 Deye SE-G5.1 Pro-B). Alle anderen Entitäten funktionieren einwandfrei, und zb. der Gesamt-Batterie-Ladezustand (SOC) wird ebenfalls angezeigt.
Zuvor konnte ich über den WLAN-Logger die Batterie-Entitäten ebenfalls auslesen.
Ich bin mir nicht sicher, ob es nur ein Einstellungsfehler ist, oder ob über die Modbus Verbindung evtl. weniger Daten gesendet werden als über den WLAN-Logger vorher. Ich meine irgendwo weiter oben etwas davon gelesen zu haben.
Die Register für die Batterie liegen im Bereich ab 10.000. In diesem Forum wurde bereits berichtet, dass die Register nur über RS232 und nicht über RS485 erreichbar sind. Dein Waveshare benutzt die RS485-Schnittstelle, der WLAN-Logger hingegen die RS232-Schnittstelle.
Ich bin mir nicht sicher, aber ich meine, jemand hat schon berichtet, dass er es über die RS485-Schnittstelle geschafft hat, die Register über 10.000 auszulesen.
Schade, die Befürchtung hatte ich schon. Deine Beiträge zu dem Thema habe ich schon gelesen, ich hatte die Hoffnung, dass in der Zwischenzeit evtl. eine Lösung dafür gefunden wurde.
Es ist keine super wichtige Funktion für mich, aber grundsätzlich finde ich es schon gut die einzelnen Akkupacks genau auslesen und beobachten zu können.
Eine Frage, wenn man den Deye per Modbus RTU über RS485 ausliest - kann man zeitgleich auch den WLAN Logger über RS232 weiter verwenden um damit die Daten an die Deye Cloud zu senden? Dort konnte man nämlich die einzelnen Akkus auch auslesen.
Oder lässt der Deye nur die Kommunikation über eine Schnittstelle zu?
Ich habe einen 20K Deye und würde den auch gerne in HA einbinden auslesen und Steuern ich würde das ganze noch mit den 3 JBD BMS kombinieren .
Woran scheidert es aktuell ich fimnde nichts wo ein 20K in HA auszulesen ist.
Meine Erklärung sollte nur zeigen wie man es machen könnte wenn man auf den "Luxus" eines BMS und Kommunikation mit dem WR verzichten will. Viele "Experten" meinen das sie im AGM Modus des WR trotzdem die Akkus mit voller Leistung nutzen können. Das dies falsch ist wollte ich nur klarstellen.
vergrößern. Versuch macht kluch ':O)