@DWL
du hast es also gefunden 
jap ist etwas so lässt es sich aber ggf einfach finden oder zumindest verstehen brauch ja auch nicht den gesamten log wenn er dann steht halt die "letzten" einträge ..
@drbacke
habe den ersten Eintrag jetzt mal so gemacht das ich dort die Update einfach einfügen werden
und hast du den log von deinem Absturz ??
mich beschleicht der verdacht das der SW reset (ESP.restart) bei dem EPS32 gar nicht geht
mal sehen ggf schaffe ich es heute abend das mal zu testen...
und ggf ziehen wir eine kleine leitung zwischen zwei pins und dann mach ich halt ein echten HW reset ....
aber erstmal würde ich gern sehen was da wirklich passiert und ob der reset überhaupt getriggert wurde... nicht das ich ein anderes Problem im Code habe...
Moin scotty,
den log habe ich leider nicht. Das Teil ist in meinem Container und deswegen ist es etwas schwierig.
Ich werde es aber beim nächsten mal mitloggen und dann hier posten, vermutlich aber erst morgen dann.
Hallo,
der ESP32 verhält sich um einiges anders als der ESP8266.
Beim ESP32 läuft FreeRTOS...
Zuerst würde ich den ESP32 dazu bringen, WiFi nicht schlafen zu legen:
esp_wifi_set_ps(WIFI_PS_NONE)
Man kann dann noch einen Task von FreeRTOS schreiben, der bei WiFi-Problemen einen erneuten Connect voran treibt. Wenn ich heute Abend zu Hause bin, schreibe ich hier mal meinen Ansatz.
Gruß
Jörg
[...]Danke dir. Werde ich mir anschauen. Ist bestimmt hilfreich.
also im Guthub wirst du von mir nichts finden ;) das ist alles von jemand anderes und meist auch "nur" für ein Raspberry ;)
anbei mein Gerüst was ich mal zum laufen bekommen habe... beachte aber den ersten Post hier von mir !
wegen Stabilität kann ich dazu nichts sagen hab es nie aktiv genutzt nachdem klar war das mir hier Daten "fehlen"...
RS485_JKBMS_Working.ino.rar
Werde berichten, wenn ich was hinbekommen habe.
Hallo,
der ESP32 verhält sich um einiges anders als der ESP8266.
Beim ESP32 läuft FreeRTOS...
Zuerst würde ich den ESP32 dazu bringen, WiFi nicht schlafen zu legen:
esp_wifi_set_ps(WIFI_PS_NONE)
Man kann dann noch einen Task von FreeRTOS schreiben, der bei WiFi-Problemen einen erneuten Connect voran treibt. Wenn ich heute Abend zu Hause bin, schreibe ich hier mal meinen Ansatz.
Gruß
Jörg
Hey der ESP 8266 kam huer nur auf da ich mal ein anderen Code für den RS485 geschrieben hatte ^^ da war noch kein WIFI oder so drin ;)
also wenn dann geht es jetzt nur noch um den ESP32 ;)
das mit den WIFI schau ich mir heute abend ggf auch nochmal an ^^ ggf finde ich eine Dose wo keine Signale mehr durchkommen ;)
Sorry,
hab nicht alles gelesen, aber die meisten (auch ich am Anfang) habe den ESP32 genauso initialisiert wie den ESP8266 - zu dem man ja Beispiele ohne Ende findet.
Und im Thread habe ich erst auf Seite 8 angefangen. Da stand dann irgendwann ESP32 und WiFi-Reconnect Probleme.
Werde mir heute Abend mal deinen Code anschauen, ich persönlich habe auf Batrium gesetzt...
Gruß
Jörg
@DerLang
kein Problem ist auch mittlerweile lang geworden hätte nicht gedacht das es wirklich jemand nutzen will außer mir
nur um alle nochmal abzuholen
wir haben aktuell ein Problem wo wir sehen das keine Daten mehr vom BMS kommen
-> WLAN , MQTT ist aber weiterhin stabil und aktiv...
-> Scheinbar greifen hier meine Ideen nicht wirklich mit dem 3 Stufen Konzept ... irgendwie komme ich scheinbar nicht in Stufe 3 wo ich dann einen Restart triggere der bei mir im test ging
da warte ich gerade auf Logs von den fleißigen Helfern hier ,)
dann gab es den Wunsch von einem User das es möglich sein soll das WIFI so zu bauen das es ein reconnect kann da er es über Nacht wohl abschaltet...
das mit dem WIFI reconect kann ich nicht testen da meine Blechdose noch zu viel Pegel durch lässt und ich mein WIFI nicht abschalten will zum testen 
meine Vermutung aktuell ist das der WIFI reconnect eigentlich gehen sollte und wir hier eigentlich immer das Problem sehen das keine Daten mehr kommen und er irgendwo im Code "hängt"
Ok der Log läuft mit, ich bin gespannt.
Ok der Log läuft mit, ich bin gespannt.hast auch den Full log aktiv ;) ?
Na klar :DOk der Log läuft mit, ich bin gespannt.hast auch den Full log aktiv ;) ?
Hier ist der Log, scheint beim BLE Reconnect zu hängen:
Notify callback for characteristic 0000ffe1-0000-1000-8000-00805f9b34fb of data length 128
data: 0, 0, 4E, 0, 22, 0, 5F, 0, 0, 0, B0, F7, 2, 51, 55, 7C, 2, 0, 40, D, 3, 0, C, 0, 0, 0, FF, 1A, 26, 0, 64, 0, 4, 2, DB, 2A, 32, 0, 1, 1, 2C, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 1, 0, 0, 0, 4F, 4, 0, 0, 0, 0, 61, E6, 3F, 40, DC, 0, 0, 0, 58, AA, FD, FF, 0, 0, 0, 1, 0, 5, 0, 0, 75, BC, 7A, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Notify callback for characteristic 0000ffe1-0000-1000-8000-00805f9b34fb of data length 44
data: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6D,
New Data for Analyse Complete...
Cell Voltages = 3.087V, 3.087V, 3.086V, 3.087V, 3.086V, 3.084V, 3.086V, 2.948V, 2.944V, 2.953V, 3.087V, 2.945V, 2.972V, 2.917V, 2.917V, 2.943V,
unbekant 1 = 0, 0, FF, FF,
Average Cell Voltage = 3.014V,
Delta Cell Voltage = 0.171V,
Current Balancer = 3.333V,
unbekant 2 = 0, 0, 0, 0, 0, 0,
Battery Voltage = 48.230V,
Battery Power = 0.000W,
Charge Current = 0.000A,
Analyse = 0, 0, 66, BC, 0, 0, 0, 0
unbekant 3 = 0, 0, 0, 0, 0, 0,
Battery T1 = 7.800°C,
Battery T2 = 3.400°C,
MOS Temp = 9.500°C,
Balance_Curr = -1.968A,
unbekant 4 = 0, 0,
Percent Remain = 81%,
Capacity Remain = 162.901,
Nominal Capacity = 200.000,
Cycle Count = 12,
unbekant 5 = 0, 64, 0, 26, 1A, FF,
Capacity Cycle = 0.516,
Tage: 38 Stunden: 1 Minuten: 16 Sekunden: 11
unbekant 5 = 0,
Charge on? = on,
Discharge on? = on,
unbekant 7 = 2C, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 1, 0, 0, 0, 4F, 4, 0, 0, 0, 0, 61, E6, 3F, 40, DC, 0, 0, 0, 58, AA, FD, FF, 0, 0, 0, 1, 0, 5, 0, 0, 75, BC, 7A, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, Status of ble_Connect: 1
Get Deivce Dates Rerended...
Status of ble_Connect: 1
BLE -> Retry: 2
BLE -> Reconnecting!
Hi,
Thank you Scotty for the great software solution. I can read and write in german but english just is a bit easier for me 
I have one JK-BMS (200A/2A) in production but received 4 more BMS's this week I need to implement. (It will be 4 (each with there own BMS) x 1P16S x 200Ah (48v) and 1 x 2P8S * 304Ah (24v)).
The software is working great and I have had a look through the code. I already tried to add the OTA function but for some reason I havn't got it to work yet. That might be due to the fact that I need to use the setting "Minimal SPIFFS with OTA" that sometimes gives these problems.
For myself I will I will add a kind of heartbeat function that will tell me when the board (e.g. problems with the BLE transmission) has problems so I can restart it (have to test wether or not by resetting by cutting the power (with a relay) or using the reset ping (also with a relay). What I have noticed is that when starting fort the first time after applying power I get the same error as stated on page 8.
12:06:18.442 -> - Created client
12:06:18.914 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
12:06:18.914 -> - Connected to server
After bootup and then a reset for a second try usally fixes this.
Then I have a request: Would it be possible to add the error codes like "overvoltage" to the code. I would add them my self but i'm not sure on what adresses they might sent the data?
Thank you so much.
Best regards,
Gert
Hallo,
hat jemand den Quellcode mit WiFi/BLE? Ich habe nur die ...Working.ino als letzes gefunden ohne WiFi/BLE.
Gruß
Jörg
Hi,
Thank you Scotty for the great software solution. I can read and write in german but english just is a bit easier for me :)
I have one JK-BMS (200A/2A) in production but received 4 more BMS's this week I need to implement. (It will be 4 (each with there own BMS) x 1P16S x 200Ah (48v) and 1 x 2P8S * 304Ah (24v)).
The software is working great and I have had a look through the code. I already tried to add the OTA function but for some reason I havn't got it to work yet. That might be due to the fact that I need to use the setting "Minimal SPIFFS with OTA" that sometimes gives these problems.
For myself I will I will add a kind of heartbeat function that will tell me when the board (e.g. problems with the BLE transmission) has problems so I can restart it (have to test wether or not by resetting by cutting the power (with a relay) or using the reset ping (also with a relay). What I have noticed is that when starting fort the first time after applying power I get the same error as stated on page 8.
12:06:18.442 -> - Created client
12:06:18.914 -> lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
12:06:18.914 -> - Connected to server
After bootup and then a reset for a second try usally fixes this.
Then I have a request: Would it be possible to add the error codes like "overvoltage" to the code. I would add them my self but i'm not sure on what adresses they might sent the data?
Thank you so much.
Best regards,
Gert
Hey no Problem ;)
yes at the moment there is not OTA update and form my side at the moment i do net need this Feature ;) but for shure could be one Point for further impl :)
regarding the Hearbeat this is waht i think about since a long time also ;) maybe i schould bring this in the next version also ...
but Sorry i do not understand the Error... from my side it works fine at the first Startup ..
and at least regarding the overvoltage if you can tell me where i can find this Information than i can impl this .... ;)
Hallo,hey schau mal auf den ersten Post da habe ich das angefügt und Pflege ich es nun ;) dann muss man nicht alles durchschauen ;)
hat jemand den Quellcode mit WiFi/BLE? Ich habe nur die ...Working.ino als letzes gefunden ohne WiFi/BLE.
Gruß
Jörg
Hier ist der Log, scheint beim BLE Reconnect zu hängen:
Notify callback for characteristic 0000ffe1-0000-1000-8000-00805f9b34fb of data length 128
data: 0, 0, 4E, 0, 22, 0, 5F, 0, 0, 0, B0, F7, 2, 51, 55, 7C, 2, 0, 40, D, 3, 0, C, 0, 0, 0, FF, 1A, 26, 0, 64, 0, 4, 2, DB, 2A, 32, 0, 1, 1, 2C, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 1, 0, 0, 0, 4F, 4, 0, 0, 0, 0, 61, E6, 3F, 40, DC, 0, 0, 0, 58, AA, FD, FF, 0, 0, 0, 1, 0, 5, 0, 0, 75, BC, 7A, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Notify callback for characteristic 0000ffe1-0000-1000-8000-00805f9b34fb of data length 44
data: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6D,
New Data for Analyse Complete...
Cell Voltages = 3.087V, 3.087V, 3.086V, 3.087V, 3.086V, 3.084V, 3.086V, 2.948V, 2.944V, 2.953V, 3.087V, 2.945V, 2.972V, 2.917V, 2.917V, 2.943V,
unbekant 1 = 0, 0, FF, FF,
Average Cell Voltage = 3.014V,
Delta Cell Voltage = 0.171V,
Current Balancer = 3.333V,
unbekant 2 = 0, 0, 0, 0, 0, 0,
Battery Voltage = 48.230V,
Battery Power = 0.000W,
Charge Current = 0.000A,
Analyse = 0, 0, 66, BC, 0, 0, 0, 0
unbekant 3 = 0, 0, 0, 0, 0, 0,
Battery T1 = 7.800°C,
Battery T2 = 3.400°C,
MOS Temp = 9.500°C,
Balance_Curr = -1.968A,
unbekant 4 = 0, 0,
Percent Remain = 81%,
Capacity Remain = 162.901,
Nominal Capacity = 200.000,
Cycle Count = 12,
unbekant 5 = 0, 64, 0, 26, 1A, FF,
Capacity Cycle = 0.516,
Tage: 38 Stunden: 1 Minuten: 16 Sekunden: 11
unbekant 5 = 0,
Charge on? = on,
Discharge on? = on,
unbekant 7 = 2C, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 1, 0, 0, 0, 4F, 4, 0, 0, 0, 0, 61, E6, 3F, 40, DC, 0, 0, 0, 58, AA, FD, FF, 0, 0, 0, 1, 0, 5, 0, 0, 75, BC, 7A, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, Status of ble_Connect: 1
Get Deivce Dates Rerended...
Status of ble_Connect: 1
BLE -> Retry: 2
BLE -> Reconnecting!
danke für den Log bin gespannt ob es beim DWL auch so aussieht das sieht erstmal komisch aus ...ich schau mir das heute Abend mal in ruhe an ^^ was ich jetzt schon sagen kann ist das er das Senden der Daten einstellt ;) also das BMS ...
Hallo,
erste kurze Analyse:
1. Prüfen ob WiFi verbunden ist sollte in der loop() als erstes stehen. Wenn kein WiFi, dann auch kein MQTT möglich. So wird Zeit auf MQTT re-connect verschwendet, was eh nicht geht.
2. MQTT bringt einen Quasi-Heartbeat mit. Einfach ein Topic auf LastWill setzen. Wenn der Client sich nicht in x-Zeit meldet (geschieht bei MQTT im Hintergrund), dann wird LastWill Topic auf den definierten Wert gesetzt.
Ich mache es so, dass ich im LastWill beim Verbinden den Wert "offline" mitgebe, nach erfolgreichem Verbinden setze ich das Topic auf "online". Bezüglich BLE habe ich noch nie etwas gebastelt, kann daher nichts beitragen.
3. WLAN Verbindungsaufbau ist recht rudimentär, habe aber im Moment keine Beispiele vor Ort.
Den Arduino-Style mit millis()-Prüfungen würde ich bei ESP32 umgehen und mit FreeRTOS Tasks arbeiten. Dann können weniger Probleme mit WiFi (Kernel 0) und Applikation (Kernel 1) auftreten. Da habe ich bisher die meisten Probleme mit gehabt.
Gruß
Jörg
Hallo,Danke dir fürs Feedback ;)
erste kurze Analyse:
1. Prüfen ob WiFi verbunden ist sollte in der loop() als erstes stehen. Wenn kein WiFi, dann auch kein MQTT möglich. So wird Zeit auf MQTT re-connect verschwendet, was eh nicht geht.
2. MQTT bringt einen Quasi-Heartbeat mit. Einfach ein Topic auf LastWill setzen. Wenn der Client sich nicht in x-Zeit meldet (geschieht bei MQTT im Hintergrund), dann wird LastWill Topic auf den definierten Wert gesetzt.
Ich mache es so, dass ich im LastWill beim Verbinden den Wert "offline" mitgebe, nach erfolgreichem Verbinden setze ich das Topic auf "online". Bezüglich BLE habe ich noch nie etwas gebastelt, kann daher nichts beitragen.
3. WLAN Verbindungsaufbau ist recht rudimentär, habe aber im Moment keine Beispiele vor Ort.
Den Arduino-Style mit millis()-Prüfungen würde ich bei ESP32 umgehen und mit FreeRTOS Tasks arbeiten. Dann können weniger Probleme mit WiFi (Kernel 0) und Applikation (Kernel 1) auftreten. Da habe ich bisher die meisten Probleme mit gehabt.
Gruß
Jörg
1. ja das habe ich gestern Abend beim "review" mir auch gedacht und schon in meienr "Lokalen" 1.72 geändert ;)
2. bau ich gleich ein ;) ich nutze dafür aktuell das IoBroker Signal (Connection) was die verbunden Geräte anzeigt... wenn es verschwindet weiß ich das er offline ist...
3. ja das stimmt aber mehr muss es ja nicht sein oder ;) es geht ja an für sich auch ...
was meinst mit millis()-Prüfungen ??? ich versuche ja schon wo es geht auf Delay zu verzichten und bau er zeitliche abfragen ein ;)
Hallo,
ich habe mal versucht ein wenig durchzublicken. Ehrlich liest sich der Quelltext extrem schwer.
Ich lagere gerne Zusammenhängende Themen in eigene Tabs aus, das wird ein wenig übersichtlicher, auch wenn die Arduino IDE das nur rudimentär unterstützt.
Weiterhin darf eigentlich keine Methode länger als ein Bildschirm sein, lieber in viele Methoden auslagern. Ausnahme: Serial-Ausgaben oder so, auch wenn man es da machen kann.
Aber gut, einige Kommentare darin sind vielleicht nicht 100%ig korrekt, habe aber jetzt einige Zeit aufgewendet und wollte nicht nochmal alles durchgehen.
=> WiFi und MQTT koppeln, d.h. MQTT sendet zyklisch die Daten, auch wenn diese veraltet sind.
=> Bluetooth wird anscheinend verwendet, um die Daten auszulesen. Dachte hier wird RS485 genutzt, daher ein paar falsche Annahmen.
Im loop würde ich daher alles auf WiFi, MQTT und BLE Verbindung prüfen und ggfs. neu aufsetzen.
Da ich nichts mit BLE bisher gemacht habe, weiss ich nicht ob BLE Verbindung aufgebaut wird, wenn die Daten gelesen werden sollen, oder ob eine ständige Verbindung da sein soll.
Das mit millis()-Prüfungen habe ich im Quelltext mal dargestellt. xTaskCreate erstellt einen OperatingSystem Task (RTOS), der jede Sekunde vom OS aufgerufen wird.
Wichtig: Das alles ist für den ESP32 geschrieben, beim ESP8266 muss einiges anders gemacht werden.
Leider kann ich in meiner Arduino IDE nicht kompilieren. Er sagt mir das Sketch ist zu groß. Keine Ahnung warum, das ist peanuts gegenüber meinen "SmartHome"-Devices
Könnte am Import liegen. Ich nutze normalerweise nur PlatformIO mit VisualCode. Das ist um einiges freundlicher zu bedienen, wenn die ersten Hürden geschafft sind (und vor allem schneller, der kompiliert nicht immer wieder alles wie die Arduino IDE, sondern nur die geänderten Objekte).
Gruß
Jörg
11798=2674-BLE_client_v1.71x.zip|attachment (7.02 KB)
Guten Abend zusammen,
also etwas schlauer bin ich jetzt geworden und weiß schonmal das ich das BMS nicht dazu bekommen erneut die Daten zu senden ..... Oder anders gesagt nur wenn ich die BLE Verbindung trenne und wieder aufbaue...
und genau das habe ich dann jetzt auch in der Version 1.72 umgesetzt...
aus meine 3 Stufen Konzept ist ein wenn keine Daten mehr vom BMS nach 60sekunden kommen machen wir ein Reset Konzept geworden.
Änderungen:
-> wird ein Timeout vom BMS erkannt (kommen innerhalb von 60 Sekunden keine neuen Daten wird der ESP neu gestartet.)
-> zudem gibt es jetzt ein neuen Wert über MQTT -> Status (offline und online), mal sehen ob der auch wirklich offline anzeigt falls hier mal wieder was stehen bleibt ..
-> Wlan Status Check wird jetzt vor MQTT Status überprüft
@DerLang
VIELEN DANK dir dafür schon mal ...
ich bin ehrlich gesagt kein freund von dem RTOS weil es einfach für solch "einfache" Anwendung zu viel Speicher etc verbraucht
oder ich kenne mich damit einfach nicht gut genug aus bin ja kein Informatiker :mrgreen:
ich werde mir dein Code aber mal anschauen und die Idee der Umsortierung mitnehmen besser geht immer ... bestimmt kann ich da ein paar Ideen dann in die 2.0 übernehmen.
ggf bekomme ich es dann übersichtlicher hin. jetzt will ich erstmal die 1.X stabil bekommen
ggf. kannst du mir aber bei einem Problem helfen wo ich gerade den "faden" verloren habe....
und zwar in der If schleife von " if (doConnect == true) {" Zeile 415
wird in Zeile 420 -> "BLEClient* pClient = BLEDevice::createClient();" das pClient angelegt ...
kannst du mir sagen wie ich das "global" oder "übergeben" bekomme das ich in der Zeile 522 anstelle "ESP.restart();" -> "pClient->disconnect();" aufrufen kann ?
dann könnte ich anstelle des ESP Neustart "einfach" das BLE Verbindung sauber trennen und dann wiederherstellen....