Projekt JK BMS über Raspberry auslesen

Da ich den Thread --> Link nicht mit meiner Idee zuspammen will, habe ich die wesentlichen Inhalte hieraus mal übertragen und einen eigenen Thread dafür geöffnet.
---------------

Zum Passwortschutz, bzw. dem vermutlich nicht vorhandenen Passwortschutz der gängigen BMSse habe ich mir auch mal meine Gedanken gemacht.

Meine Idee dazu:
Entwicklung eines zentralen Dashboards auf einem Raspberry Pi, das in Echtzeit Daten von einem oder zwei BMS (LiFePO₄) und Victron-Geräten (Solarregler + Batteriecomputer) sammelt, anzeigt und gleichzeitig die BMS per Bluetooth dauerhaft blockiert, um unbefugten Zugriff zu verhindern.
Optional Einrichtung von Fernabfrage über Internet, o.ä.

Weiß jemand, ob Sowas oder etwas Ähnliches schonmal einer umgesetzt hat?
Ich würde mir gerne weitere Anregungen hierzu holen oder mich austauschen, bevor ich es selber ggf. umsetze.

Für mein Vorhaben möchte ich aber lieber einen Raspberry Pi 4 einsetzen, weil ich neben der BMS-Datenanzeige auch die Victron-Geräte (BMV-712, Solarlader) visualisieren und langfristig loggen möchte. Außerdem will ich Node-RED verwenden, um das Dashboard frei anpassbar zu gestalten und ggf. später weitere Sensoren oder Geräte einfach einzubinden.

Nur mal als kleine Zwischeninfo an alle JK-BMS-User:
Ich habe schonmal mit obigem Projekt angefangen, bin inzwischen so weit, über BT eine Verbindung zu meinem (und theoretisch zu jedem) JK-BMS aufnehmen zu können...
Und mir wird hierbei (zwar nicht Klartext, aber für mich rekonstruierbar) leider auch mein hinterlegtes Passwort übertragen.
Bedenkt das bitte - euer BMS ist auch passwortgeschützt nicht wirklich komplett sicher.

Die gute Nachricht: Wie geplant, ist mein BMS aus dem BT Umfeld verschwunden, sobald ich eine Verbindung mit meinem Pasp hergestellt habe - das Blocken klappt also wie geplant.

Hier findest Du vielleicht schon, was Du suchst: Artikel auf eBay oder versuchs hier bei Amazon

Stand der Dinge:

Zugang über BLE funktioniert, wie oben erwähnt, relativ problemlos.
Erhalt der Hex-Daten auch kein größeres Problem - das BMS sendet 3 verschiedene Framearten.
Lustigerweise sind die Arbeitsdaten schwieriger zu decodieren als einige andere Dinge, von denen ich mir das gewünscht hätte - aber nun gut...

Es gibt eine Mappingtabelle, die aber laut eigenem Autor nicht sehr zuverlässig funktioniert - schade, denn die hätte ich gut brauchen können.
Aber es gibt einen C++ Code, in den man sich reinfuchsen kann und wenn man den erstmal versteht, kann man daraus ein eigenes Mapping erstellen - dachte ich...
Gesagt, getan - und voila - es kommt im Wesentlichen Müll dabei raus. :lach:
Was habe ich dann gemacht? Ich habe 4 verschiedene Hexdatenfolgen an den Autor des esphome-jk-bms Projektes geschickt. Der hat diese widerum als Fakes in sein Homeassistant eingeschleust und mit die ausgelesenen Daten zurück gesendet.

Perfekt - nun hatte ich Hexdaten und aufs 1000stel genaue echte Werte - denn das ist gar nicht so leicht zu bekommen.
Man kann ja immer nur mit einem Gerät auf das BMS zugreifen und nacheinander sind die werte nur ähnlich, aber nicht exekt identisch (von Ladezyklen o.ä. mal abgesehen)
Aber mit exakten Werten und dem C++ Code kann man dann ganz gut reverse engineeren - ist etwas Arbeit, aber man bekommts hin.
Hierbei konnte ich dann auch bemerken, dass ich einen Byteversatz (Offset) von 32 Bytes mit meinem JK BMS habe - verrückt, das ist für die größeren JK Modelle wohl dokumentiert, aber für das kleine B2A8S20P hatte ich das noch nicht gesehen.

Für die, die hier mitlesen, sich aber nicht mit Bits und Bytes so gut auskennen: Vertut oder verzählt man sich auch nur um ein Byte, kommt später der größte Käse heraus. :roll:

OK - heute vormittag ist es mir dann erstmalig gelungen, mein Pytonscript mit meiner Mappingtabelle erfolgreich auf mein JK anzusetzen und siehe da - das sieht schon ganz gut aus (das ist jetzt eine kompakte Ausgabe - man kann auch alle Einzelwerte detailliert ausgeben)

[11:59:28] Update #8 (Δt=0.5s)
Zellen: 3.38V - 3.38V (Ø 3.38V)
Total: 13.52V | 13.67A | 184.7W
SoC: 99% | 278.7Ah / 280.0Ah
Temp: 23.0°C / 22.9°C
Status: IDLE

[11:59:28] Update #9 (Δt=0.5s)
Zellen: 3.38V - 3.38V (Ø 3.38V)
Total: 13.51V | 13.67A | 184.7W
SoC: 99% | 278.7Ah / 280.0Ah
Temp: 23.0°C / 22.9°C
Status: IDLE

[11:59:29] Update #10 (Δt=0.6s)
Zellen: 3.38V - 3.38V (Ø 3.38V)
Total: 13.51V | 13.67A | 184.7W
SoC: 99% | 278.7Ah / 280.0Ah
Temp: 23.0°C / 22.9°C
Status: IDLE

[11:59:29] Update #11 (Δt=0.5s)
Zellen: 3.38V - 3.38V (Ø 3.38V)
Total: 13.52V | 13.67A | 184.7W
SoC: 99% | 278.7Ah / 280.0Ah
Temp: 23.0°C / 22.9°C
Status: IDLE

[11:59:30] Update #12 (Δt=0.5s)
Zellen: 3.38V - 3.38V (Ø 3.38V)
Total: 13.51V | 13.67A | 184.7W
SoC: 99% | 278.7Ah / 280.0Ah
Temp: 23.0°C / 22.9°C
Status: IDLE

Nachdem ich noch ein kleines Problemchen hatte, dass im Stromfluss keine negativen Werte angezeigt wurden und ich es behoben habe, wird nun der nächste Schritt sein, nicht ein JK auszulesen, sondern das ganze Multi-BMS fähig zu machen...

Interessant!
Vor Jahren hatte ich meinen Tracer LR mit Solaranzeige über Grafana anzeigen lassen, da geht wohl mittlerweile auch mehr.
--> Link

Vielleicht ist das hierfür auch verwendbar...
KI-Google Suche:
Um BMS-Daten mit Grafana und der "Solaranzeige" einzubinden, musst du die Daten vom BMS (z.B. JK oder Daly) per MQTT an die "Solaranzeige" senden und dann Grafana mit der auf der "Solaranzeige" installierten InfluxDB verbinden. Das "Solaranzeige"-Image für den Raspberry Pi enthält bereits InfluxDB und Grafana, was die Einrichtung vereinfacht.
Schritte zur Einrichtung:

BMS-Daten per MQTT an die "Solaranzeige" senden:
Du benötigst eine Software (z.B. auf dem Raspberry Pi), die die Daten deines BMS ausliest und per MQTT veröffentlicht.
Die "Solaranzeige" empfängt diese MQTT-Nachrichten. Überprüfe die IP-Adresse der "Solaranzeige" und den MQTT-Port.
Optional kann die Frequenz der Datenübertragung angepasst werden.
Datenbank für Grafana einrichten:
Das "Solaranzeige"-Image enthält bereits eine Datenbank (wahrscheinlich InfluxDB), die die BMS-Daten speichert.
Alternativ kannst du InfluxDB auf deinem Raspberry Pi selbst installieren und konfigurieren.
Grafana mit der InfluxDB verbinden:
Grafana wird mit der Datenbank verbunden, die die BMS-Daten enthält.
Du erstellst dann ein neues Dashboard in Grafana und wählst die entsprechende Datenbank aus.
Innerhalb des Dashboards wählst du dann die Daten aus, die du visualisieren möchtest, z.B. verschiedene Werte der Batterie.

Wichtige Hinweise:
Das "Solaranzeige"-Image für den Raspberry Pi ist eine praktische Lösung, da es alle wichtigen Komponenten (InfluxDB, Grafana) bereits enthält.
Du musst die korrekte IP-Adresse und den MQTT-Port für die Kommunikation zwischen BMS, "Solaranzeige" und Grafana kennen.
Bei der Einrichtung eines Daly BMS mit Raspberry Pi kann es erforderlich sein, den richtigen USB-Port herauszufinden und die Daten in einer Textdatei zu speichern, bevor sie in die Datenbank geschrieben werden.

