Ein sehr netter Programmierer hat mir die SEPLOS- und JK-BMS-Unterstützung in sein HA HACS Addon "BMS_BLE-HA" eingebaut.
Vorausgesetzt man hat BLE auf dem HA oder ein esp32-bt-proxy, werden alle BMS automatisch gefunden und identifiziert und können einfach mit einem Klick in den HomeAssistant integriert werden.
Großer Vorteil für alle Besitzer mehrerer Seplos Packs: Man kann sogar die Zellspannungen von der Masterbox ablesen! Dafür gab es bisweilen kaum eine simple Lösung.
PS: Zum Zeitpunkt des Schreibens dieses Artikels muss man noch die Beta v1.11 herunterladen, aber ich bin sicher, dass die Änderungen bald in einer offiziellen Version enthalten sein werden.
Hmm, stimmt so nicht ganz. Wenn man seine Packs nicht über CAN sondern RS485 mit je einem RS485 zu USB Adapter am Cerbo oder VenusOS anbindet und den dbus.serialbattery Treiber samt Battery-Agregator nutzt hatte man auch alle Zellspannungen
Aber die Variante über BLE ist sicher auch ganz brauchbar auch wenn ich persönlich der Meinung bin, wer Funk kennt nimmt Kabel.... zumindest dann, wenn es um sicherheitsrelevante Steuerungsaufgaben geht.
Darum meinte ich: "kaum eine simple Lösung".
Klar, mit div. HW-Adaptern zu jeder Box separat kann man das schon realisieren.
Bzgl. Funk bin ich bei dir.
ABER: Die Sicherheitsrelevanten Infos (Limits, Alarme,etc.) gehen bei mir auch über ein RS485-Kabel vom Master zum WR.
Die einzelnen Zellenspannungen sind eher für die Statistik, daher m.M.n. nicht sicherheitsrelevant und daher auch schön über BLE auszulesen. Vor allem im HA macht sich das alles recht schön.
Ich habe unter HomeAssistant das BatMon AddOn getestet. Dieses arbeitet ebenfalls über BT mit 2x JK-BMS (Inverter Version) zusammen. Aktuell nutze ich aber eine ModBus YAML Integration meiner Akkus die per RS485 Kabel angebunden sind. Soweit zu den Grundlagen.
beide Varianten sind bei der Parameterabfragen identisch, gleichwertig
BatMon ist einfacher zu installieren, mit ModBus und YAML muß man sich einarbeiten
BatMon ist wesentlich instabiler, störanfälliger und deutlich langsamer bei der Aktualisierung der Daten
die YAML Lösung benötigt kein AddOn oder so
die YAML Lösung läuft absolut stabil mit 15 Sekunden Abfrageintervall (geht auch schneller)
Fazit: wenn man auf eine BT Variante verzichten kann, dann sollte man dies auch. Ich habe damit nur schlechte Erfahrungen gemacht. Allerdings ist es eine Click&Run Lösung. Mit der HA ModBus->RS485 Lösung arbeitet man am stabilsten und schnellsten hat aber eine deutlich größeren Aufwand sich in HA + ModBus + YAMl usw. einzuarbeiten. Am Ende lohnt es sich aber in mehrfacher Hinsicht.
"port" ändern auf den an dem dein USB-RS485 Adapter hängt
wenn du einen TCP/IP -> RS485 Adapter benutzt melde dich nochmal oder lies die Doku der "ModBus Integration" im HA-Wiki nach.
Ich benutze den Weg über die "Packages" da man so in einer einzigen YAML Datei alle Topics ansprechen kann. HA merged das mit den anderen Packages und den Basiskonfigurationen und zb. scripts.yaml, configuration.yaml usw.
Dein Hinweis auf Sensors.yaml suggeriert das du das noch nicht wusstest.
Dh. in meiner nachfolgenden YAML findest du alles, auch die Senoren, Automationen usw. also alles in einerm File,
rechts im Screenshoot siehst du wie das Dashboard aussehen könnte.
Beim Master Akku ist das Panel für die Zellspannungen und den Schaltern sichtbar, beim Slave-Akku links ist es unsichtbar.
Falls daran Interesse besteht dann müssen wir aber einen ausführlichen Kurs machen da HACS + git Account + einige Community AddOns installiert werden müssen
Perfekt. Nein, Packages hatte ich noch nicht auf dem Radar, Danke für den Hinweiß und die Datei. Werde dies WE integrieren versuchen. mit zuerst over RS485 to usb und im Endausbau mit RS485over TCP/IP
Perfekt, und schon sind die Sensoren per Modbus drin. Gute Anleitung, Ich hoffe Rest folgt bei Gelegenheit. Danke.
Schönes Dashboard. Gerne, HACS und Github Account bereits vorhanden. Bin lernwillig, da kein Developer.
Du hast die Anbindung schon fertig? Also du siehst schon die Entitäten des Akkus?
Wenn ja, machen wir weiter mit dem Dashboard. Du kannst aber auch erstmal einen normalen vertikalen Stack nehmen und darin alle Sensoren des Akkus hinzufügen, zum Vergleich mit dem späteren Dashboard.
Wenn es geht ändere erstmal nichts an den Namen der Entitäten, so können wir später einfach meine YAML für das Dashboard importieren und es geht alles sofort.
Ja, die Integration hat in paar Minuten funktioniert, hast ja gute Vorlage geliefert.
Kämpfe noch etwas mit der Verkabelung RS485toEth und mit modbus IDs.
Wenn dies stabil läuft, dann schaue dein Dashboard an.
Frage zu deiner Datei:
Aus welchem Grund, hast du die einzelnen Zell Spannungen zusammengefasst und nicht als einzelne Sensoren aufgenommen? Ich habe schon ein umfangsreiches Dashboard, was auf dem add-on Batmon aufbaut. Das würde ich gerne auch beibehalten, wegen Woman Acceptance Factor.
Warum verwendest du „slave: 0“ bei jedem sensor? Wäre es nicht einfacher dies in Modbus Config einmal zu definieren?
Welchen Sinn hat der der Sensor „Battery 1 password“? Ich habe den entfernt. Mag keine Passwörter im Klartext rumstehen.
Überlegst du noch die Sensoren in MQTT zu publishen?
weil dann die ModBus Integration 16x eine ModBus Abfrage sendet statt nur 1x, wie bei meiner Lösung. Durch die dann zeitversetzte Abfrage bekommst du "unlogische" Werte bei der späteren Visualisierung wenn das System balanciert. Ich hebe ja, wie bei der Handy-App, die Zellen farblich hervor die gerade beim Balancieren ausgeglichen werden. Aus Sicht der ModBus Kommunikation ist es immer besser wenn man ganze Blöcke von Registern in einem Rutsch ausliest.
Aus dem String mit den 16 Spannungen extrahiere ich in dem YAML später als Template Sensoren die 16 einzelnen Spannungen als einzelne Sensoren. Insofern geht deine Visualiserung doch schon Nur Sensor-Namen anpassen.
Geht nicht anders nach meinem Kenntnisstand. Ich habe mich an die Doku bei HA gehalten. Wenn das anders ginge, eventuell mit "globalen Variablen" dann wäre das super. Anderseits: früher in jungen Jahren hätte ich mich stundenlang an diesem Thema aufgegeilt, heute nehme ich den Editor und mit "Suchen&Ersetzen" ändere ich den Kram in 30 Sekunden auf eine andere Slave Adresse, fertig.
Das Passwort ist Augenwischerei beim JK-BMS. Über BT wird es im Grunde garnicht benötigt um die Daten abfragen zu können. Ergo: BT ist bei mir aus Sicherheitsgründen immer ausgeschaltet am BMS. Und so kann ich es nicht vergessen wenn später mal Updates über Windoof eingespielt werden müssen oder ich über BT bestimmte Parameter ändern möchte. Man benötigt heute einen Passwortsafe bei der Anzahl der Passwörter. Wenn du es nicht möchtest dann kommentiere das aus
Nein, wozu? Ich arbeite nur mit Home Assistant und ansonsten benötigt kein anderer externer Client diese Daten. Wie du im YAML am Ende sehen kannst protokolliere ich mit dem HA-Recorder auch nur die wenigsten Werte. Das kostet nämlich Datenbank Performance wenn man unnötige Werte speichert. Mit MQTT, was technisch möglich wäre, und Nutzung der Mosquitto MQTT Broker Integration protokolliert dann der HA-Recorder sogar doppelt, einmal die Daten wie jetzt und die dann noch vom MQTT Broker.
Was muß ich mir unter ModBus IDs vorstellen? Die Slave Adresse stellst du ja sowieso am Master-BMS auf 0, das musst du sowieso spätestens wenn du weitere Akkus anschließen willst. Nur beim Update der Firmware musst du das auf 1 usw. stellen.
der einzige Wermutstropfen ist das man in HA kein Device/Gerät anlegen kann. Man muß also über alle Sensoren zum Akku als Entität einzeln zusammen suchen statt über die Filterung nach einem Gerät zu suchen. Vielleicht bessert HA in Zukunft noch nach.
Hallo,
ich habe es mittlerweile auch geschafft das BMS auszulesen.
Wie wird die zweite Batterie ausgelesen ?
Was muss alles für das linke Bild mit der schönen Übersicht installiert werden.
HACS mit Github läuft bereits?
Danke
diesen per RS485_1 einbindest in HA wie den ersten Akku
diesen per RS485_2 mit dem RS485_2 des Master-Akkus verbindest, an dem ja CAN-Bus am WR hängt
dem Master-Akku die Adresse 0 -> DIP alle auf OFF, stellst
dem Slave-Akku die Adresse 1 gibst
das Battery_1.yaml in kopierst und in Battery_2.yaml umbenennst
in Battery_2.yaml durch Suchen&Ersetzen von "Slave: 0" nach "Slave: 1" änderst
in battery_2.yaml alle Entitäten von Battery_1 nach Battery_2 änderst, Suchen&Ersetzen
je nachdem ob du beide RS485_1 Ports der Akkus seriell als Bus oder individuell an deinem RS485 Adapter angeschlossen hast musst du noch die PORT Adresse in der YAML ändern. Falls jeder Akku seinen eigenen RS485 Port am HA-Server bekommen hat musst du dort PORT in der YAML ändern. Ansonsten nicht. Die serielle Konfiguration als RS485 Bus habe ich bei mir aber nicht und somit noch nicht getestet.
BEACHTE: mit Homeassistant Version 25 wurde pymodbus Integration geändert. ModBus Geräte mit Slave Adresse 0 können nicht mehr schreibend benutzt werden. Das liegt an einer sinnfreien ModBus Protokoll Interpretation bei der ein schreibender Zugriff auf Slave Adresse 0 ein Broadcast an alle am Bus angeschlossenen Geräte auslöst. Einen Bedarf für sowas habe ich noch nie gehabt oder irgendwo gesehen. Das führt aber dazu das man die JK-BMS Akkus nicht mehr schreiben kann per ModBus, da JK wiederum zwingend die Adresse 0 am Bus für den Master-Slave-Betrieb verlangt. Echt blöde. Ich benutze deshalb HA v25 noch nicht und werde das erst noch austesten müssen. Insofern: die Funktionalität meiner "Integration" die Balance/Charge/Discharge/Float Mode Buttons kann für den Masterakku nicht mehr funktionieren.
Ah, soweit zum Akku.
In HA benötigst du die SunSynk-Integration des Wechselrichters, den du auch per RS485 an HA angebunden hast. Gehe hier hin:
und lese dich dort ein über die Installation, oder auf GitHub:
Alle Entitäten die mit SDM630, SPM02 und Growatt zu tun haben musst du ändern auf diejenigen die die SunSynk Integration zur Verfügung stellt.
Ich benutze den Eaton SDM630 mit HA da dieser genauere Werte liefert als der Deye
ich benutze SPM02 ZigBee 3-Phasen Sensoren in meiner Hausunterverteilung, da diese ebenfalls genauer sind als der Deye und weil ich zwei komplett getrennte Hausnetze habe, eines für Ersatzstrom und eines für Netzstrom (umschaltbar)
Growatt ist meine ESPHome Integration meine µWR voim Schuppen. Dort habe ich den Shine-Wifi-X WLAN Stick mit ESPHome geflasht.
Letztendlich wirst du das Prinzip dieser Card eh schnell verstehen und anfangen damit zu spielen. Das Ding kann echt viel.
Nun benötigst du in HACS
Mushroom
Bubble Card
Multiple Entity Row
Stack In Card
Waves
Du gehst in HA in die HACS Integration und suchst nach obigen AddOns und installierst sie. Ich glaube du brauchst zwingend nur 3. und 4.
5. ist ein Theme für HA, dieser blaue Hintergrund und die leichte Transparenz der Cards.
visibility:
- condition: user
users:
- 541919ad78e8431aa587ce1a482b6c56
Das musst du ändern. Einfach eine andere card anlegen und die Anzeige Konditionen auf deinen USER setzen. Dann im YAML Modus der Card die ID kopieren.
Wenn du nämlich dieser USER bist dann kannst du auf das Akku-Symbol klicken und dann erst siehst du die Zellenspannungen und die Buttons um den Akku zu steuern.
Dann obigen YAML nehmen und Battery_1 durch Battery_2 ersetzen und zweite Card erzeugen.
Uff, bei Fragen, die kommen werden, einfach fragen
PS: keine Ahnung warum mal die YAML's korrekt formatiert werden und andere YAMLs wieder nicht.
Und du brauchst auch noch einen MQTT Broker. Am einfachsten ist der integrierte Mosquitto Broker, als Integration. Das SunSynk AddOn arbeitet per MQTT.
Ich werde später Mosquitto bei mir wieder deinstallieren und einen Linux Container in meinem Proxmox Server benutzen. Also MQTT Broker aus HA entfernen. Das habe ich schon mir meinen vier ZigBee2MQTT Server so gemacht da ich nicht möchte das zuviel zentralisiert in Home Assistant integriert wird. Gleiches gilt für meine Frigate + rtc2go + Google Coral TPU + SIP Gate Server. Auch diese laufen losgelöst von Home Assistant und übernehmen meine Überwachsungskameras + Doorbell + lokale Personen/Katzen Erkennung.
Danke für die ausführliche Antwort,
mir ist aufgefallen dass der battery_1_current überhaupt nicht mit dem Strom zusammenpasst der im Victron angezeigt wird, dieser wird über CAN Bus vom JK BMS ausgelesen.
Ich habe auch einen Lynx Shunt, bei dem der Strom vom JK BMS zum Shunt recht gut zusammenpassen.
Ist da was bekannt ?
Gruß Michael
Hm, mir nichts bekannt. Ich habe aber das JK-BMS (Inverter Version) kalibriert, jeweils Spannungen und Ströme. Mir ist da nichts aufgefallen, das was die ModBus Integration anzeigte konnte ich mit Messungen bestätigen, zeigte der Deye/SunSynk Wechselrichter an und erschien mir ansonsten auch logisch richtig. Am WR benutzte ich lange zeit das Pylontec Protokoll und jetzt habe ich bei der neusten Firmware (V15.38) auf Deye umgeschaltet.
habe jetzt dass Abfrageintervall für Strom und Spannung von 5 auf 1 gestellt, jetzt schaut es besser aus.
Wurde mit der 15.38 die SoC Berechnung verbessert?
Wie hast du den Strom kalibriert?
Danke nochmal
Laut Andy -> YT: Off Grid Garage soll laut JK die SOC Berechnung verbessert worden sein. Hinterfragt man das dann kann das ja nur bedeuten das man vorher in der Software schlecht programmiert hatte. Denn, die Hardware steht nun mal und die Messung der Ströme/Spannungen kann man also nicht genauer machen als sie in der Hardware sind. In Software Fehler zu machen die so gravierende Abweichung hat muß man auch erstmal lernen
Ich vermute: die SOC Berechnung verbessert heist auf chinesisch "wir haben die SOC Reset-Konditionen verändert". Und das stimmt offensichtlich.
Ich konfiguriere den Deye/SunSynk Wechselrichter so das er die Akkus aus dem Netz konstant mit zB. 30A lädt und entlädt. Dann lese ich am Deye die dort gemessene Akku Spannung ab und trage diesen Wert in der Bluetooth App des Akkus ein. Und den Strom messe ich am Akkukabel, vergleiche den mit dem was der Deye meint zu messen und trage den gemessenen Strom ebenfalls in der App ein. Fertig.
Warum die Spannung die der Deye misst und nicht die die man an den Akkuklemmen misst?
Nun, als erstes schaut man natürlich ob der gemessene Wert am Akku mit dem des Deye so Pi*Daumen übereinstimmt. Bei mir sind so ca. 120mV Unterschied, dh. der Deye misst mehr als am Akku tatsächlich anliegt. Trägt man den Deye-Wert als Kalibrierung ein so kann man damit nichts falsch machen, der Akku denkt er hätte eine höhere Spannung an den Zellen als tatsächlich dort anliegt.
Das Wichtige ist aber das der Deye so die vom Akku angeforderte Ladespannung einhält und so das JK-BMS auch überhaupt in die Spannungswerte kommen kann die nötig sind damit die interne Logik der SOC 0% und 100% Werte erreicht werden können. Ansonsten funktioniert nämlich deren Logik in der Software nicht mehr.
Aber Achtung! bisher konnte ich das korrekte Verhalten nur einmalig (zweimalig da zwei Akkus in parallel) verifizieren. Ich muß das also selber noch ausgiebig austesten.