Okay, ich habe jetzt aus dem ganzen ein PR erstellt. Jetzt sind da leider mehrere Dinge fürs Bluetooth drin.
BITTE testet das mal, damit ich das nachbessern kann bzw. wir das in den DEV übernehmen können
Improve Bluetooth status, scanning, reconnect handling and web UI by joker-mik · Pull Request #461 · biologist79/ESPuino
Bluetooth-Verwaltung und Verbindungsstatus überarbeitet
Ich habe die Bluetooth-Funktionen und die dazugehörige Weboberfläche etwas grundlegend überarbeitet. Ziel war vor allem, die Bedienung verständlicher zu machen und die Verbindungsverwaltung im Bluetooth-Source-Modus robuster zu gestalten.
Bisher war insbesondere beim Verbinden, Wechseln und Wiederverbinden von Bluetooth-Kopfhörern nicht immer eindeutig, was das Gerät gerade macht. Außerdem gab es einige Fälle, in denen Scan-, Retry- und Verbindungsstatus nicht sauber voneinander getrennt waren.
Weboberfläche
Der Bluetooth-Bereich im Webinterface wurde überarbeitet. Die verschiedenen Betriebsarten sind jetzt klarer voneinander getrennt:
- Normalbetrieb
- Bluetooth Source, z. B. für Bluetooth-Kopfhörer
- Bluetooth Sink
Für den Source-Modus wird außerdem der aktuelle Verbindungsstatus angezeigt. So ist direkt im Webinterface erkennbar, ob gerade eine Verbindung besteht.
Die Geräteliste und die Scan-Bedienung wurden ebenfalls überarbeitet. Dabei wurde auch das Verhalten auf kleineren Displays bzw. Smartphones verbessert.
Die neuen Texte wurden für Deutsch, Englisch und Französisch ergänzt.
Bluetooth-Scan
Das Scannen nach Bluetooth-Geräten wurde robuster gemacht. Scan-Zustand und Callback-Verwaltung werden jetzt expliziter behandelt, damit sich ein manueller Scan aus dem Webinterface nicht mit der normalen A2DP-Verbindungslogik in die Quere kommt.
Nach einem manuellen Scan wird der ursprüngliche Bluetooth-Callback wiederhergestellt.
Verbinden und Gerätewechsel
Auch die Verbindungslogik wurde überarbeitet.
Beim Wechsel von einem bereits verbundenen Gerät zu einem anderen wird die bestehende Verbindung zunächst gezielt beendet und anschließend die neue Verbindung aufgebaut.
Wichtig war dabei, einen absichtlich ausgelösten Disconnect nicht fälschlicherweise als fehlgeschlagenen Verbindungsversuch zu zählen.
Retry-Verhalten
Die Retry-Zählung wurde korrigiert.
Ein Retry wird jetzt nur dann gezählt, wenn tatsächlich ein neuer Verbindungsversuch gestartet wird. Doppelte oder verspätete DISCONNECTED-Events verbrauchen damit nicht mehr versehentlich zusätzliche Retry-Versuche.
Der Ablauf ist jetzt sinngemäß:
erster Verbindungsversuch
→ Retry 1/3
→ Retry 2/3
→ Retry 3/3
→ Abbruch
Die zugehörigen Zustände werden nach erfolgreicher Verbindung oder nach endgültigem Abbruch wieder sauber zurückgesetzt.
Fix für Auto-Reconnect und laufende Bluetooth-Discovery
Bei den Tests ist noch ein weiteres Problem aufgefallen.
Wenn ein bereits gekoppelter Bluetooth-Kopfhörer ausgeschaltet und später wieder eingeschaltet wurde, konnte sich ESPuino automatisch wieder verbinden. Im Log waren nach dem erfolgreichen Reconnect aber weiterhin über längere Zeit Meldungen wie
Bluetooth source => Device found: ...
zu sehen. Und die Wiedergabe ruckelte.
Die Ursache war, dass die A2DP-Bibliothek während des Auto-Reconnects eine eigene GAP-Discovery starten kann. Diese Discovery wurde von unserem bisherigen scanInProgress-Status nicht erfasst, weil dieser nur den manuellen Scan aus dem Webinterface abbildet.
Dadurch konnte die Discovery auch dann weiterlaufen, wenn die A2DP-Verbindung bereits wieder hergestellt war und die Audiowiedergabe schon begonnen hatte.
Das wurde geändert: Sobald eine Bluetooth-Source-Verbindung erfolgreich hergestellt wurde, wird eine eventuell noch laufende GAP-Discovery beendet.
Der manuelle Web-Scan benutzt weiterhin den bisherigen vollständigen Cleanup-Pfad, damit UI-Zustand und Callbacks korrekt zurückgesetzt werden.
Test
Getestet wurde unter anderem folgender Ablauf:
Bluetooth-Kopfhörer verbinden
→ Kopfhörer ausschalten
→ Disconnect abwarten
→ Kopfhörer wieder einschalten
→ automatischer Reconnect
→ Wiedergabe fortsetzen
Vor der Änderung lief die Bluetooth-Discovery nach dem Reconnect teilweise noch weiter.
Nach dem Fix wird sie mit erfolgreicher Verbindung beendet. In meinem Test lief der Reconnect damit sauber und die vorher beobachteten Device found-Meldungen nach erfolgreicher Verbindung traten nicht mehr auf.
Sonstiges
Zusätzlich wurden die REST-API-Dokumentation und die Übersetzungen angepasst.
Der Bluetooth-Verbindungsstatus wird im Webinterface nur abgefragt, wenn sich das Gerät im Bluetooth-Source-Modus befindet und der Bluetooth-Tab geöffnet ist. Dadurch entsteht im normalen Betrieb kein permanentes zusätzliches Polling.
.