v1.19.52b7

Deutsch

Beta, Runde 7: „Geister-Verbindungen" gezielt jagen, vollständiges Terminierungs-Logging (Issue #79)

Reine Firmware-Änderung an der experimentellen Zwei-Bike-Bridge (bosch_ebike_ldi_dual, factory-dual.yaml). Die einfache Bridge (bosch_ebike_ldi) ist nicht betroffen.

PEPITO82 hat mit zwei weiteren Testläufen die eigentliche Hauptursache der langen Wartezeiten gefunden: Eine „Geister-Verbindung", die vom Bluetooth-Controller bereits reserviert ist (erkennbar daran, dass jeder Advertising-Versuch mit „kein Speicher mehr frei" scheitert), aber der Bridge selbst nie als Verbindungsereignis gemeldet wird — bis NimBLEs eigener, fest einprogrammierter 30-Sekunden-Timeout aufgibt. In den beiden Testläufen entfielen 40 von rund 50-60 Sekunden Wartezeit genau darauf, nicht auf die in Runde 6 behobene blockierte Geräteerkennung.

PEPITO82s eigene Erkennungsidee umgesetzt: Scheitert das Advertising mit „kein Speicher mehr frei", während genau ein Rad verbunden ist, muss die zweite, unsichtbare Verbindung diesen Zustand verursachen — und bei dieser Hardware kommen dafür nur zwei mögliche Kennungen infrage. Die Bridge versucht jetzt gezielt, genau diese „Geister-Verbindung" selbst zu beenden. Ob das tatsächlich funktioniert, ist noch offen — deshalb loggen jetzt alle relevanten Beendigungs-Versuche ihr Ergebnis, auch im Erfolgsfall, nicht nur bei Fehlern wie bisher.

Wieder Compile-geprüft, noch nicht an echter Hardware bestätigt.

English

Beta, round 7: actively hunting "ghost connections", full termination logging (issue #79)

Firmware only change to the experimental two bike bridge (bosch_ebike_ldi_dual, factory-dual.yaml). The single bike bridge (bosch_ebike_ldi) is unaffected.

PEPITO82's two further test runs found the actual dominant cause of the long waits: a "ghost connection" the Bluetooth controller has already reserved (evidenced by every advertising attempt failing with "out of memory") but that never gets reported to the bridge as a connection event at all, until NimBLE's own hardcoded 30 second timeout finally gives up on it. Across both runs, 40 of roughly 50 to 60 seconds of total wait time was exactly this, not the stalled discovery round 6 already addressed.

Implemented PEPITO82's own detection idea: if advertising fails with "out of memory" while exactly one bike is connected, the second, invisible connection must be causing that state, and on this hardware only two possible identifiers are ever in play. The bridge now actively tries to end that exact "ghost connection" itself. Whether this actually works is still an open question, so every relevant termination attempt now logs its result, success included, not only failures as before.

Compile checked again, not yet confirmed on real hardware.

Nederlands

Beta, ronde 7: gericht jagen op "spookverbindingen", volledige logging van beëindigingspogingen (issue #79)

Alleen een firmwarewijziging voor de experimentele bridge voor twee fietsen (bosch_ebike_ldi_dual, factory-dual.yaml). De bridge voor één fiets (bosch_ebike_ldi) is niet geraakt.

Met twee verdere testruns heeft PEPITO82 de eigenlijke hoofdoorzaak van de lange wachttijden gevonden: een "spookverbinding" die de Bluetooth-controller al heeft gereserveerd (te herkennen doordat elke adverteerpoging mislukt met "geen geheugen meer vrij"), maar die nooit als verbindingsgebeurtenis aan de bridge wordt gemeld, totdat NimBLE's eigen vast ingebouwde timeout van 30 seconden uiteindelijk opgeeft. In beide runs ging 40 van ongeveer 50 tot 60 seconden totale wachttijd precies hierin op, niet in de vastgelopen apparaatherkenning die ronde 6 al aanpakte.

PEPITO82's eigen detectie-idee geïmplementeerd: als adverteren mislukt met "geen geheugen meer vrij" terwijl precies één fiets verbonden is, moet de tweede, onzichtbare verbinding die toestand veroorzaken, en op deze hardware zijn daarvoor maar twee mogelijke identificaties in omloop. De bridge probeert nu gericht die exacte "spookverbinding" zelf te beëindigen. Of dit daadwerkelijk werkt is nog een open vraag, dus elke relevante beëindigingspoging logt nu het resultaat, ook bij succes, niet alleen bij mislukkingen zoals voorheen.

Opnieuw compilatie gecontroleerd, nog niet bevestigd op echte hardware.