NEEY 4A Balancer

[kmn13]

Ich starte hier einmal eine Runde bezüglich der NEEY Balancer. Zwar gibt es schon ein paar Kommentare unter anderen Kapiteln - denke jedoch eine "Kanalisierung" macht Sinn.

@shining-man soweit ich gelesen habe, hast du die Anbindung mit 1x NEEY im Einsatz mit dem BSC.
Zur Prüfung der Performance etc, kann ich gerne etwas beitragen.
Ich habe bei mir 8 Stück "herumliegen" und diese sollen später dann kaskadiert eingesetzt werden.

Leider scheitere ich aktuell mit meinem Testboard ([https://amzn.eu/d/dFsBpOJ]) noch etwas mit einer generellen Verbindung.
Benutzte BSC Version 0.1.5 und einen aktuellen NEEY 4A der Generation 4 (von Aliexpress - HankzorBMS).
Der NEEY will einfach nicht gefunden werden. Wobei mit der "GeeWe BMS" App oder auch einem BLE Sniffer klappt die Verdindung.
Natürlich nicht gleichzeitig, aber das "blaue" Lämpchen zeigt an ob eine Verbindung besteht oder nicht.

Meine NEEYs sind: Hardware version: HW-2.8.0 und Software version: ZH-1.2.3

@shining-man welche Version vom NEEY hast du erfolgreich im Einsatz?

[shining-man]

Richtig, ich habe einen NEEY im Einsatz. FW/HW-Version schaue ich später einmal.

Sobald du die Seite Schnittstellen->Bluetooth offen hast, wird nach BT Devices gescannt und am unteren Ende der Seite angezeigt. Hier sollte er, unabhängig der Version des NEEY, die gefundenen Devices auflisten.
Wiki: https://github.com/shining-man/bsc_fw/wiki#schnittstellen---bluetooth
Was zeigt er hier bei dir an? Listet er überhaupt ein Device auf?

[shining-man]

Wenn es nicht funktioniert könntest du in der nimconfig.h CONFIG_BT_NIMBLE_LOG_LEVEL auf 0 setzen, dann wird mehr geloggt.

[kmn13]

alles klar ;-)
Ich hab die Änderungen einmal reingestopft - aber leider selbes Spiel 😢

Folgende Log konnte ich erstellen:
CONFIG_BT_NIMBLE_LOG_LEVEL = 0
NIMBLE_LOGLEVEL_0-221205-210413.log
Das verkraftet meine CPU nicht und geht zwischen dem Verbinden vom 1. und 2. NEEY in reboot.
Habe auch testweise den TAG Alarm deaktiviert, brachte ab eh nichts (wollte ein wenig die Serielle entlasten).

CONFIG_BT_NIMBLE_LOG_LEVEL = 1
NIMBLE_LOGLEVEL_1-221205-205448.log
Habe einmal versucht etwas weniger Loginfo. Stürzt nicht mehr ab, aber natürlich keine so genauen Daten

[kmn13]

🥳 ich habe es nun geschafft, die Verbindungen zu mehreren NEEYs ohne diese doofen NimBLE: Controller not ready to receive packets Meldungen zu erhalten ;-)
Es laufen nun auch wieder alle 7 und keine verdächtige Meldung^^

Nach nun längeren probieren und suchen bin ich über folgende Info gestolpert: https://github.com/h2zero/NimBLE-Arduino/blob/release/1.4/docs/Usage_tips.md#put-ble-functions-in-a-task-running-on-the-nimble-stack-core

Nun wird ja im nimconfig.h die NimBLE auf Core 1 gepinnt: #define CONFIG_BT_NIMBLE_PINNED_TO_CORE 1
Bis jetzt dachte ich, der ganze Appcode läuft auch am Core 1 -> bei mir läuft die task_ble jedoch am Core 0.
Festgestellt mit:

void task_ble(void *param)
{
  ESP_LOGD(TAG, "-> 'task_ble' runs on core %d", xPortGetCoreID());
.....

Ich habe nun die task_ble einmal auf denselben Core wie die NimBLE gepinnt: xTaskCreatePinnedToCore(task_ble,"ble", 3000, NULL, 5, &task_handle_ble, CONFIG_BT_NIMBLE_PINNED_TO_CORE);

Beim pinnen von Task und Lib auf Core 1 kommen die Fehlermeldungen, mit Core 0 nicht mehr👍.

Da ich sonst noch keine andere Hardware laufen habe, kann ich nicht feststellen ob nun andere Nebeneffekte hinzugekommen sind.
Aktuell sieht es einmal stabil aus - lief jetzt mind. 6h ohne Disconnects oder Controller not ready to... Meldungen durch 👍

@shining-man gab es einen speziellen Grund, dass die #define CONFIG_BT_NIMBLE_PINNED_TO_CORE 1 von default: auskommentiert (=0) auf 1 umgebogen wurde? Nur um zu wissen, wo vielleicht nun andere Nebengeräusche auftauchen könnten ;-)

[shining-man]

Ich habe den NimBLE auf Core 1 gepinnt, da ich sporadisch immer wieder Reboots aufgrund des Watchdogs hatte. Der NimBLE hat den Core 0 immer wieder blockiert und es somit zum reboot kam. Die meisten reboots sind bereits beim Connect des NEEYS aufgetreten. Das würde ich zumindest einmal testen. Ich würde mir eine kleine Testbench machen und z.B. den NEEY über ein Relais immer wieder aus-/einschalten und schauen ob er sauber verbindet. Und ich würde den Anlauf und den anschließenden ersten Connect anschauen und auch dies ausgiebig testen.

Vielleicht sollte man alle anderen Task fest auf Core 1 pinnen. Ich bin der Meinung, dass die Tasks bei meinen Tests auch auf Core 1 liefen und ich den BT Task dann eben auch auf Task 1 gepinnt habe...

[shining-man]

Ich habe mir noch einmal einen alten SW-Stand angeschaut, mit dem ich damals die Probleme hatte.
Mit der alten Version kann ich die damiligen Probleme reprodzieren. Mit der Version kommen dann wieder die Probleme mit den Reboots. Die Reboots treten meistens beim Starten des ersten BT-Scans nach dem Start des BSC auf. Festpinnen des NimBLE auf Core 1 bringt sofort Abhilfe. Ich wollte jetzt nicht mehr zuviel Zeit in die alte Version investieren. Mir ist nur aufgefallen, dass in der alten Version der BT-Task auch auf Core 1 läuft. In der aktuellen SW-Version läuft der BT-Task auf Core 0. Alle anderen Tasks laufen in der aktuellen Version aber auf Task 1. Woher das kommt, ist mir nicht ganz klar.

Ich habe jetzt in der aktuellen Version den BT-Task und NimBLE auf Core 0 gepinnt und alle anderen Tasks auf Core 1. So läuft es jetzt schon seit mehr als 24 h ohne Reboot. Parallel laufen einige Testroutinen in der die meisten Schnittstellen (3x Serial, CAN, onwire, Ansteuerung der DIs/DOs) ziemlich stark ausgelastet werden.

Was ich zwischen den Versionen grundlegend geändert habe, ist die Version der espressif32-platform und der NimBLE Lib. In der NimBLE Lib V1.4.0 wurde auch der NimBLE -Core aktualisiert.
Meine Vermutung ist, dass es irgendwie daran liegt. Da nach dem Tausch bei mir alles weiterhin funktioniert hat, habe ich auch keine weiteren Untersuchungen gemacht.

Ich habe die Tasks jetzt auf die entsprechenden Cores festgepinnt, damit es nicht zu „selbstständigen“ Änderungen bezüglich der Core Zuordnung kommt.

Ich pushe noch meinen aktuellen Teststand. Wenn du ihn auch noch einmal mit deinen 7 NEEYs testen kannst, wäre super👍, denn dann würde ich die Änderung in den Masterbranch übernehmen.

[kmn13]

Ich war beruflich unterwegs und konnte daher nicht weiter testen.

Werde mir den Letztstand ziehen und mal testen. Morgen Abend starte ich dann auch noch die Verbindungsversuche mit zyklischem aus/ein.
Gebe dir dann Feedback, wenn ich durch bin 😎

[kmn13]

Sodale 😅 habe jetzt mal einiges getestet:

• Langzeit Test (seit gestern Abend) mit 7xNEEY: lief durch ohne Probleme, jedoch habe ich nicht so viel Gesamtlast wie du
• BT - Disconnect Test: lief 200x ohne crash durch, nachdem Zeile 72 im BleHandler.cpp auf "%i" korrigiert wurde: ESP_LOGI(TAG, "Disconnected Device %i", i);

Ach ja: In der Git Version von nimconfig.h ist das NimBLE Pinning noch auf "0" zurück gestellt^^

Ich denke mal, es kann nach den obigen Änderungen so in den Master Branch 👍

[shining-man]

Ich habe es jetzt wieder in dem main Branch gemerget.

[shining-man]

Heute hat meine Testbaugruppe, die jetzt einige Tage lief, einen Reboot gemacht und beim Neuanlauf hatte sie dann beim BT Connect immer wieder einen Rebbot gemacht, bis es irgendwann wieder lief. Die gleichen Probleme die ich damals hatte.
Kannst du einmal testen wie sich deine 7 NEEYs verhalten, wenn du sowohl den BT-Task als auch NimBLE auf Core 1 pinnst?
Aktuell ist beides auf Core 0 gepinnt.

[shining-man]

Ok, danke. Dann macht das Umpinnen keinen Sinn. Ich werde wohl das Problem finden müssen. Der Backtrace hilft mir auch nicht weiter, da CORRUPTED.
Was war die längste Zeit die du die 7 NEEYS laufen gelassen hast und gab es dabei einmal einen Reboot?

[kmn13]

bei mir liefen die am Core 0 etwas mehr als 24h ohne Probleme oder Reboots.
Ich musste danach wieder etwas umbauen bzw meinen Laptop anderweitig nutzen, sodass ich stoppen musste.

[kmn13]

Ich hatte nun ein sepparates Testsystem aufgebaut, welches nur NEEY und Webserver übersicht offen spielt.
Nach 18h trennte sich 1x NEEY mit disconnect, reason=520 baute aber gleich wieder eine Verbindung auf (müsste: BLE_ERR_CONN_SPVN_TMO - Connection Timeout sein).
Nun ein paar Stunden später ist alles abgeschmirrt...keine Ausgabe seriellen Log oder im Logfile ...hmm.... und per IP nicht mehr erreichbar.

Ich habe immer wieder einmal einen Blick auf den Heap geworfen, der war eigentlich immer annähernd gleich.

Muss das noch einmal wiederholen...

[shining-man]

Kann es auch sein, dass die NEEY Kommunikation weiterhin lief und nur der Webserver abgeschmiert ist? An der BSC HW siehst du das anhand der blinkenden LED.
Wie hast du festgestellt, dass er abgeschmiert ist? Was war hierbei deine Aktion?

Du könntest in der main-Loop und in den Tasks ein Lebenszeichen, z.B. alle Sekunde, auf der seriellen-Schnittstelle ausgeben lassen, um zu sehen welcher Task abschmiert.

Wenn der Heap überlaufen würde, dann gebe es einen Reboot, den hattest du ja aber nicht... Das wäre schöner, denn dann hätten wir einen Backtrace.

[kmn13]

Die "orig" BSC HW habe ich ja leider (nocht) nicht ;-)
Erkannt dadurch: alles NEEY getrennt (dann blinkt dort die blaue LED) aber keine Info im seriellen Trace (da kommt ja sonst der ganze Disconnect output). BSC auch nicht mehr erreichbar...auch nicht per Ping.

Hab mal in jede Task einen Hearbeat ins Log eingepflanzt.