Hallo Gemeinde,
habe mich dieses Jahr auch dazu entschlossen, mit dem allgemein bekannten Energiethema, endlich mal näher mit PV zu befassen.
Also habe ich begonnen, erstmal auf dem Carport (eigentlich schlechte Nord-Ausrichtung), PV-Module zu platzieren.
Da mich von vorn herein, der Preis für eine 11kWp Anlage (Südseite) ~18000€ (ohne Speicher) abgeschreckt hat, habe ich beschlossen, das ganze selber zu bauen.
12x460W Jimko Module.
16x230AH Shenzen Akkus
250er Daly BMS
5KW Victron Multiplus 2
450/100 Victron MPPT
EM Carlo Gavazzi
Cerbo GX
5A Balancer (habs nie nachgemessen, aber lt. BMS sind die Akkus 0,0x V ausgeglichen), wobei ich mir nicht unbedingt sicher bin ob es den bräuchte.
Siemens CPU 314C mit Touchpanel:
Hier lese ich die Daten Multiplus per Modbus ein und steuere meinen nachgerüsteten Heizstab im Warmwasserspeicher. 3x2KW, wobei ich bisher nur einen Strang nutze per SSR und 0-10V Ansteuerung.
Nun zu meiner Frage, hat sich schon mal einer mit der UART Kommunikation und dem BMS befasst?
Ich würde gerne die Daten auslesen und auswerten mit C#
Habe schon einen ähnlichen Fall auf Github gefunden wo jemand mit Arduino und C++ die Daten ausliesst. Aber ich habe hier noch keinen Erfolg.
Wobei ich mir nicht 100% sicher bin ob die UART Schnittstelle
1- RX
2-TX
6- GND
MfG Chef
Ich verwende den Multiplus2 als Batteriewächter. Und das funktioniert ganz plausibel. Ich habe auch das 250er Daly BMS.
6,5 kWp aufm Dach, 14 kWh mit Daly BMS 250A im Keller, Victron Multiplus II 5000, 2 x Victron MPPT 250/70, Cerbo GX, EM24
Camper mit 660 Wp und 3,5 kWh, Victron MPPT 100/50, Wechselrichter mit 2000 Watt, Senseo Kaffeemaschine, kein Gas 😀
Ich würde eben gerne die Daten aus den BMS mit aufzeichnen und auswerten,
da über die Bluetooth bzw. PC Schnittstelle teilweise die SOC zum Victron sehr driften, teilweise um 10%.
Was stimmt jetzt?
Hi,
ich hatte vor einiger Zeit auch das Vergnügen, mich an so ein BMS zu hängen. Ich habe einen USB-Seriell-Wandler (FTDI) an die Schnittstelle gehängt.
Die Belegung des BMS passt so. Beachte aber, dass du TX des BMS mit RX deines Ausleseports und umgekehrt belegen musst! (RX und TX müssen gekreuzt werden)
Also:
DALI Pin 1: RX -> FTDI TX
DALI PIN 2: TX -> FTDI RX
GND einfach durchverbinden.
Und Vorsicht, das sind 3V oder 5V Pegel, geh da nicht mit einem RS232-Pegelwandler a la MAX232 oder an einen PC-COM-Port dran! Das könnte im Entweichen des magischen Rauches enden!
Zum Protokoll:
Ich habe Antwort vom BMS auf folgendes Kommando bekommen:
(MSG-ID 90)
Request: 0xA5 0x80 0x90 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xBD
Response: 0xA5 0x01 0x90 0x08 0x01 0xD1 0x00 0x00 0x75 0x30 0x01 0xEE 0xA4
Das letzte Byte jeder Nachricht ist immer die Checksumme, in diesem Falle einfach alle Bytes der Nachricht aufaddiert und das kleinste Byte dieser Summe an die Nachricht angehängt.
Ich hoffe, das hilft dir weiter.
Lg Florian
Erstmal vielen Dank für deine Antwort.
Ich benutze einen CP2102 USB Wandler, gejumpert auf 3,3V
Die Pins sind richtig gesteckt:
Der Checksum ist gleich deinem!
Aber es kommt wie gesagt kein Response.
Ich hänge auch mal das Programm in C# ran, Visual Studio Express 2017
Der Datastring geht an den Output von der seriellen Schnittstelle, die LED auf dem CP2102 TX blinkt auch kurz.
Vielleicht hast du noch einen Vorschlag?
Wäre dir sehr dankbar.
Vielen Dank.
Hi,
ich hab grade noch mal nachgeschaut, ich hatte meinen FTDI auf 5V gejumpert. Möglicherweise sind bei 3,3V die Pegel zu niedrig...
Ansonsten würde ich zuerst mal am USB-Adapter TX und RX verbinden, um das Echo zu prüfen. Du solltest die gesendeten Daten dann als Input sehen.
Sonst wird es schwierig, fürchte ich. Der Data-String sieht soweit gut aus.
Lg Florian
Kleiner Nachsatz:
Ich hab grade mal in deinen Code geschaut und folgendes ist mir aufgefallen (ich bin kein C#-Programmierer, möglicherweise liege ich falsch):
Datei "Form1.cs", ab Zeile 78:
Wenn ich das richtig verstehe, wandelst du die Bytes in tx_buffer, die die Hex-Werte enthalten in einen String um, der die ASCII-Repräsentation der Hex-Werte ist, oder? Nach dem du die "-" und die entstehenden Leerzeichen entfernt hast, sendest du das, korrekt?
Falls das der Fall ist, liegt das Problem darin, dass du ASCII-Zeichen sendest, wo Binärzahlen stehen sollten. Ich kenne mich, wie gesagt, mit C# zu wenig aus, um dir sagen zu können, wie das geht, aber eigentlich solltest du das Array "tx_buffer", so wie es ist, ausgeben.
Lg Florian
Danke Florian,
habe jetzt mal TX und RX gebrückt. Und mit beiden Pegeln bekomme ich den String zurück gemeldet. Kommt zwar teilweise auseinander geschnitten, aber es kommt was zurück. Exakt der String.
Also funktioniert der Adapter schon mal.
Es gibt 2 Methoden bei serialport, einmal eine serialport.writeline die wirklich einen String übergibt und
eine serialport.write(Byte[] tx_buffer, int offset, int count).
Wenn ich jetzt die write Methode (mit den wirklichen Bytes im Buffer also buffer[0] = 0xA5 usw... ) benutze liefert er mir "???" zurück. Ok. Ist klar, mit serialport.readexisting liefert er ja einen String zurück.
Mit serialport.read(Byte[] rx_buffer,int offset, int count) sieht es jetzt schon anders aus und es stehen die Bytes im Empfangspuffer.
Werde es, je nachdem ich Zeit habe, morgen mal am BMS testen und natürlich berichten.
Schonmal Danke, zumindest bin ich schon mal einen guten Schritt weiter.
Bisher habe ich mich mit serieller Kommunikation noch nicht so beschäftigt.
Hintergrund ist nach wie vor, dass mir das BMS teilweise bzw. selten andere Ladezustände als der Victron liefert. Aber es fehlen dann schon mal gerne 20-30%. Auch habe ich beim Victron schon mal eine Änderung vom Ladezustand von 85% auf 93% beobachtet. Innerhalb ein paar Minuten.
Hi,
ja, write mit buffer klingt sehr viel besser. Da das BMS dir auch binär antworten wird, wird die Stringumwandlung fehlschlagen. Zu Anzeigezwecken kannst du den Buffer aber so aufbereiten, wie du es bisher für die Sendedaten getan hast.
Ich benutze für solche Basteleien ganz gerne erstmal ein Terminalprogramm um zu schauen, ob ich eine Kommunikation zu Stande bekomme. Damit kann man solche Probleme sehr viel besser eingrenzen. Ich benutze dafür gerne Terminal.exe von Br@y. Das ist schon älter und wird nicht mehr gepflegt, kann aber so schöne Dinge wie Binärdaten senden und beim Empfang als HEX-Werte darstellen. Finden kannst du es hier: https://sites.google.com/site/terminalbpp/. Binäre Daten kannst du da durch Voranstellen eines Dollarzeichens $ senden. Also sowas wie $30 = 0x30.
Tipp: die neueste Version von 2014 ist ziemlich instabil, nimm lieber die 2013er von davor, etwas weiter unten auf der Seite zu finden.
Der State-Of-Charge scheint, je nach Akkutyp, nicht so einfach feststellbar zu sein. Bei Bleiakkus korrespondiert der Ladezustand in etwa mit der Klemmspannung. Bei Li-Typen ist dieses Verhalten viel schwächer ausgeprägt, die Spannungskennlinie also viel flacher. Die knickt erst an den Enden, also bei ganz voll oder ganz leer, stärker ab. Die flachsten Kennlinien haben wohl LiFePO4-Zellen. Daher wird meist mit Coulomb-Counting gearbeitet, was sich aber erst ein bisschen kalibrieren muss.
Daher wahrscheinlich die Abweichungen und Sprünge. Im Zweifelsfalle würde ich aber auch die Daten aus dem BMS benutzen, das ist halt direkt an der Batterie dran. Aber auch das kann ein paar Zyklen brauchen, bis seine Werte passen.
Lg Florian
Hi,
also es funktioniert. Kann jetzt die Daten auslesen. Der springende Punkt war den Buffer als bytebasiert zu übergeben.
War jetzt noch etwas mit Konvertieren beschäftigt. Bekomme "165 1 144 8 2 2 0 0 117 48 1 0 0 0" zurück.
Wobei mich ja speziell die Bytes 4,5,10,11 interessieren.
Diese wandle ich nun nach HEX (4+5 und 10+11), setze sie zusammen, mache einen String daraus und konvertiere sie dann in ein int und dann eine double Zahl.
Ergibt 51,4V und 42,3%.
Der Strom ist auch speziell, hat einen Offset von 30000 😉
Vorallem bei hohen Strömen >80A aus den Akkus über längere Zeit kann hier schon einen Drift zwischen den Ladezuständen von BMS und Victron verursachen. Über die I*t Integrationsmessung.
Ich muss hier auch anmerken, dass ich mittlerweile Polfett verwende.
Habe 2 Busbars, eine 200A Sicherung. Es sind zwar nur hier (gemessene mOhm Widerstände), aber einen Spannungsabfall hast du hier definitiv!
0,001Ohm * 100A = 0,1V.
Hier macht der Strom eben die Musik. Aber ich denke auch, dass hier das BMS der zuverlässigere Ladezustandsmelder ist.