Open thelaoshi opened 6 years ago
Ok seems I narrowed it a bit down. If I restart the bluetooth daemon the Device gets online again, but after a few minutes I see this in the log:
Jun 07 02:23:52 rasp3 kernel: Bluetooth: hci0 command 0x200c tx timeout
Jun 07 02:23:52 rasp3 kernel: Bluetooth: Failed to disable LE scan: status 0x1f
And afterwards the binding seems to loose the connection to the item.
hi @thelaoshi, what version of Bluez are you running?
Make sure you use 5.47 version which is the most stable.
Hey, I initially tried the Arch Bundled version which is 5.49. Thats where I got the errors. Then I tried 5.47 but I did no reload/restart. So I first thought, that there is no difference, but today I tried everything again and switched back to 5.47 and now it seems to work :-) I see even more things now, too.
I now have this in the syslog though:
Jun 09 09:34:37 rasp3 [3147]: failed to execute '/usr/bin/hciconfig' '/usr/bin/hciconfig hci0:64 up': No such file or directory
Jun 09 09:34:37 rasp3 systemd-udevd[3146]: Process '/usr/bin/hciconfig hci0:64 up' failed with exit code 2.
Seems that hciconfig is not in the bluez default package ? Is it needed for anything? Not sure if just another packages from my os tries to use it.
Guess I was too optimistic .... still the same with 5.47. And the same error msg I posted above.
Right. It seems to me there is something wrong with the adapter driver or the adapter itself. According to your logs, it fails to stop scanning process. Could you please try to disable scan by using the bluetoothctl
?
pi@raspberrypi:~ $ bluetoothctl
select <adapter mac>
[bluetooth]# scan off
Discovery stopped
Have a look if it generates the same error in your syslog.
No it doesnt, but i get the message Failed to stop discovery: org.bluez.Error.Failed
directly in bluetoothctl.
I'm running openhab on an Rasp 3 with onboard bluetooth.
Ah ok i guess thats because discovery is already disabled ... somehow. If I try "scan on", scan off" I dont get the error msg.
And in the binding logs I seen, that it still finds the discovered items + I see them in the inbox. Still the added things are offline and in the logs it looks like the binding does not find them.
tried around with bluetoothctl and I just found out, that just a "power off" seems to help for a few minutes. The binding seems to notice that the power is off and turns it on again and finds the devices again too. Until the error message in the syslogs pops up again...
What's your kernel version? It seems to me there was a bug introduced in some recent versions of linux kernel:
https://bbs.archlinux.org/viewtopic.php?id=230366
I'm running
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux
Hi, I can confirm the bug on raspberry pi 3; I'm using OpenSuSE Leap 42.3 aarch64; the bug seems to span rather deep (and for quite some time). I'm using external bluetooth dongle, I was not able to find the issue within the bluetooth stack, rather than USB one, as usb over IP based dongles work fine to me.
In general, the issue is that bluez is waiting for confirmation from dongle, which never comes - possibly due to lost packet.
Btw, the SuSE kernel numbering reports 4.4.126 ; but there is the issue of custom numbering - SuSE guys often backport a lot of patches from higher upstream kernel releases.
Furthermore, in my experience, resetting the bluetooth dongle via hciconfig hci0 reset allows for recovery without restarting the bluetoothd, which can be automated upon parsing dmesg output. However, this requires elevated priviledges.
Unfortunately, the broken tx timeout also disrupts ongoing connections. I'm not sure whether the connected clients keep the broken connection or not, but I'm not able to connect to any other device unless I perform the reset.
The usbip dongle I currently use is shared from another raspberry pi 3, running libreelec with 4.9.80 kernel. So far, it works without any issues (though, I'm currently using custom bluetooth transport provider, that bypases tinyb and uses direct dbus calls instead).
Hey @xrucka,
(though, I'm currently using custom bluetooth transport provider, that bypases tinyb and uses direct dbus calls instead)
This is really awesome! I was going to use this library to do so! TinyB is annoying useless layer.
This is really awesome! I was going to use this library to do so! TinyB is annoying useless layer.
I ended up using it's upstream and wrote this. It might still have some issues (it still needs native libraries as the dbus library relies on unix sockets, which - at least back in java 1.5 - were not supported).
Unfortunately, I do not have enough experience with maven to force include of system classpath into the jar file, so it needs manual jar manifest modifications. Feel free to use it / comment on it / develop it further.
@xrucka this is very cool, I was dreaming to get rid of TinyB. I'll have a look what we can do to improve maven stuff and soon roll out your awesome transport!
BTW, those native libs are already in OH, both java-dbus (unfortunately the original one) and sockets ("utils"-something).
Referencing the original issue, as this seems quite related: #https://github.com/sputnikdev/eclipse-smarthome-bluetooth-binding-tinyb-transport/issues/1
I'm on Linux version 4.14.44-1-ARCH (builduser@leming) (gcc version 8.1.0 (GCC)) #1 SMP Fri Jun 1 13:13:07 UTC 2018
on my raspberry it helps to just do a "power off" with bluetoothctl. Seems as the binding recognizes this and then restarts the connection?
My tag somehow gets stale and offline soon after I added it from the inbox. It never gets discovered anymore nor does it get online I totally have to remove BT things and restart OH to get it back into discovery
Here is the debug output: