Cannot connect to Sphero BB-8

[rfestag]

I'm trying to use ruby-ble to connect to a Sphero BB8. Using this library, I'm able to detect the device, but connections always fail. I keep getting

device = BLE::Device.new('hci0', 'D4:3B:0A:0C:3E:51')
device.connect

Which gives me:

BLE::NotReady: BLE::NotReady; caused by 4 sender=:1.123 -> dest= serial=529 reply_serial= path=/org/bluez/hci0/dev_D4_3B_0A_0C_3E_51; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged error_name= from /home/ryan/.rvm/gems/ruby-2.3.0/gems/ble-0.1.0/lib/ble/device.rb:374:inrescue in refresh!'
`

In the past, I was able to use gatttool to connect. In order to do so, I had to set my address type to random, and security level to medium. I can't seem to replicate that anymore (I reinstalled my OS recently, and for whatever reason gatttool isn't behaving the same).

Any ideas on what I would need to change in order to connect to this device? Am I doing something wrong, or is there no way to connect via DBus with additional parameters?

[rfestag]

After a bit more digging, it looks like the issue is that @o_dev[I_DEVICE] does not have a 'GattServices' property. Does something need to be done in order to make that available?

[rfestag]

After some more troubleshooting, I am able to connect with gatttool (but still not via ruby-ble). I had to disable the pnat service, in /etc/bluetooth/main.conf, but I also still need to set the address type to random. It doesn't look like any parameters can be passed to DBus, so I'm not sure how to tell it to use the random address type.

[rfestag]

So, it turns out that the DBus API is pretty different between 5.36 and 5.43 (which is what I'm running). I have been able to update ruby-ble to support it, but it won't work on systems running an older BLUEZ.

[sdalu]

Thank you for investigating the issue. It would be nice if you could submit a pull request with your fixes. What distro/version are you running?

[rfestag]

I will, I just wasn't sure about submitting a breaking pull request until I had a little more time to look into a way of auto-detecting which one to use. I am running Manjaro (Arch derivative), so it is a rolling distribution. I suspect most other distributions are on 5.3x, so I'm not sure how much sense it makes to push this change unless there is some way to dynamically select the appropriate API, or two branches are maintained with different major versions.

I also ended up needing to make another breaking change, and I'm not sure how best to work around that. Basically, I need to use the notifications system (which uses ruby-dbus's on_signal) to get the results of commands I send to the BB-8. The problem with that is the notifications callbacks only execute the next time I tell dbus to do something (read/write another characteristic). The way around that was to use the DBus::Main event loop in a separate thread, but it seems to eventually hang on an IO.select because I am mixing and matching blocking and non-blocking calls. I suspect it is actually an upstream bug in ruby-dbus, but the best way I found around it was to change all calls to ReadValue and WriteValue to be in the non-blocking form (ie, by passing a block). My plan is to have Characteristic.read and Characteristic.write return promises, so that this can work more generically.

I'm definitely open to other ideas if you have them.

[kamaradclimber]

@rfestag , by any chance, would you still have your changes to support to the dbus api?

[rfestag]

I just submitted the pull request with my changes. I haven't touched it in quite a while, so your mileage may vary.