BMS-Web — Mein Multi-BMS Dashboard für JK-BMS mit Telegram-Alerts

Ich betreibe zwei LiFePO4-Akkus mit je 8 Zellen und 280 Ah, überwacht von je einem JK-BMS (JIKONG B2A8S20P-HC, 200 A, 2 A Active Balance). Die offizielle JK-BMS App deckt die Grundfunktionen ab, hat für meinen Anwendungsfall aber drei Einschränkungen: 1. Nur ein BMS zur Zeit. Ein gleichzeitiger Vergleich beider Akkus ist in der App nicht möglich. 2. Keine Alerts, keine Historie. Die App zeigt ausschließlich Live-Werte. Zell-Drift, Offline-Zustände oder BMS-Fehler werden nicht gemeldet. Daten der letzten Tage oder Wochen sind nicht abrufbar. 3. Keine Integration. Die Verbindung erfolgt per Bluetooth direkt zum BMS. MQTT, Home Assistant oder andere Systeme werden nicht unterstützt. Für diese Anforderungen habe ich BMS-Web entwickelt: ein Multi-BMS Web-Dashboard mit Live-Daten, Historie, Energie-Zählung und Telegram-Bot.

Auf der Hardware-Seite kommt ein einziger ESP32-S3 zum Einsatz. Er läuft mit ESPHome und nutzt die `jk_bms_ble` Komponente, die das Bluetooth-Protokoll der JK-BMS implementiert. Ein ESP32-S3 kann mehrere BLE-Verbindungen gleichzeitig halten — in meinem Aufbau beide JK-BMSes parallel. Datenfluss: 1. JK-BMS senden per Bluetooth Low Energy (BLE) an den ESP32-S3 2. ESP32-S3 empfängt, decodiert und publiziert per MQTT über WLAN 3. BMS-Web Server (Node.js) abonniert die MQTT-Topics und hält den State 4. Browser und Telegram-Bot zeigen die Daten live an Eine zusätzliche Bridge, ein Kabel zum BMS oder ein RS485-Adapter sind nicht erforderlich. Der ESP32-S3 muss lediglich in Bluetooth-Reichweite der Akkus platziert werden. Konkret eingesetzte Hardware: - **JK-BMS JK-B2A8S20P-HC* — 4S-8S, 12V-24V, 200 A, 2 A Aktiv-Balancer mit Superkondensator, Bluetooth + CAN + RS485, Heizung. Eingesetzt an beiden Akkus. - ESP32-S3 DevKit-C (N16R8)*** — 16 MB Flash, BLE 5.0. Ein Board reicht für die parallele BLE-Anbindung beider BMS.

Die Startseite zeigt eine Overview-Ansicht mit beiden Akkus nebeneinander. Jede Karte enthält SOC, Spannung, Strom, Leistung, Temperatur, Zell-Delta und Balancing-Status. Ein Klick auf eine Karte öffnet die Detail-Ansicht mit: - großem SOC-Ring inklusive Ah-Kapazität und kWh - allen 8 Zellspannungen, farblich markiert (Blau = niedrigste, Rot = höchste, Grün = normal) - beiden BMS-Temperatursensoren und der Power-Tube-Temperatur - Schaltern für Laden, Entladen und Balancer Darunter folgen Charts mit dualen Y-Achsen, Zoom/Pan-Funktion und Zeiträumen von 1 Stunde bis 30 Tage. Angezeigt werden Spannung, Strom, Leistung, Temperatur, SOC und Balancing-Strom. Die Datenpunkte werden alle 30 Sekunden in einer MongoDB History-Collection gespeichert und daraus abgefragt.

Das JK-BMS nutzt einen aktiven Supercap-Balancer. Statt Energie in Widerständen abzubauen (passives Balancing), wird Ladung über einen Superkondensator von der höchsten in die niedrigste Zelle übertragen. Das BMS publiziert über ESPHome einen `balancing_sensor`-Wert mit drei Zuständen: - 0 — Aus - 1 — Phase 1: Supercap lädt aus der höchsten Zelle - 2 — Phase 2: Supercap entlädt in die niedrigste Zelle Zusätzlich werden die Nummer der aktuell höchsten und niedrigsten Zelle sowie der Balancing-Strom übertragen. BMS-Web stellt diese Informationen im Dashboard folgendermaßen dar: - ▼ Oranger Pfeil über der höchsten Zelle (Ladungsabfluss) - ▲ Cyaner Pfeil über der niedrigsten Zelle (Ladungszufluss) - aktueller Balancing-Strom als numerischer Wert Anhand dieser Darstellung ist erkennbar, ob der Balancer aktiv ist, in welche Richtung die Ladung gerade übertragen wird und welche Zelle gerade ausgeglichen wird.

