-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gigaset G-tag gets stale shortly after added #52
Comments
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:
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:
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
Have a look if it generates the same error in your syslog. |
No it doesnt, but i get the message I'm running openhab on an Rasp 3 with onboard bluetooth. |
Ah ok i guess thats because discovery is already disabled ... somehow. 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
|
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). |
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: #sputnikdev/eclipse-smarthome-bluetooth-binding-tinyb-transport#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:
The text was updated successfully, but these errors were encountered: