Das war der Trick!!!
Besten Dank, jetzt kenne ich auch den Grund dafür, warum man genau(!) diesen Schema einstellen muss und kein Anderes...
Sensationell - kannst Du hier beschreiben, wie Du das machst? Ich habe zB auch einen HomeAssistant laufen und mir persönlich würde es schon reichen, wenn ich eine Meldung bei einem Alarm des JKBMS bekomme.
Wenn alle Daten im esp korrekt eigegeben sind, überträgt er alle Register wie oben beschrieben an den mqtt-Empfänger. Den hast du ja schon in Betrieb.
Im ioBroker kommen die Daten dann einfach an.
Die visualisiere ich nun nach und nach wie es der ioBroker hergibt.
Den Alarm vom BMS gibt es wohl nicht direkt als Registerwert... Da suche ich noch die Ersatzrechnung, z.B. SOC ändert sich nicht, obwohl die Sonne scheint oder so ähnlich, muß mal sehen was geht.
Eine weitere Frage zur html Page:
Ist es möglich die Nummerierung der Zellen nicht bei 0 sondern bei 1 beginnen zulassen?
Ich habe den Sketch jetzt noch um das Auslesen des echten JK-BMS Alarmstatus erweitert.
Getestet habe ich es selbst noch nicht, deshalb wäre Rückmeldung interessant, ob die Alarmbits bei anderen JK-BMS/Firmwareständen genauso ankommen.
Der Alarm wird zusätzlich zu den bisherigen Werten ausgegeben.
Im JSON unter Battery:
JK_Alarm_Code = numerischer Rohwert
JK_Alarm_Hex = Alarmcode als Hex-Wert
JK_Alarm = lesbarer Text, z. B. OK, Cell undervoltage, MOS overtemperature usw.
JK_Alarm_Active = on / off
Per MQTT:
jkbms/Data/JK_Alarm_Code
jkbms/Data/JK_Alarm_Hex
jkbms/Data/JK_Alarm
jkbms/Data/JK_Alarm_Active
Wenn kein Alarm anliegt, sollte z. B. kommen:
JK_Alarm_Code = 0
JK_Alarm_Hex = 0x00000000
JK_Alarm = OK
JK_Alarm_Active = off
Wenn ein Alarm aktiv ist, wird zusätzlich der Rohcode mitgesendet, sodass man auch unbekannte oder neue Alarmbits später noch nachvollziehen kann.
JKBMS-WI_JK-Alarm.zip (27,0 KB)
1 „Gefällt mir“
Kleine Änderung an der HTML-Seite:
Die Zellnummerierung soll für die Anzeige nicht bei 0, sondern wie am BMS üblich bei 1 beginnen.
Intern bleiben die Zellwerte weiterhin bei Index 0–15, nur die sichtbare Bezeichnung auf der Webseite wird um 1 erhöht:
Zelle 1, Zelle 2, ... Zelle 16
Im aktuellen Sketch ist das bereits über (j+1) umgesetzt. Dadurch ändert sich nichts an der eigentlichen Auswertung oder an MQTT, sondern nur die Anzeige im Webinterface.
Aktueller Sketch: JKBMS-WI_JK-Alarm.zip
Dieser Stand enthält zusätzlich bereits das Auslesen des echten JK-BMS-Alarmstatus über JSON und MQTT. Getestet habe ich diesen Alarm-Teil selbst noch nicht.
Probiere ich natürlich aus, danke dafür. Erspart mir ne Menge Testerei, wie ich an den Alarm komme 
TOP 
Klasse und vielen Dank.
Der Test(zumindest des Webinterface) ist schnell gemacht. Die Ausgabe des Alarmstatus klappt nur die Zellennamen beginnen leider noch bei 0
Kleines Update am Sketch:
Die Zellnummerierung in der JSON-/Web-Ausgabe beginnt jetzt nicht mehr bei 0, sondern bei 1.
Vorher:
0, 1, 2, ... 15
Jetzt:
1, 2, 3, ... 16
Intern bleibt die Auswertung natürlich unverändert, es wurde nur die sichtbare Nummerierung angepasst. MQTT Zelle_01 ... Zelle_16 bleibt ebenfalls wie gehabt.
Der aktuelle Stand ist:
JKBMS-WI_JK-Alarm_Cell1-16.zip
Enthalten sind damit jetzt auch weiterhin der echte JK-BMS Alarmstatus sowie die korrigierte Zellnummerierung. - Bitte Testen !!
2 „Gefällt mir“
Oh, ist der Link abhanden gekommen?
JKBMS-WI_JK-Alarm_Cell1-16.zip (26,9 KB)
1 „Gefällt mir“
Jetzt komme ich zum nächsten Punkt:
Ich schreibe bereits Daten von einem anderen JKBMS in meinen IOBroker. Demzufolge funktioniert das System ansich. Auf diesem ESP läuft allerdings das BavarianSuperGuy Image. Jetzt möchte ich mein 2. BMS auch in diesen selben IOBroker schreiben lassen - und das bekomme ich nicht hin.
Ich habe den ESP32 nun fertig und lasse ihn im SerialMonitor laufen. Im Log sehe ich, dass die WiFi Verbindung funktioniert und somit kann ich auch auf die HTML Seite zugreifen.
Aber MQTT klappt einfah nicht. LoginDaten sind fehlerfrei. Im IOBroker sehe ich auch, dass der ESP32 sich verbinden will. Der mqttname ist erheblich unterschiedlich zwischen beiden Systemen. Ich habe auch das "alte" System abgeschaltet. Kein Erfolg.
Was übersehe ich denn? Ich vermute das Problem beim IOBroker irgendwie...
Das hier ist der Startprocess des ESP32:
So sieht es dann im IOBroker aus:
Kleines Update zum MQTT-Problem:
Im ioBroker-Log war zu sehen:
Client [jkbms_client] has invalid password(undefined) or username(undefined)
Der ESP32 erreicht den MQTT-Broker also grundsätzlich, hat aber beim Connect offenbar keinen Benutzername und kein Passwort mitgesendet.
Ich habe den aktuellen Sketch deshalb um einen richtigen MQTT-Login erweitert.
In JKBMS-WI.ino können jetzt die Zugangsdaten eingetragen werden:
mqtt_user
mqtt_password
Wenn mqtt_user leer bleibt, verbindet sich der ESP weiterhin ohne Login. Sobald ein Benutzername eingetragen ist, werden Benutzername und Passwort beim MQTT-Connect mitgesendet.
Aktueller Sketch:
JKBMS-WI_JK-Alarm_Cell1-16_MQTT-Login.zip
Enthalten sind weiterhin:
JK-BMS Alarmstatus, Zellnummerierung 1–16 und jetzt zusätzlich MQTT-Authentifizierung.
Getestet werden muss jetzt nur noch, ob ioBroker den Client anschließend sauber annimmt und die Werte unter dem zweiten BMS anlegt.
JKBMS-WI_JK-Alarm_Cell1-16_MQTT-Login.zip (27,0 KB)
Wahnsinn - ich fühle mich auch ein Stück weit rehabilitiert... 
Danke Dir @sralus
1 „Gefällt mir“
Beim genauen betrachten der Ausgabe des LKBMS, frage ich mich, was bedeuten eigentlich diese Parameter:
"Battery_Status_Code"
"Estimated_Runtime_h"
"Power_Reported"
Die drei Werte bedeuten in meinem Sketch folgendes:
Battery_Status_Code
Das ist kein originaler JK-BMS-Alarmcode, sondern ein vom Sketch selbst erzeugter Statuscode. Dabei werden bestimmte Zustände als Bitwerte zusammengefasst:
1 = Zell-Unterspannung
2 = Überspannung
4 = Überstrom
8 = MOS zu heiß
16 = Batterie zu kalt
32 = Zellspannungs-Differenz zu groß
64 = SOC sehr niedrig
Mehrere Zustände können gleichzeitig aktiv sein und werden dann addiert.
Estimated_Runtime_h
Das ist eine berechnete Restlaufzeit in Stunden. Vereinfacht wird aus verbleibender Energie und aktueller Leistung geschätzt, wie lange der Akku bei gleichbleibender Last noch laufen würde. Der Wert ist daher nur eine Momentaufnahme und keine exakte Vorhersage.
Power_Reported
Das ist die Leistung, die direkt aus dem JK-BMS-Datenframe übernommen wird.
Zusätzlich gibt es noch Power_Calc. Dieser Wert wird im Sketch selbst aus
Battery_Voltage × Charge_Current
berechnet und dient damit auch als Plausibilitätsvergleich.
Der inzwischen zusätzlich eingebaute echte JK-BMS Alarmstatus läuft separat über JK_Alarm_Code, JK_Alarm_Hex, JK_Alarm und JK_Alarm_Active.
Hatte jetzt den Fall, dass sich der ioBroker "aufgehängt" hatte. Über den Web-Zugriff auf das esp32-Modul hab ic herstmal nichts gesehen am Handy (Android). Firefox blieb schwarz, ein Jason-Tool sollte helfen, hat aber gedauert, bis ich dahinter kam. Der Firefox hat ein internes Json-Modul, dass aber die Webseite nicht anzeigt. In der Erweiterung muss ich jedes mal in die Einstellungen des Tools, auf safe drücken und die Seite nochmal aktualisieren.
@sralus gibt es eine Möglichkeit, das zu optimieren? Kenne mich da nicht so aus.
Zweites Problem, irgendwie wird der ioBroker manchmal durch timeouts so langsam, dass man ihn nicht mehr bedienen kann. Da musste ich den Server neu starten und damit kamen weitere Probleme mit einem unvollständigen Update hoch... Ganz schön Streß gehabt...
Wie hoch ist die Zeit zwischen den "publizieren"- Vorgängen? Kann ich die beeinflussen, um nicht in einen Timeout zu kommen?
Hallo erst einmal vielen Dank an alle die das Projekt weiterentwickeln.
Habe es schon einige Zeit mit meinen 3 DIY Akku's in Verwendung und via NodeRed und IoBroker visualisiert. Mangels eigener Fähigkeiten habe ich am Wochenende mit KI endlich die gesammelten Daten auf dem InfluxDB auch Darstellen können.
Und siehe da ein BMS zeigt deutliche Auffälligkeiten. Da gibt es wohl seit langer Zeit einen Übergangswiderstand auf einer Messleitung. Bei hohen Strömen (50A) macht das 10-12mV aus.
Bei einer Kontrolle optisch nicht zu erkennen. Blanker Kabelschuh sauber gekrimpt + verlötet.
Einmal die richtige Schraube gelöst und erneut festgezogen und der Messfehler ist behoben.
Wie ich es verstanden habe, ist in dem Programm für den esp beim Start ein Befehl -> charge=on und discharge=on.
Jetzt kam die Meinung auf, dass es problematisch sein könnte, wenn man diese beiden Werte auf "off" gestellt hat und der esp neu gestartet wird und beides auf "on" geht.
Stimmt das so? @sralus . Sollte vielleicht ein Hinweis in das Programm, dass die Zeilen deaktiviert werden können (mit #), wenn man die Funktion bei Neustart nicht möchte?