ubuntuusers.de

Hallo liebe Community,

mein Bluetooth stellt immer nach ca. einem halben Tag den Betrieb ein.

Laut "sudo systemctl status bluetooth" läuft der Adapter/Service, aber meine Homeassistant Integration findet ihn nicht mehr und bekommt daher auch keine Daten mehr von den angeschlossenen Geräten (Temperatursensoren).

Im Anhang findet ihr eine Ausgaben, die ich so gesammelt habe (bluetoothNotRunning.txt).

Besonders interessant finde ich dabei die "rfkill" Ausgaben.

Augenscheinlich ist Bluetooth nicht gesperrt (Hard/Soft: 0), aber was heißt das dann?

Apr 13 19:04:49 homeassistant bluetoothd^[761]: src/rfkill.c:rfkill_event() RFKILL event idx 17480 type 2 op 0 soft 0 hard 0

Da hilft auch kein Neustart des Services, löschen der rfkill-List oder ein Neustart meines Homeassistants.

Nur ein Neustart des kompletten Rechners hilft.

Zum System:

• Distributor ID: Ubuntu

• Description: Ubuntu 22.04.2 LTS

• Release: 22.04

• Codename: jammy

• Produkt: Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge

Servus,

nochmal Deine Angaben durchgegangen, also umschreiben..

Hast Du im BIOS/UEFI die Möglichkeit die USB Energieeinst. auszuschalten/ also "immer an"? Ebenso das im OS.

+

lsmod | grep btusb

Davor und im Fehlerfall vergleichen.

Hi Marant--,

danke für deine schnelle Antwort.

Im Moment läuft es noch. ☺

Meine Energie-Einstellungen im OS (graphisch) sind auf "Ausgewogen".

Da gibt es nicht viele Optionen...

Mal schauen, ob da noch was auf der Konsole geht.

BIOS ist ein guter Tipp.

Ich mach das, wenn er wieder "abkackt".

Im Moment fass ich den nicht an, wenn so brav läuft. ☺

Im Anhang meine Liste der Befehle im laufenden Betrieb, falls es dich interessiert.

Dein "lsmod" hab ich auch mit aufgenommen.

Gruss, Daniel

Hist. Ausgabe, die Stunden anpassen, so kurz bevor der BT Controller "verschwand".

journalctl --since "1 hour ago" | grep -i blue

Das wäre für den laufenden Betrieb(die letzten 5 Minuten + Live), quasi als Monitor:

journalctl --since "5 min ago" -f | grep -i blue

-

Setze die Ausgabe(n) dann per Codeblock, oder Anhang ist auch OK.

Hallo zusammen,

es ist wieder passiert.

Diesmal habe ich den genauen Zeitpunkt mit "journalctl"-log (siehe Anhang: bluetoothLogUntilDie.txt).

Ab "Apr 17 16:47:25" beginnt das sterben. 😕

Übrigens ich betreibe meinen Homeassistant in einem Docker-Container.

Könnte das da noch reinspielen?

Ich schau mir jetzt gleich die Bluetooth settings im BIOS an, wobei ich nicht glaube, dass das Bluetooth einfach im Ruhemodus ist.

In der OS GUI schaltet es immer zwischen "Bluetooth ausgeschaltet" und "Kein Bluetooth gefunden". (siehe Anhang: bluetooth1.png und bluetooth2.png).

UPDATE: Ich habe nix im BIOS gefunden, was auf einen Ruhemodus hindeutet.

Wie müsste die Option denn heissen?

Ausserdem ist mein Homeassistant immer erreichbar, was LAN betrifft, also ist er nicht im Ruhemodus denke ich.

Es betrifft nur die Bluetooth Schnittstelle.

Vorerst(wg. journalctl):

Bluetooth settings im BIOS

Nicht BT, sondern USB. Ist darüber angebunden s.

kernel: usb 1-7: New USB device found, idVendor=8087, idProduct=0a2a, bcdDevice= 0.01

https://devicehunt.com/view/type/usb/vendor/8087/device/0A2A

auch da zu sehen:

hciconfig
lsusb

Also:

• Nach ggf. USB Energieeinst im BIOS/UEFI schauen.

• Hast Du die Möglichkeit mal einen ext. BT Controller zu nutzen? (Dann schauen, das der geänderte Controller tatsächlich genutzt wird)

• Mach mal den Rechner für ca. eine halbe Stunde aus(Strom Stecker/ Adapter ggf. raus), dann erst wieder ein. Kein Witz. Entladung/ Wird empfohlen bei solchen Problemen.

Ja, ich habe einen externen BT-Stick.

Den kann ich ausprobieren.

Aber da sollte ich vorher die interne HW deaktivieren, sonst gibts eventuell Konflikte und damit ganz andere Fehler, denke ich.

