Questions about this project

[wpd]

I wish GitHub offered a "Discussions" feature in addition to the "Issues" feature. Oh well...
I'm curious to learn the purpose of this project. I saw a reference to it here as an example of how to use bluster. So that's what I'm using it for... to teach myself some bluster, some bluetooth, some BLE, and some Rust.

I'm curious why you have so many characteristic_*.rs files with nearly identical code. I'm following your model for my test case, but I kinda feel like there should be a way to refactor all of that common code. Maybe Rust's safety features prevent that. I'll learn for myself shortly.

I'm curious why each of the create_blah() functions make a vector of the string, and then clone it, and then clone it again, and then toss it around to a future to do something fancy.

I'm sure this will all make more sense to me once I learn more Rust, and learn more about futures in Rust specifically.

Thanks for any hints or tips you can provide.

--wpd

[dfrankland]

Hey, there! Thanks for asking. I added the Discussions section and converted this issue into a discussion.

As for characteristic_*.rs files, I was converting this project from JS and each characteristic was a class, so I carried over the layout. bluster and bleboard are both super alpha prototypes in Rust. I wouldn't expect much to work. This problem of having lots of duplicate code would go away with some proper traits written and implemented on structs for each characteristic.

A lot of things are cloning values because I didn't care to refactor the code to be written efficiently, I was just trying to get things to work. Writing async code before async...await required using closures without Pin which cause a lot of things to need to be Sync + Send or just cloned. This would probably go away by updating to use async...await.

If you are just learning Rust, welcome! I am not sure I would recommend this as code to learn from though considering it is quite outdated now and definitely was not my greatest work 😅 Of course feel free to challenge yourself with it though.

[wpd]

Thanks... I kinda figured it was alpha code... but being new to the language, I didn't want to just come on out and ask :-)

I am still curious to learn more about your "bleboard" project... especially as it relates very closely to my project at hand... implement BLE on a Linux board that has bluez. In the end, I'm going to have to write my code in C/C++ only because, in addition to learning Rust, learning about Bluetooth, learning about BLE, and learning about D-Bus, I would need to figure out cross compilation for Rust (seems to be done), telling the Rust cross compilation environment about the libraries upon which bleboard/bluster depend, getting cross compiled versions of those libraries, and adding in the other 3rd party stuff my project requires.

In the mean time, I'm making opportunities to read and try out as much Rust code as I can. I was able to adapt your bleboard code to advertise the services for my project during just a couple of hours of (somewhat distracted) hacking last night and see it work. I'm still trying to get to that point with the C/C++ approach I've been trying for the past week.

[dfrankland]

Wow, how neat! I totally get where you are coming from. I eventually got exhausted with this project and haven't returned to it for awhile because of how overwhelming it is. Thanks for checking it out. I hope that you are successful in your endeavors. Feel free to ask anything you'd like as you learn more.

[BareTuna]

I came here for the same reason as OP, I'm just two years late to the party haha. I hope it's okay to ask some questions here too.

I'm pretty new to Rust and Bluetooth, but I wanted to challenge myself a little. My hope is to make a game controller to control the nintendo switch. I'm using repo called nxbt for a working app, but referencing an outdated, but better documented repo called joycontrol. we'll see how it goes lol

Anyway, my question is if/how the peripheral sends data to the central device once it's connected? Looking briefly looking at the code the peripheral seems to advertise itself ... then does nothing afterward? With what (little) i know about BLE, it should send data back/forth via GATT. But what's leaving me a little confused is that this repo does seem to have GATT related stuff 😅. Maybe im missing something or misunderstanding?

Any help is appreciated 🙂

[BareTuna]

ha, i should've done my homework. Having extra context about how BLE works now makes things much easier to digest. I think I get it now.

I checked back to the tests/peripheral.rs in Bluster, since I think the async code looks nicer. So here's how I see it now:

There's 2 main parts to using Bluster: building the service, and building the event handlers for the service. A service is made up of characteristics, and characteristics can contain metadata called descriptors. Each characteristic and descriptor will want its own event handler. A tx/rx pair is created to link each characteristic and descriptor to their corresponding event handlers. Now you need some way to connect your peripheral to the central device. The advertising async block advertises for a period of time, hoping a connection is made, then exits the async block. The rest happens in the event handlers. The real "entry point" I was missing was the join!() near the bottom, which run the event handlers.

I will also say there were a couple issues with my setup in trying to get the demo to run, but it is to no fault of Bluster.

1. My central device could see the advertising packets, but failed to connect. I got it to work with my peripheral (Linux BlueZ) by changing the systemd bluetooth.service's ExecStart= to include the flags --compat --noplugin=*.
2. After I connected from my central device, my central device would disconnect after a short period of time. I had ran some demos and toyed with things a month prior, so in my central device I clicked Forget Device, reconnected, then it worked okay.