Deutsch
Beta, Runde 3: verfrühte Freigabe korrigiert + selbstheilendes Advertising (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 v1.19.52b2 erneut mit präzise getimten Logs getestet und zwei weitere, unabhängige Fehler gefunden.
Erstens: Die in Runde 2 eingeführte Freigabe des Advertising-Sperre wurde schon beim allerersten Notify eines Rads ausgelöst, nicht erst wenn die eigene Geräteerkennung dieser Bridge wirklich fertig war. Ein bereits gekoppeltes Rad kann offenbar ein Notify aus seinem eigenen, über die Wiederverbindung hinweg gespeicherten Benachrichtigungs-Status senden, noch bevor diese Bridge ihre eigene CCCD-Aktivierung überhaupt geschrieben hat. Das Log zeigt genau das: Notify um 42,933, Advertising wieder an um 42,946, aber CCCD-Schreibung und Initial-Read erst um 43,533 bzw. 43,771 abgeschlossen. Behoben, indem die Freigabe jetzt ausschließlich am Abschluss des Initial-Reads hängt, nie an einem gewöhnlichen Notify. Ob ein wirklich eingeschwungenes erstes Rad allein ausreicht, um das zweite zu schützen, lässt sich aus diesem Lauf nicht sicher ablesen, weil der Fehler selbst die Messung verfälscht hat — das braucht einen sauberen erneuten Test mit dem behobenen Fehler.
Zweitens, unabhängig davon: Nach dem dritten fehlgeschlagenen Reconnect-Versuch scheitert das eigene Advertising mit BLE_HS_ENOMEM, und danach versucht es niemand mehr erneut — ziemlich wahrscheinlich die eigentliche Erklärung für das ursprüngliche „bleibt eine Stunde weg". Neu: ein periodischer Wiederholungsversuch alle fünf Sekunden, solange ein Slot frei ist.
Wieder Compile-geprüft, noch nicht an echter Hardware bestätigt.
English
Beta, round 3: fixed a premature release + added self-healing advertising (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 tested v1.19.52b2 again with precisely timed logs and found two further, independent bugs.
First: the advertising hold introduced in round 2 was releasing on the very first notify from a bike, not once this bridge's own discovery had actually finished. A bonded bike can apparently send a notification from its own notification state retained across the reconnect, before this bridge has even written its own CCCD. The log shows exactly that: a notify at 42.933, advertising resuming at 42.946, but the CCCD write and initial read only completing at 43.533 and 43.771. Fixed by making the release depend only on the initial read finishing, never on an ordinary notify. Whether a genuinely settled first bike alone is enough to protect the second cannot be read reliably from that run, since the bug itself confounded the measurement, that needs a clean retest with the fix in place.
Second, independent of the above: after a bike's third failed reconnect attempt, this bridge's own advertising fails with BLE_HS_ENOMEM, and nothing ever tries again afterward, quite possibly the actual explanation behind the original hour long stalls. New: a periodic retry every five seconds while a slot is free.
Compile checked again, not yet confirmed on real hardware.
Nederlands
Beta, ronde 3: te vroege vrijgave gecorrigeerd + zelfherstellend adverteren (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.
PEPITO82 heeft v1.19.52b2 opnieuw met nauwkeurig getimede logs getest en twee verdere, onafhankelijke fouten gevonden.
Ten eerste: de in ronde 2 ingevoerde adverteerblokkade werd al opgeheven bij de allereerste notificatie van een fiets, niet pas zodra de eigen ontdekking van deze bridge echt klaar was. Een reeds gekoppelde fiets kan blijkbaar een notificatie sturen vanuit zijn eigen, over de herverbinding heen bewaarde meldingsstatus, nog voordat deze bridge zijn eigen CCCD-inschakeling heeft geschreven. Het log toont precies dat: notificatie om 42,933, adverteren weer aan om 42,946, maar CCCD-schrijven en de eerste uitlezing pas voltooid om 43,533 respectievelijk 43,771. Opgelost door de vrijgave nu uitsluitend te laten afhangen van het voltooien van de eerste uitlezing, nooit van een gewone notificatie. Of een echt ingeburgerde eerste fiets alleen voldoende is om de tweede te beschermen, kan uit die run niet betrouwbaar worden afgeleid, omdat de fout zelf de meting heeft vertekend, dat vraagt om een schone nieuwe test met de fix aanwezig.
Ten tweede, los daarvan: na de derde mislukte herverbindingspoging van een fiets mislukt het eigen adverteren van deze bridge met BLE_HS_ENOMEM, en daarna probeert niets het nog een keer, heel goed mogelijk de echte verklaring achter de oorspronkelijke uren durende storingen. Nieuw: een periodieke nieuwe poging elke vijf seconden zolang een plek vrij is.
Opnieuw compilatie gecontroleerd, nog niet bevestigd op echte hardware.