Nur zur Info, meine Arbeit basiert übrigens auf dem im Video vorgestellten Projekt. Nur das ich noch viele Sicherheits und Balance Features eingebaut habe. Zudem noch die ganze Deye Inverter Kommunikation mittels Modbus. Man kann es aber auch einfach nur als Pylontec Batterie betreiben und dann mit anderen Wechselrichtern verwenden.
@ackmaniac ich bin total begeistert was du da geleistet hast.. jedoch könnte ich mir vorstellen dass ich mir als Anfänger die Frage stellen würde was ist der Vorteil von deiner Lösung gegenüber dem neuen jk-bms das von Haus aus einen can-Bus mitbringt.
Spontan fällt mir dazu ein dass du ein verbessertes zeitgesteuertes top ballencing bietest.
Und zusätzlich noch die Daten vom deye und jk- bms dem Homeassistent bereit stellts.
Und das du alles als Open source bereit stellst...
Im Gegenzug sehe ich als Nachteil eine zusätzlichen Hardware die Probleme machen kann und dass ich deren Parameter nur über home assistant ändern kann und nicht über eine eigene Web-Oberfläche..
Vielleicht kannst du ja noch ein paar weitere Vorteil nennen.
Es ist auch über eine eigene Weboberfläche möglich. Jedoch ist diese dann nicht sonderlich schön organisiert. Funktionieren würde es aber dennoch.
Vorteile sind viele:
Die Leistung (Ampere oder Volt) wird stufenlos reduziert (auch bis 0) bei:
- Batterie zu kalt
- Batterie zu warm
- BMS zu warm
- Einzelne Zelle zu hohe Spannung
- Einzelne Zelle zu niedrige Spannung
Im Gegensatz zum BMS, welches beim Erreichen von maximalen Werten hart abschaltet, sagt der HJDC dem Wechselrichter das er die Leistung reduzieren soll, statt ihm die Verbindung zu kappen. Ich denke, dass dies die Leistungselektronik des Wechselrichters schont. Denke nicht das es gesund ist, wenn bei beispielsweise 5kW Ladeleistung das BMS spontan abschaltet.
Mithilfe des Controllers kann man die Batterie nur alle paar Tage (einstellbar) zum balancen auf 100% laden und dazwischen nur bis bspw. 90% (einstellbar). Ich beispielsweise Balance nur alle 10 Tage was in meinem Falle völlig ausreichen ist. Das sollte die Lebensdauer der Batterie verlängern.
Auch achtet der Controller das beim balancen die maximale Spannung der Zelle mit der höchsten Spannung nicht über die "Cell Overvoltage Protection Recovery (Cell OVPR)" steigt. Somit kann man neue ungebalancte Zellen einfach als Batterie anschließen und den Controller die Zellen balancen lassen. Es besteht keine Gefahr das eine einzelne Zelle eine zu hohe Spannung erreicht. Es dauert eben nur seine Zeit.
Man braucht somit nicht alle Zellen initial zusammen parallel anschließen und balancen. Man kann sich also auch das teure langsame 5V Ladegerät sparen. Sollte eigentlich auch schneller sein.
Das kann man natürlich auch nur mit dem JK-BMS erreichen. Jedoch stoppt diese die Ladung erst, wenn die maximal Zellspannung erreicht ist und schaltet bei der Recovery Voltage wieder zu.
Moin!
Wir (mein Vater und ich) sind grade dabei, eine PV- Anlage für meine Eltern aufzubauen.
Ich wollte die Anlage zuerst mit Victron Multiplus II als WR aufbauen und hatte daher auch schon das JK-BMS (JK-B2A24S20P) gekauft.
Beim WR habe ich mich nun aber doch für den Deye SUN-12K-SG04LP3-EU entschieden.
Alles in allem komme ich so einfach günstiger weg.
Aufgrund der "Kommunikationsschwierigkeiten" zwischen JK-BMS und Deye WR kommt mir der "HJDC" sehr gelegen.
Erstmal ein fettes Dankeschön für deine Arbeit und das du diese mit uns teilst!
Magst du mir mitteilen, welche Komponenten du genau verwendet hast und ob du noch eins der PCBs übrig hast?
Lötarbeiten etc. sind für mich kein Problem.
(Erster Beitrag hier, daher konnte ich dir nicht direkt schreiben...)
Beste Grüße
mwe
Weitere Daten der im Aufbau befindlichen Anlage:
Module: 34x Trina TSM-NEG9R.28 435 Wp
LiFePO4 Zellen: 16x EVE LF280K
Habe noch ein paar Sätze Platinen inklusive aller benötigten Komponenten Zuhause. Hab dir eine Nachricht geschrieben.
Moin, ist ein sehr interessantes Projekt.
Ich habe ein JKBMS und ein MPPSOLAR MPI12KW WP mit Solarassistant zusammen laufen. Drüber steuere ich im Moment den Ladestrom und könnte auch die Spannung Steuern.
Wäre es möglich deine Projekt auf mein system anzuwenden? Mein WR hat eine BMS Schnittstelle, aber ohne CAN, nur RS485. Der WR unterstütz Pylontech, Soltro und Weco Batterie systeme
Grüße
Maik
Theoretisch wäre das möglich. Jedoch kenne ich zum einen das Pylontech Protokoll mittels RS485 nicht und zum anderen wäre es auch Recht aufwendig es zu implementieren falls es stark vom CAN Protokoll abweicht. Sollte das irgendwo zur Verfügung stehen könnte man Mal darüber nachdenken.
Kannst du mir bitte auch eine PN schicken, danke
[quote data-userid="19035" data-postid="152511"]
Wenn einem die Entladeleistung von 200A (10,5 kW) ausreicht, dann ist das BMS Theoretisch ausreichend für eine 16S3P (48 Zellen) Batterie....
Somit hätte man nur eine Batteriebank mit knapp 45 kWh Kapazität. [/quote]
Wenn ich das jetzt richtig verstanden habe, Sind an EINEM BMS 3x 16er Batteriebänke ?
Wie funktioniert das dann mit den 16 Überwachungskabeln für 48 Zellen ? Gruss
3 Zellen parallel, also z.B. 3x280 Ah zu einer 840 Ah und die dann in Reihe anstatt 3 Stränge a 48V 280Ah, parallel schalten. Dann braucht man 3 BMS
Genau. Die 3 parallel verbundenen Zellen verhalten sich dann wie eine mit der dreifachen Kapazität. Es kann dann auch mit dem dreifachen lade und entladestrom belastet werden.
Aha, und warum max 3 ? Weil ab da die Grenze des BMS mit 200A schlagend wird ?
und ich kann dann nicht mehr jede einzelne Zelle monitoren, sondern nur noch den 3er Pack, richtig ?
Gruss
Es gibt da keine direkte Grenze. Man soll die EVE280K ja mit 0,5C dauerhaft betreiben können bei einer Zyklenzahl von 6000. Das sind dann 140A pro Zelle. Sie werden dabei für meinen Geschmack ein wenig warm. Weswegen ich für meinen Geschmack bei 16S2P beim dauerhaften laden etwa 135A benutze. Dann erhöht sich die Temperatur weniger als 10 Grad. Aber nur mein Gefühl sagt mir das ich die Zellen damit quasi nur massiere. Vielleicht vertragen sie auch täglichr Temperaturwechsel von 30 grad ohne Probleme. Für mich ist daher bei einem System dass dauerhaft mit 200A lädt der sweet spot bei 16S3P.
Aber das kann ich bis auf die Temperatur nicht wirklich wissenschaftlich begründen. Zudem wird bei 135A die 16S2P Batterie in 4 Stunden voll.
Übrigens werde ich bei meinem neuen Haus eine 17S3P Batterie verbauen welche ich mit einem aktiv luftgekühlten JK BMS und meinem Zusatzcontroller HJDC betreibe. Und das ist in Bezug auf Amortisation schon sehr übertrieben.
17S weil man sowieso nur bis 3,45 V lädt (58,65V) und somit etwa 13% (17/16)² geringere Verluste haben sollte.
Tolles Projekt und läuft bei mir seit ca. 4 Monaten tadellos mit dem Deye WR und einen DIY Akkublock. Alle Werte sind im Home Assistant und teilweise auch dort bequem änderbar. Eine Anregung hätte ich noch: könnte man noch die Time of Use Tabellen einfügen mit Möglichkeit zum ändern im Deye WR, so wie auf diesem Projekt: GitHub - klatremis/esphome-for-deye: Esphome component for Deye 3 phase inverters for Home Assistant ?
Der Hintergrund wäre in Verbindung mit Tibber und dem dynamischen Strompreis möchte ich meinen Akku voll laden wenn der Strompreis sehr günstig ist. Das würde ich dann gerne am PC einstellen und nicht am WR. Evtl. schaffe ich es dann auch das ganze zu automatisieren über Home Assistant.
Danke
Die Time of Use Werte sind in der konfiguration schon vorbereitet. Man muss sie in dem script nur aktivieren indem man den # entfernt.
Hier sind die dafür benötigten Werte welche ihr beispielsweise in der Datei esp32-example-can-deye-modbus_espidf.yaml Zeile 2098 bis 2342 der Github seite findet.
- platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_1
name: "${deye_name} Time Point 1 Start"
address: 148
min_value: 0
max_value: 2359
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_2
name: "${deye_name} Time Point 2 Start"
address: 149
min_value: 0
max_value: 2359
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_3
name: "${deye_name} Time Point 3 Start"
address: 150
min_value: 0
max_value: 2359
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_4
name: "${deye_name} Time Point 4 Start"
address: 151
min_value: 0
max_value: 2359
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_5
name: "${deye_name} Time Point 5 Start"
address: 152
min_value: 0
max_value: 2359
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_6
name: "${deye_name} Time Point 6 Start"
address: 153
min_value: 0
max_value: 2359
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_1_power
name: "${deye_name} Time Point 1 Power"
unit_of_measurement: W
address: 154
min_value: 0
max_value: 12000
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_2_power
name: "${deye_name} Time Point 2 Power"
unit_of_measurement: W
address: 155
min_value: 0
max_value: 12000
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_3_power
name: "${deye_name} Time Point 3 Power"
unit_of_measurement: W
address: 156
min_value: 0
max_value: 12000
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_4_power
name: "${deye_name} Time Point 4 Power"
unit_of_measurement: W
address: 157
min_value: 0
max_value: 12000
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_5_power
name: "${deye_name} Time Point 5 Power"
unit_of_measurement: W
address: 158
min_value: 0
max_value: 12000
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_6_power
name: "${deye_name} Time Point 6 Power"
unit_of_measurement: W
address: 159
min_value: 0
max_value: 12000
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_1_capacity
name: "${deye_name} Time Point 1 Capacity"
unit_of_measurement: "%"
address: 166
min_value: 0
max_value: 100
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_2_capacity
name: "${deye_name} Time Point 2 Capacity"
unit_of_measurement: "%"
address: 167
min_value: 0
max_value: 100
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_3_capacity
name: "${deye_name} Time Point 3 Capacity"
unit_of_measurement: "%"
address: 168
min_value: 0
max_value: 100
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_4_capacity
name: "${deye_name} Time Point 4 Capacity"
unit_of_measurement: "%"
address: 169
min_value: 0
max_value: 100
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_5_capacity
name: "${deye_name} Time Point 5 Capacity"
unit_of_measurement: "%"
address: 170
min_value: 0
max_value: 100
mode: slider
step: 1
value_type: U_WORD
entity_category: config - platform: modbus_controller
use_write_multiple: true
modbus_controller_id: modbus_deye
id: deye_Time_point_6_capacity
name: "${deye_name} Time Point 6 Capacity"
unit_of_measurement: "%"
address: 171
min_value: 0
max_value: 100
mode: slider
step: 1
value_type: U_WORD
entity_category: config
Aktell scheint es Probleme mit der neuesten version von ESPHome zu geben. Wenn man ESPHome in Home Assistant updated schlägt Home Assistant auch immer vor den HJDC Controller zu updaten. Tut dies bitte vorerst nicht da dann scheinbar die Kommunikation nicht mehr zu funktionieren scheint. Ich analysiere gerade ein workaround und halte eauch auf dem laufenden.
Ich habe eine Growatt Welt von Wechselrichtern oder fast auch Flotte, die von SPH 4600 Hybriden bis MIN 4600 und MIC 3000 reicht, weil historisch so gewachsen aus einer kleinern 10 kWp auf eine am Ende irgendwann 30 kWp und auch, weil nur der SPH 4600 eine DIY 48V 16S LFP Batterie zulässt, da alles größeren Varianten von Growatt auf HV umgestellt worden sind.
Ich wollte jetzt ein neues JK Inverter BMS bestellen und bin über Andy Offgrid Garage und Peter Board irgendwann und irgendwie hier gelandet, hab mir das 2x durchgelesen und das Video geschaut, so dass ich grob eine Ahnung habe.
Growatt hat / kann CAN Bus und RS485, ich wollte das JK Smart Inverter BMS mit RS485 & CANBUS & HEAT Function bestellen.
Passt das so weit zu dem, was Du bisher vorgestellt hast, wenn ich das das JK BMS und den Wechselrichter auf Pylon Protokoll einstelle ?
Oder ist das meilenweit davon entfernt und auf Sicht nicht zu erwarten, dass ich das auch nutzen könnte?
Ich habe 2 SPH 4600 Hybriden mit je 1x SEPLOS MASON DIY Boxen mit 16S und 280 Ah EVE LF280K , die beide JK Smart Inverter BMS bekommen sollen.
Beide System laufen 51,2 V 16S mit max. 66 A Lade / Entladestrom (ca. 3.000 kWh)
Ich meine, dass ich die Growatt CanBus Protokolle irgendwo mal gesehen und gleich gesichert habe und zwar in 2 Versionen.
Ich find das Projekt jedenfalls recht spannend und würde das gern nutzen können.
Danke Dir schon mal vorab
Da musst Du doch immer beim BMS und desse Specs nachschauens. Da wird doch auch ein Limit für die parallelen Zellen vorgegeben wie auch der maximale Strom.
Bei 3 Pack mit 15 kWh hast Du ja an einem Wechselrichter eh den Engpaß. Ich weiß nicht, wo der bei Deye liegt, aber ich meine , dass die EVE Zellen ihre Zyklenfestigkeit behalten, wenn mit max. 0,5C entladen wird, also bei 3 Stück davon dann 3x 140A = 520 A
Das wären grob 25 kW rein und raus, keine Ahnung, ob Deye das kann.
Ist gewaltig viel, aber fast nix, sobald einer eine 22 kW AC Ladesäule hat und auch seinem 45 kWh Akku jetzt mal eben noch vollmachen muss.
Da jucken Speicherverluste von 20% oder mehr nicht, wenn im Akku PV Überschusstrom eingelagert worden ist, denn dann sind das selber bei 20% auch nur 0,10 € je kWh, die da fällig werden und sicher 30 Cent weniger als Ladestrom unterwegs und 20 Cent weniger als vom Netz.
@wolfgang ich vermute das es auch mit deinen Hrowatt Wechselrichtern funktionieren würde wenn sie das Standard pylontec Protokoll verstehen. Damit könntest du die meisten meiner Features nutzen. Das auslesen des Großwatt Wechselrichters selbst und übermitteln der Daten von diesem an Home Assistant ist dann natürlich etwas anderes.
Wenn du es auf einen Versuch ankommen lassen möchtest kannst du mir gern eine PM schreiben.
Hey @Ackmaniac!
Danke für das Tolle Projekt. Ich nutze den zwar nicht, aber das kann als Grundlage für mein Projekt dienen.
Meine Idee:
Ich werde bald 2x 280Ah Batterie Packs mit je JK Inverter BMS haben. Man könnte meinen diese sprechen ja mit dem Inverter direkt, das will ich aber nicht ganz, sondern ich will die mögliche Lade/Entladestromstärke manipulieren können.
Die Idee dahinter:
-
Ich will weder im BMS noch im Deye WR die Flash-Schreibzyklen verbrauchen
-
Meine Idee könnte super einfache Lösung für viele WRs sein, um z.B. PV gesteuert den Akku zu laden
-
Ich will also in der dem 0x351 Telegramm die 2x Stromstärken so verändern wie es mir gerade passt:
3a) wenn ich Charge Current auf 0 stelle, dann wird WR nichts mehr in den Akku laden, als ob Akku voll wäre.
3b) ich kann aber auch Stromstärke zwischen BMS Vorgabe und 0 empfangen und dem WR kommunizieren und so z.B. nicht schon morgen früh den Akku vollladen sondern erst zum Mittag und dann nicht mit voller Stromstärke (HA oder wer auch immer muss es halt steuern). Vorteil: es ist nicht die harte Abschaltung als ob man im BMS das Laden verbietet, sondern WR regiert eher langsam auf die Veränderung. Man könnte aber auch langsame "runterfahren" auch einbauen.
Also praktisch: esphome-jk-bms-can/esp32-example-can-deye-modbus_espidf.yaml at main · Ackmaniac/esphome-jk-bms-can · GitHub
3c) Genauso beim Entladen. Hier könnte man im Winter die Entladung des Akkus je nach Börsenstrompreis steuern (bei niedrigen Preisen Entladung sperren, bei hohen erlauben)
3d) bei Victrons habe ich mitgekommen, dass auch Voltage evtl. um 0.2V höher kommuniziert werden muss, damit die MPPTs die Verluste in der Leitung richtig kompensieren können.
-
evtl. noch das Telegramm mit "Force Charge" auch extern steuern, das könnte bei negativen Strompreisen nützlich sein.
-
alle anderen Telegramme werden weitergeleitet.
Hardware ist als "Zwischenstecker" oder "Man-in-the-Middle" gedacht, wird also 2x RJ45 CAN Buchsen haben, für WR und BMS und so alle Pylontech sprechende BMSe und WRs steuern. Dafür habe ich mir ESP-C6 bestellt, er hat 2x CAN on Board, nur die Transceiver werden gebraucht. Leider kann ESPHome mit beiden CANs beim C6 noch nicht umgehen.
Als Bonus:
a) eine RJ45 Buche gleich mit RS485 vorsehen und Deye auslesen (das wird wohl eher Deye spezifische Geschichte sein)
b) BMS Daten entschlüsseln und an HA senden.
c) laden nur bis 90% und alle paar Wochen doch auf 100% zum Balancen
Nun Fragen:
Wenn ich richtig verstanden habe, machst du CAN-Magie direkt im Yaml und External-Component ist nur für JK-BMS Protokoll gedacht, oder?
Hast du evtl. Beispiel wie ich ein CAN-Telegram empfange und gleich weitersende? Oder muss ich "Zwischenspeichern" und in bestimmter Reihenfolge versenden?
Oder ist es einfacher die Daten zu dekodieren, da ich die für HA so oder so brauche, und dann wieder zu CAN-Message übersetzen (das könnte ich bei dir klauen)? Nur so bin ich auf "bakannte" Telegramme beschränkt.
Ich habe mal meinen Deye-Akkus beim CAN-Kommunizieren zugehört, die senden Daten wild durch einander auch wenn WR gar nicht mit 0x305 abfragt... Das ist aber ein modifizierter Pylontech Protokoll deswegen bin ich mir nicht sicher.
