How to use notifications (`start_notify`) about blurz HOT 12 OPEN

Hi,
Sorry for the late response!
I don't think the start_notify/start_notify will be useful. It should be reworked like the DiscoverySession.
The problem is that we currently drop the session after a call, which is usually fine, but when you try to use something session related, like doing a discovery or in you case using notification, the connection should be kept.
We are planning to do this, but I can't promise that it will be in the near future. Hopefully before the end of this year.

from blurz.

@dati91 thanks for the response.

Do you think that this feature would be difficult to implement? If it isn't too much hassle I'd like to contribute.

from blurz.

@stankec My main concern is that somehow we need to receive the messages (we can do this with a loop, but i hope there are some callback functions), then store them, and somehow propagate them through an API (maybe register a callback, or a poll mechanism).

from blurz.

I went through some other libraries that implement this functionality (ble [Python] and ruby-ble [Ruby]) and there doesn't seem to be a consensus on how to do this.

The Python library pipes notification to the characteristic's value attribute and encourages the use of a loop to read them (I could be wrong here since my Python knowledge is not the best). While the Ruby library uses lambdas attached to DBus signal callbacks.

From snooping around dbus-rs I see that signals are supported (at least it says so in the readme) and there is an example of how to use them. I think it's possible to implement something similar in interface and functionality to the Ruby library using closures in Rust.

To be a bit more specific. We could add a function like on_notify which receives a closure as an argument and spawns a detached thread which does something similar to the example from DBus but in a loop.

@dati91 You opinion?

from blurz.

Sounds promising!
If you need any help with it, just let me know.

from blurz.

I have started working on this, and have successfully read from a notify using something like this in bluetooth_characteristic.rs:

pub fn acquire_notify<F>(&self, func: F) -> Result<()>
    where F: FnOnce(u16, OwnedFd)
{
    let c = Connection::get_private(BusType::System)?;
    let mut m = Message::new_method_call(
        SERVICE_NAME,
        &self.object_path,
        GATT_CHARACTERISTIC_INTERFACE,
        "AcquireNotify"
    )?;
    let reply = c.send_with_reply_and_block(m, 1000)?;
    let (opt_fd, opt_mtu) = reply.get2::<OwnedFd, u16>();
    func(opt_mtu.unwrap(), opt_fd.unwrap());
    Ok(())
}

paired with something like this:

// UGLY PROTOTYPE
println!("{:?}", charac.acquire_notify(
    |mtu, ofd| {
        println!("{:?}", mtu);
        println!("{:?}", ofd);

        use std::fs::File;

        let mut buf = [0u8; 512];

        // TODO, don't leak fd
        let fd = ofd.into_fd();

        for i in 0..5 {
            thread::sleep(Duration::from_millis(1500));
            if let Ok(num_read) = read(&fd, &mut buf[..]) {
                let hbs = buf.iter()
                    .take(num_read)
                    .map(|b| format!("{:02X}", b))
                    .collect::<Vec<_>>();

                println!("PING: {:?}", hbs);
            } else {
                println!(":(");
            }
        }


    }
));

fn read(fd: &RawFd, buf: &mut [u8]) -> Result<usize> {
    use libc::c_void;

    let ret = unsafe {
        libc::read(fd.clone(),
                   buf.as_mut_ptr() as *mut c_void,
                   buf.len())
    };

    if ret < 0 {
        println!("{:?}", ret);
        bail!("Fail")
    } else {
        Ok(ret as usize)
    }
}

which gives me this:

Pairing...
"00000001-c001-de30-cabb-785feabcd123"
        "0000c01d-c001-de30-cabb-785feabcd123"
23
OwnedFd { fd: 5 }
PING: ["0E", "00", "00", "00"]
PING: ["0F", "00", "00", "00"]
PING: ["10", "00", "00", "00"]
PING: ["11", "00", "00", "00"]
PING: ["12", "00", "00", "00"]
Ok(())

I'm working on some other stuff first, and right now this still requires periodic polling of the file descriptor, but it's a good proof of concept :)

Hopefully I can clean this up to a better interface, and contribute it back sooner than later.

from blurz.

Also as a note, this requires BlueZ 5.46 or above, and at least on 5.46, this requires you to set the --experimental flag for bluetoothd.

from blurz.

@jamesmunns Have you had time to look further into this issue? Do you know another workaround or can you make a PR?

from blurz.

Hey @denysvitali, I didn't end up going further with this project, so the comment I left before is basically as far as I got.

from blurz.

in #21 you could use start_notify, map incoming dbus messages to BluetoothEvent and use BluetoothEvent::Value. (`examples/test5.rs)

from blurz.

Has there been any more work on this? My use case also relies on BLE notifications.

from blurz.

see #21, GATT notifications work

from blurz.