BLE-Verbindung: Handshake-Robustheit & Feature-Erkennung ausbauen¶

Kontext¶

BleFtmsErgometer baut die GATT-Session best-effort auf: RequestControl + StartOrResume wurden genau einmal gesendet, ohne Auswertung der Antwort. Ablehnungen (OnControlPointResponse) wurden nur geloggt, 0x2ACC (Fitness Machine Feature) wurde nie gelesen, und bei verlorener Control wurde nie neu angefragt.

Umsetzung¶

1. Verbinden (EstablishConnectionAsync)¶

• RequestControl senden, pro Versuch ~2 s auf die Indication warten.
• Success: Control gewährt, danach StartOrResume.
• Stille (keine Antwort) oder nicht auswertbarer Code (0x02, 0x03, unbekannt): sofort weiter wie bisher (Zustand "Assumed"), einmaliger Hinweis im Log. Kein Verbindungsfehler, keine Verzögerung.
• Nur bei ausdrücklicher Ablehnung (0x05 Control Not Permitted, 0x04 Operation Failed): Retry im 1-s-Takt bis ~10 s, danach schlägt die Verbindung fehl (der bestehende Verbindungs-Loop versucht es erneut).

2. Control verloren¶

Antwortet das Gerät auf Set Target Power mit 0x05, startet im Hintergrund eine Recovery (RequestControl, StartOrResume, letzter Soll-Wert). Begrenzt auf 3 aufeinanderfolgende Versuche, danach 30 s Pause. Bei "Assumed" (Stille) gibt es keine Recovery. Der UI-Thread wartet nie auf die Indication (der Poll-Tick läuft auf dem UI-Thread).

3. Feature-Erkennung 0x2ACC (Minimalversion, im Ticket enthalten)¶

Target Setting Features Bit 3 (Power Target Setting) auswerten. Gelesen und Bit fehlt: reines Messgerät, kein RequestControl/StartOrResume, keine Steuerbefehle. Fehlt 0x2ACC oder ist sie nicht lesbar: Verhalten wie bisher (Abweichung von "degradieren auf Reinlesen", um Regressionen bei schlecht implementierten Geräten zu vermeiden).

4. Ergebnisauswertung¶

Result Codes werden über eine einmalige Mapping-Tabelle klassifiziert (Spec: 0x02 Op Code Not Supported, 0x03 Invalid Parameter, 0x04 Operation Failed, 0x05 Control Not Permitted). Set Target Power mit 0x02 schaltet weitere Soll-Werte ab, 0x03/0x04 werden nur einmal geloggt.

5. Lifecycle¶

Recovery und offene Wartende werden in CloseConnection abgebrochen.

Tests¶

• Neues Unit-Test-Projekt ErControl.Core.Tests (xUnit) für Parsing, Result-Code-Tabelle, Zustandsmodell und Recovery-Begrenzung.
• BleFtmsReceiver (Simulator) erweitert um die Befehle reject N, silent, lose, nopower für die manuelle Abnahme.

Nicht Teil dieses Tickets¶

• Kein 0x2AD8-Verhalten (bleibt wie ist).
• Keine Sportart-Erkennung aus Advertising-Service-Data.
• Kein Parsing von Speed/Distanz/Energie.

Akzeptanzkriterien¶

• Lehnt ein Gerät RequestControl dauerhaft ausdrücklich ab (0x05/0x04), schlägt die Verbindung nach ~10 s fehl.
• Nach ControlNotPermitted auf Set Target Power wird Control neu angefragt (max. 3 Versuche, dann 30 s Pause) und der letzte Soll-Wert erneut geschrieben.
• Geräte, die RequestControl nicht bestätigen oder mit 0x02/0x03 beantworten, verbinden wie bisher.
• Nicht-steuerbare Geräte (0x2ACC ohne Power Target Setting) verbinden als reine Messgeräte, ohne Fehler-Spam.
• Kein UI-Einfrieren durch die Recovery.

Offene Risiken (nur mit echtem Gerät prüfbar)¶

• Ob reale Trainer nach Control-Verlust zusätzlich StartOrResume brauchen (wird vorsorglich mitgesendet).
• Ob steuerbare Geräte RequestControl dauerhaft mit 0x04 beantworten (dann Verbindungsfehler nach ~10 s). Beta-Test mit echtem Trainer empfohlen.