Das BMS liefert Spannung und Strom. BMS-Web berechnet daraus die Leistung (`P = U × I`) und integriert sie über die Zeit zu Energiewerten — getrennt für Laden und Entladen. Beim Tageswechsel um Mitternacht werden die Zähler zurückgesetzt. Unter dem SOC-Ring werden folgende Tageswerte angezeigt: - Geladen heute in kWh - Entladen heute in kWh - Gespart heute in Euro (auf Basis eines hinterlegten Strompreises) Damit die Tageswerte einen Server-Neustart überstehen, schreibt BMS-Web den aktuellen Stand alle 30 Sekunden in die MongoDB-Collection `daily_stats`. Beim Start liest der Server die letzten Werte zurück und zählt weiter. Zusätzlich werden die Tages-Maxima (höchste Leistung, höchster Strom) persistiert und beim Neustart wiederhergestellt.

BMS-Web bindet einen Telegram-Bot ein, der sowohl Alerts sendet als auch zur Fernsteuerung dient. Automatische Alerts: - SOC < 5 % (kritisch niedriger Ladezustand) - Zell-Delta > 70 mV (Zellen-Imbalance) - OVP / UVP Verletzung sowie Pre-Warnung, wenn eine Zelle sich dem Grenzwert nähert - Übertemperatur (MOSFET oder Zell-Temperaturen ab 65 °C) - BMS offline (MQTT-Stream unterbrochen, Verbindung zum ESP32-S3 verloren) - BMS-Fehler-Bitmask (beliebiger Error-Code des BMS) Alerts sind mit einer 5-Minuten-Debounce versehen, um Mehrfach-Meldungen zu vermeiden. Fernsteuerung: Der Bot zeigt ein persistentes Reply-Keyboard mit Status, Akku 1, Akku 2 und Admin-Menü. Über Inline-Keyboards lassen sich die Schalter Laden, Entladen und Balancer pro Akku direkt aus Telegram umschalten, ohne die Web-UI zu öffnen. Benutzer-Verwaltung: Neue Benutzer müssen vom Admin freigegeben werden. Die Alert-Zustellung lässt sich pro Benutzer einzeln aktivieren oder deaktivieren. Tagesreport: Jeden Abend versendet der Bot einen Report mit Ladung und Entladung pro Akku in kWh, den Tages-Maxima (höchster Strom, höchste Leistung) und einer Gesamtsumme inklusive Ersparnis in Euro.

Ein Beispiel aus dem laufenden Betrieb zeigt das Zusammenspiel von Alert und Fernsteuerung. Während eines Ladevorgangs auf Akku 2 hat eine Zelle die obere Spannungsgrenze erreicht, während die übrigen Zellen noch darunter lagen — ein typischer Fall von Zell-Drift, bei dem der Balancer dem Ladestrom nicht hinterherkommt. BMS-Web hat einen Cell-Over-Voltage-Alert per Telegram versendet. Über den Inline-Button im Telegram-Chat habe ich den Ladevorgang für diesen Akku deaktiviert. Das Laden wurde am BMS abgeschaltet, der Balancer lief weiter und hat die Spannung der driftenden Zelle schrittweise ausgeglichen. Nach rund einer Stunde war das Zell-Delta wieder im normalen Bereich, anschließend habe ich das Laden über Telegram wieder freigegeben. *Hinweis: Ein Screenshot dieses konkreten Ereignisses liegt nicht vor, da Telegram ältere Nachrichten im Chatverlauf nach wenigen Tagen automatisch löscht. Der Screenshot des Tagesreports weiter oben zeigt exemplarisch die Bot-Kommunikation.*

Kommerzielle Lösungen wie Victron, BYD oder Pylontech decken ähnliche Anforderungen ab. Für diesen Anwendungsfall sprachen folgende Punkte für einen Eigenbau: Kosten: Ein Victron Cerbo GX liegt bei rund 800 €. Das hier beschriebene Setup besteht aus den bereits vorhandenen JK-BMS, einem ESP32-S3 (~10 €) und dem ohnehin laufenden NUC als Server. Zusätzliche Hardware-Kosten: rund 10 €. Anpassbarkeit: Umfang der angezeigten Werte, Alert-Schwellen, Darstellung und Telegram-Integration sind frei konfigurierbar. Es besteht keine Abhängigkeit von Cloud-Diensten oder herstellerspezifischen Apps. Home Assistant Integration: Die Kommunikation läuft vollständig über MQTT und ist damit ohne zusätzliche Konfiguration in Home Assistant integriert. Daraus lassen sich Automationen ableiten, z.B. eine Ladesteuerung in Abhängigkeit von SOC und PV-Ertrag. Zugriff auf Rohdaten: Alle Messwerte, einschließlich Balancing-Phase und Zell-Drift, sind direkt einsehbar und über die History nachvollziehbar. Voraussetzungen für den Nachbau: mindestens ein JK-BMS mit BLE, ein ESP32-S3 und ein kleiner Server (NUC, Raspberry Pi oder vergleichbar) mit Node.js und MongoDB. Die ESPHome-Konfiguration ist Open Source (syssi/esphome-jk-bms). Eine Veröffentlichung des Dashboards selbst ist in Prüfung.