So - ich habe das Programm nun auf Multi-BMS umgeschrieben.
Aber noch nicht getestet - habe aber einen Fakemodus eingebaut, der Multi-Hex-Daten verarbeitet.
Und so sollte das ganze dann irgendwann im Livebetrieb ausschauen:



Wohlgemerkt immer, dass dies hier nur eine Kontrollausgabe ist, die eigentlichen Werte zahlenmäßig natürlich mehr sind und genauer sind. Aber das Auslesen hier ist ja nur der erste Zwischenschritt...

.

Hi Andi,
danke für den Hinweis – ja, MQTT ist auf jeden Fall eine gute Idee für die Datenweitergabe, vor allem wenn man mehrere Komponenten integrieren will.

Ich möchte die BMS-Daten allerdings nicht direkt mit der Solaranzeige oder Grafana verknüpfen, sondern die Werte mit Node-RED weiterverarbeiten, ein eigenes Dashboard gestalten (nach meinen Vorstellungen, nicht die fixen Templates von Solaranzeige oder Grafana) und zusätzlich noch Victron-Geräte einbinden (auch über Node-RED / MQTT / VenusOS-API etc.)

Also am Ende läuft es auch bei mir auf MQTT hinaus – aber eben als Daten-Transportmittel, nicht als Teil einer fixen Lösung wie Solaranzeige. Ich will da möglichst flexibel bleiben.

Trotzdem guter Punkt – für viele Use-Cases ist das fertige Solaranzeige-Image mit MQTT, InfluxDB & Grafana ja genau richtig!

Nun funktioniert auf der Livebetrieb mit mehreren BMSsen...

Joachim170 hat geschrieben:Moin Lakritz,
Raspberry und FHEM geht, allerdings habe ich die Bluetoothverbindung nie stabil hinbekommen.

Ich bin vorhin in denselben Fehler wie Joachim hinein gelaufen.
Dabei kenne/kannte ich dieses Problem ja bereits...


Du hast es vermutlich mit dem internen BT Modul versucht?
Ja, die Bluetooth-Stabilität auf dem Raspberry Pi kann tatsächlich tricky sein – viele berichten von Problemen im Raspbian-Bluetooth-Stack.
Darum plane ich, zwei separate, Linux-kompatible USB-Bluetooth-Dongles zu verwenden, jeweils fest auf ein BMS gebunden. So umgehe ich mögliche Stack-Probleme und kann beide BMS gleichzeitig zuverlässig abfragen.


Ich hatte vergessen, dem Programm eindeutig mitzuteilen, dass es den externen BT-Dongle benutzen soll.
Habe übrigens derzeit nur einen Dongle drin - der kann beide BMS asynchron auslesen...

.

Das gefällt mir :)
Willst Du das in Venus OS à la dbus-serialbattery visualisieren, oder nutzt Du eine andere Basis auf dem Raspi?

MichaV4 hat geschrieben:Das gefällt mir :)
Willst Du das in Venus OS à la dbus-serialbattery visualisieren, oder nutzt Du eine andere Basis auf dem Raspi?

Ich finde Venus OS und dbus-serialbattery interessant – gerade wegen der D-Bus-Integration und der Community.
Trotzdem bastle ich aktuell ein eigenes System – mit einem Raspberry Pi, Python-Skripten zur BMS-Kommunikation und Node-RED als UI und Logikschicht. Gründe:

Bluetooth-Kontrolle: Viele BMS haben keinen Passwortschutz. Mein Raspi bleibt dauerhaft verbunden, um ungewollte Zugriffe zu blockieren – das ist in Venus OS (derzeit) nicht wirklich vorgesehen.
Mehr Flexibilität: Ich kombiniere (oder will das künftig machen) BMS-Daten mit externen Sensorwerten, MQTT-Topics und REST-Diensten. Node-RED hilft dabei enorm.
Eigene Web-UI: Ich will ein Dashboard, das genau zeigt, was ich brauche – mobilfreundlich, erweiterbar, mit optionalem Login, Userrechten oder sonstigem "Firlefanz" :lach: .
Lernfaktor: Ich will verstehen, wie alles funktioniert – vom BMS-Protokoll bis zur Logikverknüpfung. Node-RED macht Experimente hier recht einfach.

Vielleicht docke ich später mal an Venus OS an (per MQTT oder D-Bus), aber gerade ist mein Fokus auf einem komplett unabhängigen System.

Hi zusammen,

kurzes Update von meiner Bastelecke:

