Deutsch
Beta: Zeitüberschreitung + Entzerrung beim gleichzeitigen Verbindungsaufbau der Dual-Bridge (Issues #61, #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.
Nach ausführlichen, präzise getimten Fehlerberichten in #79 (danke, PEPITO82!) und der ursprünglichen Vermutung in #61: der Verbindungsaufbau nach dem Koppeln (Verschlüsselung, MTU-Aushandlung, Dienst- und Merkmalserkennung, Benachrichtigungen aktivieren, erster Lesevorgang) hatte bisher keine Zeitüberschreitung und keinen Wiederholungsversuch. Wachen beide Räder fast gleichzeitig auf, zum Beispiel weil eine geschaltete Steckdose beide Ladegeräte gleichzeitig einschaltet, muss das einzige Funkmodul des klassischen ESP32 beide Verschlüsselungs- und Erkennungsabläufe fast im selben Moment bedienen. Bleibt eine Seite dabei zurück, blieb die Verbindung bisher entweder dauerhaft auf „verbunden" ohne Live-Daten stehen, oder wurde durch die viel gröbere BLE-eigene Überwachungszeitüberschreitung getrennt und blieb danach oft minutenlang unverbunden.
Zwei Änderungen:
- Eine Zeitüberschreitung pro Rad überwacht jetzt die gesamte Kette vom Verbinden bis zu echten Live-Daten. Wird sie erreicht, trennt die Bridge die Verbindung selbst sauber, sodass der ohnehin vorhandene Wiederverbindungs-Mechanismus einen frischen, unbelasteten Versuch bekommt.
- Der Start der Geräteerkennung wird verzögert, wenn die Erkennung des anderen Rads gerade noch läuft, damit das Funkmodul nie zwei frische, mehrstufige Abläufe gleichzeitig bedienen muss.
Compile-geprüft (CI grün, keine neuen Warnungen), aber noch nicht an echter Zwei-Bike-Hardware bestätigt. Diese Beta ist genau dafür gedacht: wer zwei Räder an einer Dual-Bridge betreibt und das gleichzeitige Verbinden reproduzieren kann, darf sie gerne testen und Rückmeldung geben.
English
Beta: timeout and staggering for simultaneous dual bridge connections (issues #61, #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.
Following detailed, precisely timed reports in #79 (thank you, PEPITO82!) and the original hypothesis in #61: the setup sequence after connecting (encryption, MTU exchange, service and characteristic discovery, enabling notifications, the initial read) had no timeout or retry anywhere. When both bikes wake up within a few seconds of each other, for example because one switched socket powers both chargers, the classic ESP32's single radio has to service both encryption handshakes and both discovery chains almost at once. If one side falls behind, the connection used to either sit stuck at connected with no live data forever, or get torn down by the much coarser link layer supervision timeout and then stay disconnected for minutes.
Two changes:
- A per slot timeout now watches the whole chain from connect to real live data. If it elapses, the bridge cleanly disconnects on its own, so the existing reconnect mechanism gets a fresh, uncontended attempt.
- Starting discovery for one bike is now delayed while the other bike's own discovery is still in flight, so the radio never has to service two fresh, multi step sequences at the same moment.
Compile checked (CI green, no new warnings) but not yet confirmed against real two bike hardware. This beta is exactly for that: if you run two bikes on a dual bridge and can reproduce the simultaneous connect, testing this and reporting back would be very welcome.
Nederlands
Beta: timeout en spreiding bij gelijktijdig verbinden op de dual bridge (issues #61, #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.
Naar aanleiding van gedetailleerde, nauwkeurig getimede meldingen in #79 (dank je wel, PEPITO82!) en het oorspronkelijke vermoeden in #61: de opzetvolgorde na het verbinden (versleuteling, MTU uitwisseling, service en kenmerk ontdekking, meldingen inschakelen, de eerste uitlezing) had tot nu toe geen timeout en geen nieuwe poging. Wanneer beide fietsen bijna gelijktijdig wakker worden, bijvoorbeeld omdat een geschakeld stopcontact beide laders tegelijk inschakelt, moet de enige radio van de klassieke ESP32 bijna op hetzelfde moment beide versleutelingsonderhandelingen en ontdekkingsreeksen afhandelen. Bleef een kant achter, dan bleef de verbinding tot nu toe ofwel voorgoed op verbonden staan zonder live gegevens, of werd ze verbroken door de veel grovere eigen bewakingstimeout van BLE en bleef daarna vaak minutenlang niet verbonden.
Twee wijzigingen:
- Een timeout per plek bewaakt nu de hele keten van verbinden tot echte live gegevens. Loopt die af, dan verbreekt de bridge de verbinding zelf netjes, zodat het al aanwezige herverbindingsmechanisme een verse, onbelaste poging krijgt.
- Het starten van de ontdekking voor de ene fiets wordt uitgesteld zolang de ontdekking van de andere fiets nog bezig is, zodat de radio nooit twee verse, meerstaps procedures tegelijk hoeft af te handelen.
Compilatie gecontroleerd (CI groen, geen nieuwe waarschuwingen), maar nog niet bevestigd op echte hardware met twee fietsen. Deze beta is daar precies voor bedoeld: wie twee fietsen op een dual bridge gebruikt en het gelijktijdig verbinden kan reproduceren, mag dit gerust testen en terugkoppelen.