Hallo,
ich bin gerade dabei mein PV-Uprade in meiner Garage in FHEM zu integrieren. Die Komponenten werden zwar erst noch geliefert, dennoch bin ich aktuell schon am implementieren ;=) Wechselrichter sollte mit 98_ModbusEPEVER erledigt sein.
Nun fehlt mir noch das BMS der LIONTRON LiFePO4-Batterie. Diese hat ein BMS, welches per App und BT abfragbar ist.
Ich bin hier auf
https://github.com/sw-home/FHEM-BluetoothSmartBMS
gestossen, was dem Grunde nach funtionieren sollte.
Nur ich verstehe nicht, warum hier der Umweg über ein Phyton-Script und IP-Aufruf gemacht wird.
Wäre es nicht möglich, das Modul so wie andere Module auch direkt auf den BT-Treiber des Raspi zu setzen und nicht den Umweg über Phyton zu gehen.
Leider bin ich hier im Forum auf keine vergleichbare Lösung gestossen oder war ich blind?
Könnte nicht jemand ;=) das Modul direkt für FHEM und BT implementieren? Leider sind meine Perl-Kenntnisse dafür nicht ausreichend :=(
Viele Grüße
Kurt
Hallo,
das habe ich noch gefunden:
https://github.com/stefanandres/bms-monitoring-stack
vielleicht hilft das weiter
schönes Wochenende
Hallo,
nach unzähligen Recherchen und Misserfolgen habe ich ein kleines Python-Script zusammengebastelt, welches aus dem BMS der Fa. Xiaoxiang die Grundwerte ausliest. Es benutzt dabei pexpect und gatttool.
Das Script erzeugt eine XML-Datei mit plausiblen Batteriewerten und eine eigene XML-Datei im BMS-Fehlerfall.
Beide XML-Dateien können dann mittels Fhem-Modul JsonMod nach FHEM eingelesen werden und schön weiterverarbeitet werden.
Im Script wird ein Write-Befehl doppelt ausgeführt und mit einem Timer versehen. Dieses war nötig, da ab und zu das BMS mit einer Antwort hängt und damit zu einem TimeOut führt. Ich habe festgestellt, dass wenn der Write-Befehl wiederholt wird, diese Hänger nicht auftreten und das BMS beim zweiten Mal richtig antwortet.
Das Script wird bei mir nun seit 2 Tagen alle 10 Minuten im Cron-Job aufgerufen und dann mittels JsonMod nach FHEM importiert. Bis jetzt läuft es fehlerfrei und zuverlässig. Bitte nicht auf einen optimalen Programmcode achten, ich bin nicht der Programmierexperte. Aber für meine Zwecke reicht es.
In der Anlage das Script ....
Viel Spaß.
Kurt
Hallo Kurt,
ich bekomme trotz doppeltem senden des write-Befehls timeouts:
root@raspberrypi:/home/pi# python3 /opt/fhem/bmsinfo.py A4:C1:38:7D:E4:A3
Connecting to: A4:C1:38:7D:E4:A3
BMS connected: A4:C1:38:7D:E4:A3
BMS request generic data
BMS answering 1: b'dd 03 00 1b 05 34 00 00 74 5c 75 30 00 01 2b 06 00 00 00 00 '
BMS answering 2: b'00 00 25 63 03 04 02 0b 50 0b 47 fc c7 77 '
BMS disconnecting: A4:C1:38:7D:E4:A3
BMS disconnected!
BMS answer: dd03001b05340000745c753000012b0600000000000025630304020b500b47fcc777
{
"Imain": 0.0,
"NominalCap": 300.0,
"NumberCycles": 1,
"ProtectState": 0,
"ProtectStateBin": "0000000000000000",
"ProtectStateText": "ok",
"RemainCap": 297.88,
"SOC": 99,
"Time": "2022-01-02_18:26:47",
"Vmain": 13.32
}
root@raspberrypi:/home/pi# python3 /opt/fhem/bmsinfo.py A4:C1:38:7D:E4:A3
Connecting to: A4:C1:38:7D:E4:A3
BMS connected: A4:C1:38:7D:E4:A3
BMS request generic data
BMS Answering timeout
Diese sind wesentlich häufiger als Antworten mit Daten.
Hast Du eine Idee?
-Manfred
Hallo Manfred,
leider nein.
Ich bin bei meinem BMS auch nur durch Try&Error auf das Verhalten gekommen. Die richtige Android-App funktioniert nämlich astrein, aber ein Reengineering kann ich nicht.
Eventuell blockt Dein BMS zuviele Aufrufe hintereinander. Warte mal zwischen den einzelnen Aufrufen etwas. Manche BMS erwarten vor dem eigentlichen Read auch noch einen Write "ich will jetzt lesen" oder so.
Von welchen Hersteller ist Dein BMS?
Viele Grüße
Kurt
Hallo Kurt,
Danke für Deine Antwort.
Zitat von: kurt6908 am 15 Januar 2022, 20:48:00
Von welchen Hersteller ist Dein BMS?
Das BMS ist von Xiaoxiang. Es ist ein JBD-SP04S005. Momentan läuft es hiermit:
https://github.com/sw-home/FHEM-BluetoothSmartBMS (https://github.com/sw-home/FHEM-BluetoothSmartBMS)
Allerdings kommt es auch damit immer mal zu Aussetzern. Bin jetzt von einem Raspi Zero W auf einen PI 4 umgezogen, das scheint stabiler zu sein. Das ganze soll im WoMo laufen, deswegen wollte ich den Zero einsetzen.
Grüße,
Manfred
Ich habe diese Software für einen ESP32 genutzt.
https://github.com/kolins-cz/Smart-BMS-Bluetooth-ESP32 (https://github.com/kolins-cz/Smart-BMS-Bluetooth-ESP32)
Da gibt es einen Link zu einer guten Beschreibung der BMS-Schnittstelle.
https://www.lithiumbatterypcb.com/ (https://www.lithiumbatterypcb.com/)
Die Erfahrung , dass das BMS die letzte Kopplung noch einige Zeit speichert und neue erst nach Zeit zuläßt habe ich auch gemacht.
Hallo zusammen,
mein BMS von Liontron läuft jetzt auf dem Raspi3 hiermit:
https://github.com/sw-home/FHEM-BluetoothSmartBMS (https://github.com/sw-home/FHEM-BluetoothSmartBMS)
Allerdings kommt es damit immer wieder zu Aussetzern. Auch wenn ich nach einem Abbruch den Python-Prozess beende, bekomme ich nach dem Neustart meist keine Werte, sondern immer ein timeout. Aus unerklärlichen Gründen kommen dann irgendwann wieder Werte:
Disconnect
Accepted connection from 127.0.0.1:39150
Received dda50300fffd77
BMS request data
BMS answering
BMS answering
BMS answer: dd03001b05350060276d2c8800142c4300000000000025590304020afb0aeffafb77
Received dda50400fffc77
BMS request data
BMS answering
BMS answer: dd0400080d030d030d050d06ffb377
Disconnect
Die Lösung ist zwar interessant für Testzwecke, aber nicht stabil.
Hat jemand da etwas besseres gefunden?
Was ich mir vorstelle wäre ein einmaliges abrufen der Daten vom BMS auf Anforderung aus FHEM, dann wieder die BT-Verbindung disconnecten. Dann wäre auch wieder die Verbindung mit der Handy-App möglich.