Sehr cool. Gerne Mal eine Projekt Vorstellung in einem eigenen Thread. Bin Ich Mal gespannt….
So n Huawei liegt hier auch noch rum 
Nein, habe ich nicht und aktuell auch noch Baustellen weg von Windows hin zu Linux in der Familie. Aber ich habe halt auch schon mehrere JK-BMS am Laufen und da verfolge ich solche Entwicklungen mit wachem Auge …
Also danke schon mal und weiter viel Erfolg !
1 „Gefällt mir“
Hier scheint viel gebündeltes Wissen unterwegs zu sein.
Ich würde gerne meine v19 per ModBus-TCP ins Smarthome direkt einbinden. Sind Euch möglichst vollsatändige Registeradresslisten für das V19 bekannt?
Die Standarddinge findet man noch ganz gut wie Zellspannungen und Widerstände. Aber erst kürzlich geänderte Parameter wie zB der Charge Status kann ich nicht finden. Ergänzend finde ich keine Infos auch Parameter zu schreiben per Modbus.
Kennt ihr etwas bzw könnt etwas empfehlen?
Danke
1 „Gefällt mir“
das V19 unterscheidet sich nicht großartig in den Registern von den früheren Versionen.
Du findest ne gute Übersicht über die Register die bekannt sind, wenn du dir die ESPHome-Implementation fürs jk-bms anschaust - hier GitHub - syssi/esphome-jk-bms: ESPHome component to monitor and control a Jikong Battery Management System (JK-BMS) via UART-TTL or BLE
Denke das sollte dir weiterhelfen, hoffe ich jedenfalls =) Andernfalls: mach doch ne kleine MCU wie nen esp32er ans uart (modbus) und schick die daten per MQTT und ruf das dann im Smartphone ab - geht fixer und bereits mit ESPHome-Bordmitteln
1 „Gefällt mir“
Danke das schaut vielsprechend aus, wenn ich einmal das Prinzip ausgetüftelt habe.
Das genau ein Punkt warum ich offene Standardlösungen aktuell bevorzuge. Möchte nicht noch mehr kompilierte Software im System haben.
Erm bitte nimm es mir nicht krumm - aber ich hoffe aufrichtig dir eher damit zu helfen, vlt falsche Vorstellungen auszuräumen:
Es ist kein Problem ob es “kompiliert” ist oder nicht. Die entscheidende Frage ist : ist es opensource und hast du diese offenen Quellen auf deinem eigenen System kompiliert. Der ESP32 IST ja GERADE ein opensource Gerät auf Basis von ESPHome (komplett quelloffen).
Der Zustand in dem es nachher aufs Gerät kommt ist dabei nicht entscheidend. Das kommt dir eventuell nur so vor wenn du nicht im Thema bist und verstehst, woher die jeweiligen kompilierten Bins (Binary files) denn herkommen.
Kurz:
Sogenanntes “proprietary binary” - vom Hersteller ohne die Quellen aus denen es kompiliert wurde bereitgestellt - BAD
Binary, was du auf Basis offener Quellen selbst für dich kompilierst (und daher weißt “was drin ist”) - ganz und völlig normal für jeden Mikrocontroller. Du packst grundsätzlich niemals die sourcen direkt auf einen Mikrocontroller, das wird IMMER kompiliert.
Kurz - was du meinst ist : Du willst nicht mehr proprietäre Software/Systeme haben, sondern es opensource halten.
Wenn du das dann mit “kompiliert” allgemein verwechselst, schießt du dir selbst ins Bein, weil jedes (auch die open-source) Projekt als kompilierte Version auf das Gerät geflashed wird.
Kompilieren oder nicht hängt einfach von der verwendeten Programmiersprache ab:
Skriptsprachen (zB Bash-Skripte oder PHP) werden nicht kompiliert. Die werden zur Laufzeit von einem sogenannten Interpreter Zeile für Zeile abgearbeitet.
Programmiersprachen, die nicht “Zeile für Zeile” arbeiten, sondern mit komplexen Objektmodellen, wie zB. C/C++ müssen IMMER erst den Quellcode in ausführbaren Maschinencode übersetzen (Eine “executable” Fassung erstellen”).
Dieser Vorgang ist das kompilieren. Ob kompiliert oder nicht, sagt rein gar nichts über die Verfügbarkeit der Quellen aus, die kompiliert werden.
2 „Gefällt mir“
Trifft für mich alles nicht erkennbar zu. Ich mag zB ESPHome nicht da es in der üblichen Verwendung jede Menge Quellen (Open Source) einbezieht und benötigt, die leben und nicht in meinem Wirkungsraum liegen. Das nervt mich gewaltig da es so bei kleinstem Änderungswunsch in einer YAML, es Bedarf, dass neu kompiliert wird. In der Zwischenzeit wurden aber wieder tausende Dinge angepasst und die Komplierung schlägt nun fehl. Ich hab jetzt zB praktisch (mit Unterbrechnung) aktuell wieder ca. 14 Tage gebraucht, bis ich herausgefunden hab, wo das Problem liegt und wie es lösbar ist (früher kompilierte es an gleicher Hardware mizt gleicher Funktion einwandfrei, wohlgemerkt). In der Zeit hing ich in einer durch externe Kräfte bestimmten Zwinge für eine eigentlich täglich benötigte Funktion. sehr unschön und darf man gerne mit meiner Unfähigkeit begründen aber die externe Abhängigkeit bleibt für jeden.
Ich sehe hier den Fall, gerne mal Adressen oder Funktionen anzupassen und wenn ich dann wieder dafür in so eine Kompilierungsfalle laufe....hab ich wenig gute Laune...
Darum vermeide ich wie gesagt zusätzlich etwas ins System dieser Art zu bringen. Eine offene Modbus-Schnittstelle hab ich in ein paar Sekunden in ihren Registeradressen ohne jegliche Kompilierung angepasst. Und dafür brauche ich keine neuen externen Dinge. Das meinte ich damit.
Alles was du das beschreibst, sind komplett normale Sachen, die grundsätzlich für jeden Mikrocontroller gelten und haben nichts mit ESPHome im Speziellen zu tun. Alle Probleme die du beschreibst lassen sich mehr auf User-Unwissenheit als alles andere zurückführen.
Niemand verändert Sachen einfach ohne dass du es willst. Du musst eine laufende Version nicht anpassen, wenn du es nicht willst. Du kannst jederzeit auf der selben SourceCode-Version bleiben, die du als für dich funktionierend gefunden hast. Niemand zwingt dich zu updaten und das Festschreiben ist in einer Zeile Config im YAML getan.
Ich glaube dir würde klar helfen, zu schauen was genau an fehlender Erfahrung und Wissen liegt und was am System - du hast da ein paar grundfalsche Annahmen und Vorstellungen und das merkt man auch direkt an deiner Terminologie
1 „Gefällt mir“
Nein hättest du nicht. Du kannst dann diese offene Schnittstelle BENUTZEN. Die Schnittstelle selbst fasst du mit dieser NUTZUNG garnicht an.
Wenn du einen ESP32 flashst, dann SCHAFFST du die Schnittstelle selbst und benutzt sie nicht nur. DAS ist der fundamentale Unterschied.
Das mag sein. Wie gesagt, wenn ich mir ein Konstrukt "anlache" wo ich für kleinste Konfigurationsänderungen diesen Umfang an Abhängigkeiten mir aneignen muß, habe ich subjektiv für mich entschieden hier das falsche System zu betreiben. Ob das für jeden die richtige Wahl ist, kann ich nicht beurteilen.
Dass du “diesen Umfang an Abhängigkeiten” nicht brauchst - bzw dies überhaupt kein Problem darstellt, da alles automatisch aufgelöst wird und du dich eigentlich um sowas überhaupt nicht kümmern musst - sofern du nicht beginnst ohne Vorkenntnisse an den falschen Stellen dein eigenes Süppchen kochen zu wollen - das ist aber nicht eventuell möglich?
Du stellst gerade Sachen als allgemeinen Fakt dar, die auf deinen eigenen Erfahrungen basieren und die ich dir ja nicht abstreiten will.
Du vergisst nur den (sehr sehr wichtigen) Punkt, diese Erfahrungen mal auf den Prüfstand zu stellen, in was sie wirklich bedingt sind. Fehlender Erfahrung oder schlechtem System/Projekt. Du irrst dich was Letzteres angeht - und investierst nachher massiv Mühe und Zeit - die für andere Sachen - sobald du auf einen angemessenen Stand gebracht wurdest - viel besser in andere Sachen investiert wären. Hat aber niemand was von. Du muss für alles das Rad selbst neu erfinden - und alle anderen sind um den geilen Scheiss gebracht, den du produzieren könntest, wenn du erstmal bisschen offener an für dich neue Sachen drangehen würdest.
Und sorry für meine mehr als direkte Art. Ich hab für mich selbst gelernt, dass die Sachen, die mich am meisten vorrangebracht haben, oft/meistens jene waren, wo mir meine falschen Vorstellungen deutlich zurecht-gerückt wurden - letztlich habe ich davon aber enorm profitiert.
Alles was ich erreichen will, ist nicht dir deine Fertigkeiten abzusprechen, sondern diese in die richtige Bahn zu kanalisieren - bezogen auf ein spezielles Thema, bei dem ich etwas mehr Erfahrung habe.
Da scheint es aber ein gewaltiges Missverständnis oder ein grundlegendes Verständnisproblem zu geben.
Du kannst problemlos hingehen und dir esphome wie jede andere IDE einmal installieren und für immer verwenden ohne updaten zu müssen.
Wenn du dann das github respository für die JK BMS Integration lokal clonst bist du genauso gut bzw. schlecht dran wie wenn du selber was mit Arduino IDE etc. programmierst.
Wenn du das zusätzlich in eine linux vm packst wird das auch in Jahrzenten noch funktionieren und du kannst jederzeit über die yaml config dir eine neue Version bauen.
Nochmal es gibt absolut keinen Mechanismus der dich zwingt eine einmal eingerichtete Version zwangsupgraden zu müssen.
Das empfinde ich genauso. Ich hab keinen Bock für ein paar Konfigurationsänderungen irgendwas zu clonen oder irgendwelche VMs zu pflegen. Und erst recht nicht auf Arduino oder ähnlich selbst im Spaghetticode zu programmieren. Not my business. Dafür bestehen Alternativen. Wer die nicht mag, ok. Ich respektiere so etwas.
Bin ich voll bei dir. Es wäre super wenn es die Eierlegende Wollmilchsau geben würde.
Eventuell verstehe ich dann etwas nicht.
Du willst ja hierbei darauf hinaus, dass es ein "Gerät" mit fertiger Firmware mit Modbus + MQTT Gateway wo man einfach nur Register pflegen muss gibt?
Das "Gerät" kann auch eine fertige und gepflegte Softwareplattform sein. Egal wie, jedenfalls ist meine Entscheidung, wenn ich mich für ein System entscheide muß es mir diese angedeuteten Aufwende abnehmen und ich bekomme dafür die gängigen Komunikationsstandards nutzbar dazu. Diesen Aufwand zB hier auf Mikrocontrollerebene runterzubrechen, ist nicht meins.
Für das angesprochene Modbus Thema schon gar nicht. Jede popelige SPS macht das komfortabler und jedes SCADA oder PCS sowieso.
Da es ja gefühlt schwieriger wird bei der JK Firmware den Durchblick zu behalten, wenn Andy sehr berechtigt nicht das Downloadportal für JKong spielen möchte, bin ich doch angetan von aktuellen Neuerungen nach 19.10 mit aktuell 19.24. Was mir bekannt ist:
-
ab 19.11 wird zu Victron (vielleicht auch andere) die CCL/DCL Einstellung um 20% statt 5% reduziert
-
das Zero Drafting in der Strommessung wurde eingeführt und verbessert. Somit erstes Feature was v14/v15 nicht hat. Positive Effekte mit v19.24 kann ich bestätigen und es dauert einen Moment eh sich die Funktion kalibriert hat
-
im Betrieb mehrerer JK BMS soll nun die 0% SOC Schaltung und Kommunikation zum Victron wieder sinniger funktionieren und nicht nur unter Berücksichtigung des Masters
-
mit 19.24 ist das v19 Display des Clients identisch mit dem Master. Nicht wie vorher, dass am Client nur Infos des Clients verfügbar sind. Am v15 Display mit v19 BMS hat sich nichts geändert
-
v19.21 hat einen Bug in der Kommunikation der Minimum Temperatur
-
beim Update von 19.10 bleiben alle Settings erhalten
-
ein Update funktioniert nur über einen Force Code: JK BMS Monitor force updating code
-
Alle Angaben ohne Gewähr
19.24 20P 30p.zip (121,5 KB)
Edit:
- (ungetestet) nach Kommentaren ist die SOC ReBulk Einstellung nur im BMS mit der Adresse 0 (Master) vorhanden. Stellt man 10(%) dort ein, findet ein ReBulk bei 90% statt.
5 „Gefällt mir“
Moin,
Gibt es denn auch ein 19.24 für die 100A BMS von JK?
Noch nicht gesehen.
Please keep in mind that the 19.21 firmware is suitable for all JK BMS units version 19. In comparison, the 19.24 firmware is intended only for 200A and 300A BMS units and is meant to fix bugs in inverter communication, especially with Victron inverters.
https://www.softpedia.com/get/Others/Home-Education/JK-BMS-Monitor.shtml
Bei Andy liegt eine 19.21 inklusive 100A Version. Wenn Du mit dem Minimal Cell Temperature Bug leben kannst, dann ist das vielleicht eine Option.
Die 19.24 stammt, wenn ich es korrekt verstanden habe aus einer Direktkommunikation eines Nutzers mit JIKong wo er die v19.24 als Bugfix-Version direkt bekommen hat.
Die 19.21 läuft ja bei mir. Deshalb die Nachfrage nach 19.24 ist aber halb so schlimm das die Temperatur und die minimale Zellspannung aktuell nicht angezeigt wird. Mal abwarten wann Andy die neue 19.24 in einem Video präsent.
Denke aber bis dahin gibt's schon wieder eine neuere Version 
Und da ist sie die neue Version für mein 100A BMS.
Habe diese Version direkt vom JK Support bekommen.
Die Bugs mit der Zelltemperatur und der Zellspannung sind damit behoben bei Victron
Gruß
Tobi
069-JK-PB1A16S10P-V19.26.zip (61,7 KB)
2 „Gefällt mir“
Hallo liebe Gemeinde
Habe gerade die v19.24 installiert und Bug mit min Zelltemperatur und Zellspannung ist behoben
Läuft aktuell ohne Probleme und werde berichten wenn was nicht klappt
LG Michael
4 „Gefällt mir“