Version 0.1.0 committed. Das läuft bei mir jetzt ohne die bisherigen unschönen ESP Neustarts alle 5h. Der ESP rebootet nur noch, wenn er wirklich keine Verbindung mehr zum BMS bekommt. Die Initialisierung wird nun durch verschiedene Blink Codes dargestellt, sodass man sehen kann, wo es anscheinend hängt
WIFI Verbindungsaufbau LED_DOUBLE_FLASH
MQTT Verbindung aufgebaut LED_FLASH
BLE Scan LED_BLINK_FAST
BLE verbunden und alles läuft LED_BLINK_SLOW
Bitte unbedingt die config_sample.h anschauen und mit Eurer config vergleichen. Wenigstens ein Parameter ist dazugekommen: MIN_PUBLISH_TIME. Dieser Wert gibt an, nach welcher Zeit (sekunden) der ganze /data Baum neu published wird, unabhängig davon, ob sich Werte geändert haben. Sonst werden ja nur geänderte Werte published. Wenn man die Daten aber für ein Diagramm verwenden will, hat man dann eventuell Lücken in den Daten. Wird der Wert auf 0 gesetzt, ist es deaktiviert. Jeder andere Wert bedeutet Sekunden.
Hier noch ein paar mehr Dinge, alles fällt mir aber nicht mehr ein
Lot of refactoring:
replaced BLE stack by more stable NimBLE
add LED blink codes for init stages
added BMS config params to publish
avoid get BLE connection get kicked after 5hrs
publish more status details like RSSI
added MIN_PUBLISH_TIME to define a full publish after n seconds
Habe gerade rausgefunden, dass man mit NimBLE zu mehreren BLE Servern gleichzeitig verbinden kann. Dann werde ich das wohl erstmal abchecken, bevor ich RS486 implementiere. Keine Ahnung, ob der ESP32 ausreichend Bums für die parallele Verarbeitung von mehreren BLE Verbindungen hat. Aber Versuch macht klug.
Für meinen Usecase würden 2 Verbindungen ja reichen.
Bitte fragt nicht, ob ich das für die Arduino IDE umbauen kann, ich werde es nicht tun. Das Entwickeln und Kompilieren + Flashen ist einfach nur pain in the ass mit der Arduino IDE.
Vielen vielen Dank dass du dir die Arbeit angetan hast! Ich hadere schon länger damit mir das Projekt anzusehen und mich hat ehrlichgesagt die Tatsache abgehalten, dass es sich um ein Arduino IDE Projekt gehandelt hat - und ein Github Repo macht das Leben natürlich auch übersichtlicher
Nachdem ich gestern meine Heimspeicher-erweiterung (mit JK PB2A16S15P) in Betrieb genommen habe ist das jetzt der perfekte Zeitpunkt mich mit deinem Projekt zu befassen
Ähm Frage an die Runde: welche Version ist eure App? Ich kann nämlich diesen elendigen Namen (ist bei mir glaub ich die BT MAC Adresse mit -00 hinten) nicht ändern..
Mein Android sagt ich habe Version 4.28.0 (installiert ganz regulär über Google play).
Kann nur von iOS reden. Das wird mir im Changelog angezeigt. Ich kann den Namen ändern, wenn ich verbunden bin und dann nochmal das Verbindungsmenü öffne. Da kann man am verbundenen Gerät Name und Passwort ändern.
Hast Du dein Repo mal updated? Dir scheint die macros.h zu fehlen, die mit dem PR von @juepi79 eingeführt wurde. Mach mal einen git pull
Bitte auch die config_sample gegenprüfen. Da ist auch ein neues Makro zugekommen, was Du in Deine config.h übernehmen musst. Die platformio.ini wurde auch geändert.
Dann klone doch nochmal komplett in ein neues Verzeichnis. Der aktuelle github Stand läuft auf jeden Fall. Musst ja nur den Inhalt Deiner config rüberkopieren.
Ich habe in einem separaten Branch mal den BLE Stack auf den 2. CPU Kern (core 1) ausgelagert, während das Parsing und MQTT auf dem 1. Kern (core 0) läuft. Die Übergabe Queue habe ich erstmal auf 10 festgelegt. Das ist die Warteschlange der Buffer messages für die Übergabe an den 2 thread. Für ein BMS mag das überdimensioniert sein (ich gehe davon aus, das die Queue nie über 2 anwächst, da sie ja ständig abgearbeitet wird) Wenn allerdings perspektivisch mehrere BMS gemonitort werden sollen, wird das m.E. nötig sein, so schnell wie die Daten über BLE reinkommen. Bei mir läuft der Branch problemlos.
Eine Kleinigkeit ist mir aufgefallen: ich habe in der config die Option publish_delay auf 120 gesetzt, was grundsätzlich auch richtig funktioniert. Es scheint aber, dass beim Firmware boot die 2min "gewartet" wird, bevor der "data" Baum im MQTT auftaucht (alle anderen Daten sind gleich verfügbar).
Wenn die Entwicklung in der Form (2 cores) bleibt sollte man eventuell in die README die supporteten ESP Modelle reinschreiben - im Endeffekt entfällt wenn ich das richtig sehe damit die S und C Serie (die haben alle nur 1 Core).
Ist denke ich von dem her nicht tragisch, weil der Support von PlatformIO für die neueren ESPs sowieso nicht mehr gegeben ist (offenbar ist Espressif nicht mehr gewillt(**) bei PIO Kohle einzuwerfen, was sehr schade ist).
lg,
Jürgen
(**) oder wurde vom Staat damit beauftragt nicht mehr gewillt zu sein - ein Schelm wer böses denkt..
Für alle die es interessiert, ich habe mit der bewährten "Handauflegen" Methode mal die physische Zuordnung der Temperatursensoren ermittelt (KabelNr entspricht dem Label auf der jeweiligen Sensorleitung):
KabelNr
MQTT Sensor
1
temp_sensor2
2
temp_sensor1
3
temp_sensor5
4
temp_sensor4
Also eh völlig logisch wemma drüber nachdenkt...
temp_sensor3 ist wohl intern der temp_mosfet (liefern immer die gleichen Werte).
Das mit den Sensoren ist mir auch aufgefallen, dass da einige verdächtig gleich sind. Was mich eher erstaunt, ist, wenn ich 120A dauerhaft auf meine 2 DIY Boxen jage (jaaaaa heute war Sonne satt) also 60A auf jedes BMS hebt das den Mosfet gerade mal um 2 Grad an und die anderen höchstens 1 Grad)
Hmm, ja es sind schon riiichtig viele Mos-FETs drin und wahrscheinlich qualitativ gute, weil des Zeug kost eh nix mehr, aber bei am Drittel des Maximalstroms würd ich mir trotzdem einen deutlich höheren Temperaturanstieg erwarten, besonders aufgrund der Tatsache, dass das BMS ja im Grunde keinen vernünftigen Kühlkörper montiert hat.
Es kann natürlich sein, dass der T-Sensor an der Seite sitzt, auf der die Entlade-FETs aufgelötet sind, das würd auch erklären warum sich jetzt wenig tut bei dir.
Dass das die Zellen nicht sonderlich beeindruckt wundert mich eher nicht - kommt halt auch drauf an wie sinnvoll die Sensoren in deiner Box an den Zellen angebracht sind.
Welchen Speicher hast du bzw. welche Zellen?
2 von den Yixiang V1 Boxen mit je 16 MB31. Die Verkabelung ist mittlerweile geändert, der Minus Abgang ist jetzt an der vorderen Kiste. Das Foto ist kurz nach zusammenbau der vorderen Kiste entstanden, da lief die hintere schon ne Woche