Und ja, das mit dem „ganz entladen“, habe ich auf meiner Suche in einem anderen Forum auch gelesen.

Hat mir aber nicht gefallen, denn das ist ja auch keine Dauerlösung.

Aber gut, versuche ich dann auch nochmal.

interne HW deaktivieren,

Wenn Du das über bluetoothctl oder blueman machst kannst Du doch den Controller selektieren. So sollten auch 2 Controller gehen. Das Clientgerät vorher aus dem internen entfernen.

..journalctl, naja für mich wenig aussagekräftig was die eigentliche Ursache betrifft.

Apr 17 16:47:25 homeassistant bluetoothd[771]: src/device.c:device_remove() Removing device /org/bluez/hci0/dev_64_72_8E_E0_AE_39

64:72:8E:E0:AE:39

Was ist Das? Oder sehe ich was vor lauter Bäumen nicht mehr..

Ja, das ist der Bluetooth Adapter. Die Frage ist, warum entscheidet sich das System dazu ihn zu entfernen? Ich war es nicht. 😁 Ich habe heute den Rechner heute für eine Stunde vom (Strom)Netz genommen. Mal schauen wie es weiter geht. Den externen Adapter hab ich noch nicht versucht, denn das wäre wirklich eine Notlösung, wenn ich den dranlassen müsste. Im Bios finde ich wirklich nix zu Energie und USB/UEFI. Das Bios ist ziemlich rudimentär. Ist ein AMI Bios. Der Rechner ist von NiPoGi. Der da: https://amzn.eu/d/fMZ3Vst Dummerweise wurde die Firma wohl verkauft, denn die Homepage wie sie auf dem Gehäuse steht, gibt es so nicht mehr. (http://inipogi.com) Sonst hätte ich auch nach einem Bios Update gesucht.

64:72:8E:E0:AE:39

das ist der Bluetooth Adapter.

Das meinte ich mit den Bäumen

[bluetooth]# show
show
Controller F0:77:C3:5F:53:24 (public)

bluetoothctl lässt sich übrigens auch so nutzen:

bluetoothctl -- list

–

Musste erstmal nachlesen. offb. ist die BD Adresse nicht fest, im Gegensatz zur MAC.

Wegen der 2 Controller Adressen, und kommt man nicht weiter, nehme ich ein eigenes Script um vllt. schlauer zu werden. Pfad in Autostart, oder starten per

nohup /pfad/scriptname.sh

Intervall 30s;Brauchst Du damit Hilfe, schreib's. Auch falls Du was hinzufügen willst.

#!/bin/bash
echo "################ $(date +%d-%m-%H:%M:%S) ###################" >> ~/bluetooth-status.txt
echo "$(bluetoothctl -- devices)" >> ~/bluetooth-status.txt

while true; do
	echo "### $(date +%H:%M:%S) ###" >> ~/bluetooth-status.txt
	echo "$(service bluetooth status | grep "Active:")" >> ~/bluetooth-status.txt
	echo "$(service bluetooth status | tail -5)" >> ~/bluetooth-status.txt
	echo "bluetoothctl -- list: $(bluetoothctl -- list)" >> ~/bluetooth-status.txt
	echo "device_remove: $(journalctl --since "45 sec ago" | grep "device_remove")" >> ~/bluetooth-status.txt
	echo "$(lsmod | grep "btusb")" >> ~/bluetooth-status.txt
	echo "$(rfkill)" >> ~/bluetooth-status.txt
	sleep 30
done

Stand 6:40

-

Falls der mal wieder sich verabschiedet hat probiere mal ob sich damit das ändern lässt.

sudo rmmod btusb
sudo modprobe btusb 

-

Was ist eigentl. mit der home-assistant.log(o.a.)? (sagt Inet)

Hi, du hängst dich ja richtig rein für mich. Danke dafür.

sudo rmmod btusb sudo modprobe btusb

Hab ich früher schon ausprobiert. Das bringt nix. Meiner Meinung nach ist die Adresse fest, genau wie eine MAC. Jedenfalls war sie bei mir immer die gleiche. 😁

Deine:

hciconfig --all
hci0:   Type: Primary  Bus: USB
        BD Address: F0:77:C3:5F:53:24  ACL MTU: 1021:5  SCO MTU: 96:6

sowie die aus journalctl

64:72:8E:E0:AE:39

Sehen irgendwie verschieden aus ☺ (wenn die 2. tatsächlich der Controller ist)

Lies mal..

Lies sich wie eine Art Auto-Suspend ohne aufwachen. Ist auf dem Rechner tlp installiert? Falls ja, probehalber deinstallieren.

Ansonsten vielleicht das Verhalten mal mit einem Live-System testen.