auf jeden fall landen die daten jetzt auf meinem mqtt-server und werden dann in node-red weiter aufbereitet. das programm wird spaeter ueber einen cron-job regelmaessig gestartet.
aktuell rufe ich damit 10 bms ab und der pi ist so configuriert, dass er mit einem nfs-root-system laeuft, da ich es inzwischen leid bin, regelmaessig die sd-karten zu tauschen!
das addon gibt zwar noch fehlermeldungen aus, aber die kann man einfach ignorieren.
ob ich es nutzen werde, weiss ich noch nicht, aber ich will es auch einmal mit einem esp32 mit lan probieren und mir die passende firmware von esphome erstellen lassen. das waere dann die guenstigste alternative und bei sequenzieller abfrage der bms gibt es da auch kein limit, ausser die bms-liste wird zu gross fuer den speicher. das geht natuerlich auch mit einem standard esp mit bluetooth. die google ki erstellt auch gerne eine passende konfig fuer esphome.
ich wuensche euch dann mal viel spass beim ausprobieren. ich habe tagelang verschiedene programme und konfigurationen erfolglos (es kam keine verbindung zustande) ausprobiert!
wer interesse hat, kann auch schon mal die vorbereiteten daten fuer ein sehr flexibles gateway mit esp32 mit wlan und lan bekommen, mit dem man jk-bms, seplos und pylontech (v24 ueber pegelwandler) abfragen kann. testen werde ich das aber erst, wenn ich zeit dafuer habe. da ich noch einige pis hier rumliegen habe, ziehe ich die fuer solche faelle vor, da sie flexibler sind.
die anzahl der BT-bms ist dabei unbegrenzt, da die daten dafuer ueber einen mqtt-server zum esp uebertragen werden, wenn ein abruf der daten erfolgen soll! ich denke mal, man kann das ganze auch noch fuer weitere hersteller erweitern. die konfig habe ich mir fuer esphome von google zusammenstellen lassen.
falls es jemand vor mir erfolgreich testen kann, waere ich fuer eine rueckmeldung dankbar.
ganz einfach, ich will keine zusatzscript auf dem gx installieren, die bei einem update probleme machen koennen. abgesehen davon, ich weiss nicht, wieviele BT-akkus seriell-battery abfragen kann, aber wenn die akkus dann noch unterschiedliche spannungen haben, duerften wieder probleme vorprogrammiert sein. und man wird bei mehreren bms dann wieder ein zusaetzscript brauchen, um die dazu zusammenzufassen.
und wenn ich alle akkus ueber meinen cerbo abfragen wuerde und dabei alle werte, duerfte das den cerbo doch sehr stark belasten. um alle bms nacheinander abzufragen braucht das programm ca. 90s.
abgesehen davon, den pi habe ich schon laenger, einen cerbo habe ich dort erst letztes jahr installiert.
das regele ich ueber node-red und inzwischen bekomme ich auch von allen akkus zellspannungen, ausser dem pylontech, da muss ich noch etwas fuer die anbindung machen.
allerdings habe ich eher das problem, dass das system mal probleme macht, weil das bms ausfaellt, weil der can-bus probleme macht, es gab da eine zeit, da ist der can-bus zu oft ausgefallen, so dass einzelne geraete oder auch alle verschwunden waren und beim bms bedeutet das eine notabschaltung!
deshalb habe ich die bms-nutzung selbst dort deaktiviert, wo ein bms angeschlossen ist. da ich sowieso mir verringerter ladespannung arbeite und nur zum balancing oder zur synchronisierung die ladespannung etwas anhebe, ist das auch kein problem. und wenn ich alle akkus richtig eingebunden habe, wird auch jede zelle ueberwacht. wird aber noch etwas dauern. im gegensatz zu anderen programmierarbeiten und umbauarbeiten am system ist das naemlich nicht so wichtig.
abgesehen davon, wenn man das ganze ueber ein virtuelles bms steuert, kann man auch prima den ladestrom und die dc-ueberschusseinspeisung steuern!