-
Notifications
You must be signed in to change notification settings - Fork 2
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
Unable to enumerate bluetooth devices #6
Comments
I also got this in the logs:
we probably can ignore these ones as I believe they have the same root cause. Normally Bluez allows you to set bt alias even if device is disconnected. |
I'll dig further and let you know how it goes. It might be that BM needs some changes as well. |
It has been running for 1 day without encountering this issue... Do I understand correctly that we somehow lose connection to DBus? If so, I wonder if we can recover from this? |
Got that again after roughly a day of observation:
Slightly different message though. |
Ok, I was able to replicate the issue in the end; it should be solved upon migration to dbus-java-3.0.0. However, I got a different issue - what are the error policies upon failing connections? Generaly, following can occur when connect() is invoked:
|
Sorry @xrucka , just noticed this. I'll think aand reply in the morning. |
Great, thanks :-) |
Hi @xrucka, error handling is something that potentially needs to be still adjusted/tweaked. Generally speaking, BM does not differentiate errors. It is either good or bad. If any error happens, it tries to recover governors state by resetting governors, and initialising them again. I wanted to keep it this simple. This approach works ok, I did not have any issues so far. However, there is a special error/exception that still needs to be addressed in a special way. This is when something happens that requires resetting not only corresponding governor but also its parent object (e.g. if device can't connect because adapter is acting up and needs to be reset). Have a look here, I've made a skeleton for this but never implemented this: https://github.com/sputnikdev/bluetooth-manager/blob/d239d59a5368d05d06f59dc62faeb3e355716f23/src/main/java/org/sputnikdev/bluetooth/manager/impl/AbstractBluetoothObjectGovernor.java#L189 Having said that, if DBus transport somehow can identify this errors, it should probably throw the Fatal exception. But honestly speaking, I faced that kind of issues only once or two, in other words I could not reliable reproduce this sort of errors hence it is not implemented. Good finding regarding error #2. In theory it should not happen as BM insures that only 1 thread is handling a governor (hence transport object) when managing connection. However, we still can add some special login in there, e.g. if this type of error occurs, then skip connection attempt. Having said that, this might not be a good idea, because we never know what is the reason of that error, maybe a corresponding device is in fail state and needs to be reset? I'd leave it as simple as possible honestly speaking. If you still want to implement something special, then we should think how we could recover from that state anyway, e.g. calculating number of this error and if it exceeds a limit of connection attempts it resets governor, something like that... But as I say I'd make it simple... To sum up, BM does not care what errors happen on transport level, it tries to recover from any errors by resetting corresponding governors. If any specific logic needs to be implemented to handle a specific error, this logic should have an exit criteria (e.g. when to stop waiting and initiate reset). I hope I answered your questions, let me know. |
Just thinking a bit more about #2 type of error. This reminded me that connection operation is not synchronous in both bluggiga and tinyb transports. Hence... if update rate in BM is set to something low, we could get a situation when a governor could try to issue repetitive connection attempts (if a device is to slow to establish connection). Yeah, this might need some tweaking. |
Hi, mostly you did. Based upon your answer, I'll go for Btw, I'm thinking about adding a full reset option for adapters to the transport; invoking hciconfig hciX reset upon power off. It seems this might help with some strange bugs. |
This is one is a major. Once it has happened, you have to restart OH to get rid of it.
This happens after I enable "connection control" for a device (particularly to Xiaomi mi flora).
It tries to connect to that device, I can see that it also tries to do authentication (via setting a pin code) and then Bluez reports infamous
Software caused connection abort
error and then it starts failing with this:I'll do some more experiments to get some more details.
The text was updated successfully, but these errors were encountered: