presenced - Probleme beim Zugriff auf bluetooth Geräte

[pjakobs]

Moin zusammen,

ich habe seit geraumer Zeit immer wieder mal Probleme, auf meine Bluetooth Devices zuzugreifen.

Ich habe nicht herausfinden können warum, aber wie es aussieht, verabschiedet sich ein Bluetooth Device, das Ergebnis ist dann dieses:

Code Auswählen Erweitern


hcitool scan
Scanning ...
Inquiry failed: Device or resource busy


lösen lässt sich das, indem ich das hci Device selbst zurücksetze:

Code Auswählen Erweitern


sudo hciconfig hci0 reset


wäre es denkbar, in den presenced eine entsprechende Fehlerbehandlung einzubauen - eventuell optional, aber eigentlich sollte kein zweiter Prozess den BT Adapter verwenden, oder?

Ich würde ja glatt einen entsprechenden Patch schreiben, aber svn...

Was ich mir vorstelle wäre inetwa sowas: (nicht wirklich groß getestet, läuft aber jetzt erstmal bei mir)

Code Auswählen Erweitern


if( -x "$hcitool")
                         {
                             $return = qx(hcitool name $address 2>&1);
                             if ($? != 0){
                                # we got an error
                                $return = qx(hciconfig hci0 reset && hcitool name $address 2>&1); #let's just try it - no more error handling here
                             }
                         }


klar, lieber wäre mir, ich könnte herausfinden, _warum_ das hci Gerät hängt, aber ein guter Workaround ist Gold wert

Grüße

pj

[mumpitzstuff]

Wenn du mit irgendwas wie z.b. presenced auf ein Bluetooth Device zugreifst, dann ist dieses Gerät quasi exklusiv geblockt. Andere Services können dann entweder nicht mehr zugreifen (dein Fall) oder aber sie stehlen sich den Zugriff. Dann funktioniert aber der andere Service nicht mehr ordnungsgemäß. Wenn du also ein Bluetooth Device für presenced oder lepresenced verwendest, dann musst du jegliche anderen Zugriffe auf das Device verhindern. Willst du trotzdem andere Dinge mit Bluetooth machen, brauchst du einen zweiten Bluetooth Dongle, den du dann z.b. über hci1 ansprechen kannst.

Effektiv umgehen liesse sich das Problem nur, wenn man in FHEM eine zentrale Bluetooth Queue implementieren würde UND diese dann von jedem Modul genutzt werden würde. Dann ließen sich die Anfragen zumindest serialisieren, auch wenn die Quality of Service darunter leidet (presence könnte z.b. 1-2 Minuten lang keinen Status abfragen, wenn ein anderes Gerät Zugriff benötigt).

[pjakobs]

klar, aber auf diesem Gerät hat nichts anderes Zugriff auf hci0 bzw. es läuft nichts anderes, was Zugriff bräuchte.
Während ich das schreibe - ich schau nochmal nach, ob vielleicht ALSA ... nein, kein Bluetooth Backend für ALSA.
Wenn irgendwas das Gerät blockiert, dann presenced selbst, aber dann sollte da ein unblocking mechanismen für die unterschiedlichen Threads existieren (ist der nicht eh da? Ich sehe da ein wait(rnd(1)+1) )

pj

[isy]

Ist bei mir auch so.
Wenn lepresenced läuft, dann ist der Bluetooth Stack für andere Anwendungen gesperrt.
Gruß Helmut

[mumpitzstuff]

Es hatte für mich so ausgesehen als ob du parallel zu presenced ein scan abgesetzt hättest. Wenn das nicht der Fall ist, dann ist das Verhalten deines Bluetooth Dongles komisch. Ich habe sowas mit lepresenced nicht feststellen können. Vielleicht versuchst du mal von presenced auf lepresenced zu wechseln? Ich bin aber auch nicht sicher, ob sich lepresenced bei einem instabilen Dongle besser verhält.

[pjakobs]

Es hatte für mich so ausgesehen als ob du parallel zu presenced ein scan abgesetzt hättest. Wenn das nicht der Fall ist, dann ist das Verhalten deines Bluetooth Dongles komisch. Ich habe sowas mit lepresenced nicht feststellen können. Vielleicht versuchst du mal von presenced auf lepresenced zu wechseln? Ich bin aber auch nicht sicher, ob sich lepresenced bei einem instabilen Dongle besser verhält.

hatte ich auch, allerdings hatte ich dazu den presencd gestoppt.

und: Hintergrund ist ja nicht, dass ich hcitool scan nutzen wollen würde, sondern dass presenced immer mal wieder kein Ergebnis liefert und das halt als Abwesenheit gewertet wird. In diesem Zustand ist das hci Device dann nicht mehr ansprechbar, was aber durch den das "hci0 reset" gelöst werden kann. Daher mein Vorschlag das als mögliche Fehlerbehandlung in das Modul aufzunehmen.

pj