Ursprünglich hatte ich ja Node-RED und MQTT im Einsatz, um BMS-Daten zu sammeln und zu visualisieren. Mittlerweile bin ich erstmal davon abgekommen und probiere einen direkteren Ansatz:

Backend: Python + Flask mit Flask-SocketIO
Echtzeit: WebSockets über Flask-SocketIO, damit die Werte direkt live im Browser auftauchen
Zugriff: alles über mein lokales Intranet – vom Handy oder PC über den Browser erreichbar

So habe ich die volle Kontrolle über die Datenströme und das Dashboard – ich kann es genau so bauen, wie ich es brauche, ohne mich an Node-RED-Logik oder MQTT-Themen zu binden. Gleichzeitig ist es ein super Lernfeld, um mich in Flask, WebSockets, Python und Frontend-Techniken einzuarbeiten.

Zwischenschritt: Ich habe erst mal nur ein paar wenige Daten ins Dashboard gebracht – mehr Daten und eine andere Skalierung kommen noch. Bessere Lesbarkeit der einzelnen Zellenwerte auch... :lach:

Kleiner Rundungsfehler im Gesamt-Strom - aber das passt schon recht gut. :top:

Noch ein bisschen herumspielen mit Rest-Apis...

Wichtig ist, auch mal einen Langzeittest durchzuführen, denn es wird immer wieder berichtet, dass der Bluetooth-Stack von Raspbian nicht besonders stabil ist. Und das stimmt leider – zumindest was den internen Bluetooth-Chip des Raspberry Pi betrifft, vor allem wenn man ihn in einem Metallgehäuse verwendet.

Aus diesem Grund habe ich im Script einige Bluetooth-Fallbacklösungen eingebaut und den internen Bluetooth-Chip meines Raspberry Pi komplett deaktiviert. Der interne Chip hat nämlich immer wieder versucht, die Verbindung zu übernehmen, was ziemlich nervig war. Stattdessen nutze ich ausschließlich einen externen Bluetooth-USB-Dongle.

Das Ganze läuft inzwischen sehr stabil – mittlerweile schon über 14 Stunden am Stück. An dieser Stelle muss ich den Langzeittest aber erstmal abbrechen, da ich jetzt schauen möchte, ob ich über Bluetooth/BLE auch einige Victron-Daten sammeln kann.


... nicht viel los auf dem Dashboard, wenn man quasi gleich viel erntet, wie man verbraucht. :wink:

Sodele - nun ist auch der Victron Solarregler über BT/BLE eingebunden.
Sieht doch schon recht schick aus... und noch wichtiger, es funktioniert... :ja:

Nun noch Tabs eingefügt, auf dem Laptop vertival, auf dem Tablet horizontal über den Säulen.
So kann man die einzelnen Blöcke auf verschiedene Seiten verteilen und bequem anwählen.
Dazu noch eine Anzeige, die mir ein paar interessante Daten auswertet und etwas Platz nach unten hin geschaffen, um mir eine kleine Wettervorhersage einzubauen (dort, wo jetzt der Platzhalter ist) ...

Die einzelnen Anzeige-Blöcke sind frei konfigurierbar und ich habe sie für den großen Screen anders konfiguriert als zb fürs Tablet.

Laptop-Ansicht: (Tablet Ansicht folgt später...)

Tablet Ansicht: Horizontale Navigation

(Tab 1 und dann Tab 2 - dort fehlen aber natürlich noch Inhalte...)

Kleiner Hinweis für jeden, der an solchen Basteleien Spaß hat:
Mein System lief, aber die Stabilität lies selbst bei ausgeschaltetem internen BT Chip und ausschließliche Nutzung eines externen BT Dongles immer wieder mal zu wünschen übrig.

Nun habe ich den BT Dongle mal von einem USB3 auf einen USB2 Anschluss umgesteckt und die Stabilität ist exorbitant gewachsen.

Warum?
Zufall?

Nein...
USB 3.0 erzeugt elektromagnetisches Rauschen bei 2,4 GHz
USB 3.0 (genauer: USB 3.1 Gen 1, 5 Gbps) nutzt hochfrequente Signale.
Diese erzeugen elektromagnetische Störungen (EMI).
Diese Störungen liegen im gleichen Frequenzbereich wie Bluetooth und WLAN (2,4 GHz).
Besonders die Kabel und Stecker von USB-3-Geräten können wie kleine "Antennen" wirken → sie strahlen Störsignale ab.

USB 2.0 nutzt niedrigere Frequenzen (max. 480 Mbps), die nicht in das 2,4-GHz-Band streuen.
Deshalb gibt es keine oder kaum Interferenzen mit Bluetooth/WLAN.

Intel hat das 2012 in einem Whitepaper dokumentiert... --> Link

Nachdem ich nun zwecks Lastverteilung mal ein ve.direct Kabel angeschlossen hatte, mit dessen Leistung ich eher mittelprächtig zufrieden war - bin ich inzwischen bei der Lösung mit 2 externen USB BT Dongles angelangt.
Und das läuft gtatsächlich bisher wie geschnitten Brot.
Die BLE Last wird so schön aufgeteilt und ich habe es derezeit so konfiguriert, dass ei Dongle die beiden JK-BMSse abfragt und der zweite auf den Victron 100/50 angesetzt ist.
Das läuft dann auch schonmal 15 Stunden ohne Frameverlust und alles andere wird ohnehin über Fallbacks abgefangen - also wirklich live.

Nach zuletzt 2 Wochen an der Küste mit durchweg bewölktem Wetter dachte ich mir, eine kleine Wettervorhersage könnte mein Dashboard dann doch etwas aufpimpen... hier ist das Ergebnis.



.

Hallo Michael.
Hut ab was du das aus dem Hut gezaubert hast. Meine Hochachtung.
Auch wenn das nicht meine Welt ist. Aber die Leistung und Übersichtlichkeit, die du aufs Tablet bringst.
Fals ich mal in eien Anfall von ....., so was brauche. dann weiß ich wohin ich mich wenden muß.
An Guten dafür.
Franz

Mega Projekt!!!
Sowas will ich auch :-D , sobald ich meine neue Batterie gebaut habe.
Im ernst, wenn es soweit ist, würde ich mich gern bei Dir melden dürfen.

Hallo zusammen,
erstmal danke für Euer Interesse und die lobenden Worte. :top:

Stand der Dinge: (ich hoffe, das wird jetzt nicht zu technisch) :roll:
Ich habe meine bestehende Wetter-App, die auf Flask und SocketIO basiert, um eine 7-Tage-Solarertragsprognose für meine 800 Wp Wohnmobil-PV-Anlage erweitert. Dabei kommen die Python-Libraries pvlib zur Modellierung des PV-Systems, pandas zur Verarbeitung von Zeitreihen und requests für API-Abfragen zum Einsatz.

Die Wetter- und Standortdaten stammen hauptsächlich von der Open-Meteo Forecast API, die kostenlos nutzbar ist und keinen API-Key benötigt. Sie liefert stündliche Werte der Global Horizontal Irradiance (GHI) in W/m² sowie die Lufttemperatur für Temperaturkorrekturen und stellt damit eine 7-Tage-Vorhersage bereit. Für die Bestimmung der geografischen Koordinaten nutze ich zusätzlich wttr.in, das bereits in der App implementiert ist; als Fallback steht die Open-Meteo Geocoding API zur Verfügung.

Der Berechnungsablauf beginnt mit der Standortbestimmung, wobei die Latitude- und Longitude-Werte aus der wttr.in-Antwort extrahiert oder über die Geocoding-API ermittelt werden. Anschließend werden über einen API-Call an Open-Meteo stündliche Wetterdaten für die nächsten sieben Tage abgefragt. Auf Basis dieser Daten berechnet pvlib für jeden Zeitpunkt die Solarposition in Azimut und Elevation. Die stündlichen GHI-Werte werden dann auf die Fläche der PV-Module umgerechnet, um die Plane-of-Array-Irradiance (POA) zu bestimmen. Dabei wird der Anteil von direkter und diffuser Einstrahlung standardmäßig mit 60 zu 40 geschätzt, kann aber konfiguriert werden.

Die Zelltemperatur der Module wird mithilfe des SAPM-Modells unter Berücksichtigung einer möglichen Windkühlung berechnet, alternativ greift ein simpler Fallback. Die Gleichstromleistung (DC) wird mit der Funktion pvwatts_dc() unter Berücksichtigung des Temperaturkoeffizienten von -0,4 %/°C bestimmt. Zusätzlich werden typische Systemverluste wie Kabelverluste und Verschmutzung mit etwa 10 % berücksichtigt. Abschließend werden die stündlichen Werte zu Tageswerten aggregiert und in Wh, kWh und Ah bei 12 V ausgegeben.

Die Integration in die bestehende App erfolgt nahtlos innerhalb des Forecast-Threads, sodass kein zusätzlicher Thread nötig ist. Die berechneten Prognosewerte werden über das vorhandene SocketIO-Event forecast_update an die Frontend-App übermittelt, wodurch die Solarertragsprognose direkt in die bestehende Benutzeroberfläche eingebunden ist.

Das Ganze funktioniert ganz wunderbar, zudem speichere ich diese Werte in einer SQL Datenbank, um sie auch langfristig abrufen zu können, bei Bedarf Statistiken, Verläufe oder was auch immer damit anstellen zu können.

Hinweis:
Ich würde Prognose und tatsächlichen Ertrag auch gerne maschinenlernbar interpollieren, um immer genauer werden zu können.
Also quasi die Paramter automatisiert immer feiner anpassen, sodass Prognose und Ertrag immer enger zueinander passen würden.
Aber das würde nur dann einen Sinn ergeben, wenn es eine stationäre Solaranlage wäre.
Auf dem Dach eines Wohnmobils ergibt das gar keinen Sinn, da greifen viel zu viele Parameter ein, die durch die Praxis des Reisens entstehen. (Verschattung durch Baum, Häuser, usw,)

Wie geht es weiter?
Viel wichtiger als Solar-Prognosen sind natürlich die Solar-Erträge.
Aber glaubt mir mal, an die Historiewerte im Victron heran zu kommen, ist nicht einfach.
Ja, doch... über ein VE.Direct Kabel gehts schon recht gut - das widerum ist aber für eine flüssige Echtzeitanzeige des Solartachos viel zu langsam.
Daher bevorzuge ich BLE Advertising (Instant Readout) für die Live-Daten.
Hier bekomme ich aber nur die wirklichen Livedaten - also keinerlei Historie.
Die würde ich nur über (wie erwähnt) das VE.Direct Kabel erhalten oder über GATT - nur dass GATT nicht wirklich mit dem scanloop des BLE Advertising harmoniert.
Ok, die könnten sich ja geschickt abwechseln - aber ein wirklicher GATT Zugang zum Victron SR ist mir auch noch nicht gelungen.
Victron scheint den tatsächlich "abzuwehren", wenn das Pairing fehlt (was ja auch ok ist)... aber wie man Pairing mit dem Raspberry hin bekommt, weiß ich bisher einfach noch nicht - es bleibt also spannend...

Hallo.
Ich bin nach wie vor begeistert von Homeassistant. Nicht nur die aktuellen Daten, auch die historischen Daten werden gespeichert und sind jederzeit abrufbar.
Im Womo habe ich einen Rpi 3b für das Victron System. Das sendet alle 5 Sekunden Daten an mein Homeassistant zu Hause (Wortspiel) per VPN. Mein System zu Hause und das Womo habe ich dann in einem System. Für JK BMS gibt es in Homeassistant auch eine Integration über BLE, genauso wie für meine zwei Redodo 140AH.
Auch die Forecastdaten zu Wetter, PV- Ertrag ... sind als Integrationen verfügbar.
Funktioniert seit Monaten ohne Probleme.
Also warum so kompliziert?

Hi Spaetkumer,

Ja, Homeassistant ist wirklich klasse... Und hat irre viele Optionen.

Auch schön, wie du alles über HA in deinem Dashboard zusammenführst.
Und du musst selber sogar relativ wenig Ahnung von Programmcode und Softwareentwicklung haben, um dennoch zu einem schönen Ergebnis zu kommen. (womit ich dich nicht meine - vielleicht hast du sogar viel Ahnung davon - aber man kann es auch als Quasi-Laie schön umsetzen)
Das ist auf jeden Fall ein großer Vorteil von HA.
Der Vorteil selbst programmierten ist natürlich eine gewisse Flexibilität und, dass man alles genau nach eigenen Vorstellungen umsetzen kann.
Nachteil ist viel mehr Aufwand, um z. B. schöne Visualisierungen oder Datenhistorien zu realisieren.
Beides hat seine Brechtigung - HA wie auch eigener Programmcode.

Ich habe aber ein paar Fragen an dich.
Deine BMSse hast du also über BLE angebunden - das ist prima.
Wie sieht es mit deinen Solarreglern aus?
Auch BLE? Wenn ja, über welches Addon bzw. welches Repository?
Oder über ESP-Home mitsamt ESP32 Controllern?
Oder doch VE.direct?

Und hieran schließt sich die Frage an, wie "flüssig" laufen deine Daten in deinem Womo-HA?
Echtzeit? Oder im "Sekundentakt"?

Oben links in deiner Anzeige, ist das ein BMV?
Falls ja, dann auch hier die Frage, wie du dessen Daten anzapfst?

Und ganz wichtige Frage:
Läuft das wirklich sein Monaten 24/7 problemlos bei dir durch?
Oder hast du immer wieder Reboots, Restarts (manuell oder über watchdog?)

Jedenfalls auch ein schönes Projekt, das alles über HA zu machen und zudem mit riesigem Ausbaupotential. :top:

Hall8.
Läuft wirklich seit Monaten problemlos.
Jeden Tag gibt es eine von mir programmierte Datensicherung in eine Cloud.
Das System auf dem Womo läuft auch über das Victron VM Portal. Zusätzlich als Sicherheit.
Echtzeitdaten gibt es als Victron Remote Control.
Auch in Homeassistant kann das Aktualisierungsintervall bis 1 Sek. eingestellt werden.
Z. Zt. programmiere? das Ganze noch in NoteRed. Einfach um eine zusätzliche Lösung zu haben.

Remote Control im VM Portal:

Vorab – schön, dass das bei dir zufriedenstellend läuft.
Denn genau so soll es ja sein.
Deine Victron-Anbindung ist gut, mir persönlich aber etwas zu viel Overhead – ich wünsche mir das Ganze schlanker (selbst VE.direct ist mir schon zu viel...)

spaetkumer hat geschrieben:Auch in Home Assistant kann das Aktualisierungsintervall bis 1 Sek. eingestellt werden.

Hier kommen wir zum eigentlichen Knackpunkt:
1 Hz ist mir einfach zu wenig – da läuft nichts wirklich flüssig.
Einer der Gründe, warum ich mir eine eigene Lösung samt Frontend programmiert habe.
Meine Anzeige soll einfach weich und verzögerungsfrei laufen – ähnlich wie in der App selbst.

Home Assistant mit ApexCharts eignet sich hervorragend für Statusanzeigen und Datenlogging mit etwa 1 Hz Aktualisierungsrate.
Für flüssige Bewegungen im Bereich von 2–5 Hz ist ein eigenes Socket.io-Frontend oder ein Node-RED Dashboard deutlich besser geeignet.
Und wenn man wirklich ein „Oszilloskop-Feeling“ mit kontinuierlich gleitender Darstellung will, kommt man um ein externes WebSocket- oder Canvas-basiertes Frontend nicht herum.

Was ich mir trotzdem überlege:
Mein eigenes System parallel zu Home Assistant laufen zu lassen und die wichtigsten Daten z. B. alle 1–5 Sekunden an den HA-Docker zu übergeben – einfach um die Automatisierungen und Komfortfunktionen von Home Assistant nutzen zu können.
Weniger wegen der Historie, denn meine Daten landen ohnehin schon in einer externen SQL-Datenbank, die unabhängig vom Raspberry läuft.

Inzwischen habe ich sehr viel geändert - was man auf dem Dashboard selber aber nur sehr bedingt sieht.
Vor allem in Sachen Stabilität, aber auch Anzeige, welcher Port die Geräte ausliest, mqtt Broker installiert, weitere Victron Angaben hinzugefügt, von Pi4 auf Pi3 downgegradet, weil der deutlich weniger Strom verbraucht, Solarprognose gestrichen, dafür Solarertrags-Historie hinzugefügt, usw.

Weitere Aufgaben:
1. Weitergabe der ausgelesenen Daten an Home Assistant zur Implementierung von Automationen, z.b. "setze D+ auf Kühli bei Spannung == xy oder bei Solarertrag > xy oder, oder oder... also eingentlich genau das, was auch das relais beim BMV 712 macht, nur eben mit viel mehr Parametern (so könnte man z.b. auch die Wettervorhersage als Parameter für D+ auf dem Kühli nutzen)

2. Integration serverseitiger Scripte - wozu genau, weiß ich aber selber noch nicht. :wink: Aber da fällt mir schon was ein... :lach:

Hier noch ein aktueller Screenshot:

Ich habe heute mein Dashboard als Integration in Home-Assistant implementiert.
Das macht mir dann die Hüpferei zwischen Dashboard und HA etwas einfacher.
Aber HA dazu zu überreden, seinen eigenen Header mal "außen vor" zu lassen, war gar nicht so einfach.
Ja, doch, letztlich schon, aber ich habe länger nach einer Lösung dafür suchen müssen... :)

Nochmal ein bischen Input:

Mit dem bisher vorgestellten Dashboard bin ich maximal zufrieden.
Alles auf einen Blick - alles tippi-toppi.
Läuft alles inzwishen sehr stabil - mit entsprechenden Watchdogs und einem System, was selber erkennt, ob irgendwo irgendwas nicht stimmig ist und dann einzelne Komponenten selbstständig neu startet.
So ist echter Dauerbetrieb möglich.
Sämtliche ausgelesenen Daten werden von einem Raspberry Pi3 ausgelesen und über mqtt gesendet.
Auf einem Raspberry P4 läuft dann ein HAOS, welches die Daten ausliest und weiter auswertet.
Sämtliche relevanten Daten haben übrigens eine Anbindung zu meinem Server un einer darauf laufenenden Datenbank, die die Daten dann zur langfristigen Analyse aufnimmt.

So richtig Spaß macht das alles aber erst, wenn man über den Blick hinaus auch Automationen erstellen kann, also z.b.
"Schalte bei genügend SOC, Spannung, Solarertrag o.ä. den Kühlschrank auf Lifepo-Betrieb um" oder
"Schalte die Wasserpumpe automatisch aus, wenn ich das Womo verlasse" oder
"Der Thermoschalter der Akkuheizung muss erst scharf geschaltet werden, wenn die Temperaturen unter Grad C fallen" oder
"Sende mir eine Nachricht aufs Handy, wenn xyz-Parameter überein stimmen"

Und da kommt Home Assistant ins Spiel.
Und weil mir mein bisheriges Dashboard standartmäßig zu hell ist, schalte ich im Standy auf eine dunkleres Standby-Dash und im "Produktivbetrieb" auf das hier schon öfter vorgestellte helle Dash...

Hierzu habe ich mir ein 13,4 " Tablet gekauft, was ich als Wandpanel nutze.
Darauf werden alle Dashboards produziert, es dient aber ebenfalls als Mediencenter für Radio, Youtube und Ähnliches mehr.
Und selbst, wann das Tablet nachgeladen wird, läuft über HA als Automation.

Das Standby-Dash entwickle ich gerade erst - hier mal kleiner Einblick...

Und so sieht das bei mir mittlerweile aus. 230V ist nicht angesteckt, brauche ich auch nicht bei 580 Wp PV.
Habe im übrigen auch viele Automationen. Wenn man sich mit HA beschäftigt macht das schon Spaß!!!
Der Vorteil ist auch, das alle Geräte, soweit diese "smart" sind, auf einem Panel in HA - natürlich auf verschiedenen Karten - dargestellt werden.
Auch mein Zuhause läuft komplett hierüber. Kein Switchen in verschiedene Apps mehr notwendig.
Werde meine mqtt Geräteanbindungen Zug um Zug auf ESP Home umstellen. Wesentlich schneller und stabiler. Die Sequenz ist auf 1 Sekunde eingestellt.

Und so sieht das bei mir mittlerweile aus. 230V ist nicht angesteckt, brauche ich auch nicht bei 580 Wp PV.
Habe im übrigen auch viele Automationen. Wenn man sich mit HA beschäftigt macht das schon Spaß!!!
Der Vorteil ist auch, das alle Geräte, soweit diese "smart" sind, auf einem Panel in HA - natürlich auf verschiedenen Karten - dargestellt werden.
Auch mein Zuhause läuft komplett hierüber. Kein Switchen in verschiedene Apps mehr notwendig.
Werde meine mqtt Geräteanbindungen Zug um Zug auf ESP Home umstellen. Wesentlich schneller und stabiler. Die Sequenz ist auf 1 Sekunde eingestellt.


Sieht klasse aus, Spaetkummer. :top:
ESP / ESP Home steht auch bei mir auf dem Plan - ich will hierüber meine Tanksensoren umsetzen.
Frequenz auf 1 Sekunde ist ok - mein Victron läuft genau so schnell (oder lahm), meine BMSse laufen im Schnitt auf 2-3 Frames pro Sekunde. Da kommt es ein bischen darauf an, was man haben will: Information oder Design... :lach:

230v habe ich ebenfalls nicht angesteckt, obwohl ichs manchmal brauche.
Selbst bei 800WP Solar, aber ich verbringe vermutlich mehr Zeit im Womo als du, also auch mehr Verbrauch... z.b. gerade im Moment stehe ich an der Nordsee und höre dem Rauschen der Wellen zu... :ja:

Danke für deinen Input - gefällt mir sehr gut und ich wünsche mir durchaus mehr HA (oder native Dashs plus Scripte) Input hier im Forum. :top: