-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add Linux Support using D-Bus / bluez #64
Comments
I'm working on getting this library to work on a raspberry pi using bluez/dbus. There's still some issues, the device is disconnected in most cases during value notification setup, discovery is also a bit fiddly. But once it gets connected and setup, it actually works. I'm still trying to figure out the cause of the issues. Also, my current implementation uses https://github.com/hashtagchris/DotNet-BlueZ as a whole, but I found some issues that i'm trying to work around/fix. Since that package is a small and possibly incomplete abstraction layer on top of DBus anway, my goal is to implement this directly on top of Dbus (using Tmds.DBus) myself, after I get this working properly. I just wanted to let you know i'm putting some effort into this currently and i'll create a PR once I have something that actually works all the time. |
Awesome. Create a draft pull request at any time. When you need any help, just ask here! One more question: how you learned about this library? I have many new contributors this week and I am curious what drove you here! 🙂 |
I created a draft PR to track changes: #106 I found this library kind of by accident 🙂 I want to do some automation of my lego trains ever since I converted from 12v era stuff to powered up sometime last year or so. Recently I got inspired and wanted to connect my trains to some model train automation software (rocrail most likely). My end goal is to connect sensors to detect trains and servo's to control points to a raspberry pi which then communicate with rocrail or something else and i can control everything from within there. Now for the trains themselves, i figured i could use the same raspberry pi with bluetooth to control the trains. There's no real reason for me to need to use a raspberry & linux for this, since i could just use my windows laptop instead, but that's only half the fun right 🤷♂️ 🙂 |
That's cool. I would love some contributions in the train area. I am not so sure if this hub-device model is the right thing for trains. Maybe thinking different (like a huge array of devices (trains, rail switches...) with automatically managed BLE and Protocol layer below). Check #4 . |
I basically restarted implementing this, using DBus directly. It is much more reliable and I have a proper sense of what's going on now. I can get a working connection to a technic hub and run the gyro example succesfully every time.
Regarding that last point, could you shed some light on exactly what the |
I am also not perfectly happy with the API. Discover, find, ... To many interfaces, like you said. I am open for a breaking change here and a new API surface. My requirements would be:
|
DiscoverAsync basically awaits the first of its type and otherwise invokes Discover with callback. And what WinRT does... Only WinRT knows :) The Bluetooth interface is not too advanced there, it is after all over a generic driver over all kind of BT devices. Will have a look. |
So, I investigated further and figured out that there were deadlocks when awaiting a few specific methods related to connecting and watching property changes for a device.
To get stuff working, I changed the discovery handler passed to Discover() to a Func returning a Task so it can be awaited, see: https://github.com/vuurbeving/powered-up/blob/cca3e7f81e91f84b2e7b3d846ca7250627831dd8/src/SharpBrick.PoweredUp/Bluetooth/IPoweredUpBluetoothAdapter.cs#L9 The code in my fork now is a complete mess, but... it works (for a single specific test scenario that is). Exact same behavior every time also. I haven't tested the windows bluetooth stack with a async discovery handler yet, maybe that breaks 🙄. Now to clean this up and get a proper bluez support for this library, I think maybe we should define a proper api surface first, like you mentioned. Due to the very async nature of bluez, dbus and well, bluetooth itself, I'd like the approach to be 100% async. Also we should take care to apply ConfigureAwait properly where needed. Especially when working with a UI.
|
Regards Threading I hate threading. To death ;). I investigated the threading behavior of WinRT by googling and documentation reading. NOTHING. The callback from the WinRT notification handler ... is that a task/thread for my pleasure (humble opinion: WinRT case) or part of the event loop (I guess dbus case) down to the driver.
Regards the devices
|
I'll create a PR for the just the few specific changes needed for bluez/dbus to ever work/not deadlock, this can then be tested with WinRT stack, hopefully it simply works. The api surface About ConfigureAwait, I guess it's best to create a seperate issue to track this, as currently I do not specifically need it right now. I do already scan for devices with the lego specific service uuid as a filter, that works very well 👍. Basically the issue comes down to this: |
I merged #116. Was working like charm. |
sharpbrick#64 non-breaking
sharpbrick#64 non-breaking
sharpbrick#64 non-breaking
sharpbrick#64 non-breaking
sharpbrick#64 non-breaking
sharpbrick#64 non-breaking
Hi, I created programs to control 42100, 42099, 42109 and to test 42114 with bricknil (janvrany fork) for Linux (Gentoo). |
Methodology: https://stackoverflow.com/questions/53933345/utilizing-bluetooth-le-on-raspberry-pi-using-net-core
The text was updated successfully, but these errors were encountered: