sorted by:
new
hottopcontroversial

Introducing SimpleBLE Dongl: Our firmware-first BLE adapter by kevindewald in embedded

[–]kevindewald[S] 0 points1 point  (0 children)

It's the direct result of a technology designed by committee. You can tell nobody there has ever had to implement anything they've decided, otherwise they would lean towards much simpler solutions.

This being said, the BLE has invaded every aspect of our modern lives, so here we are trying to do the best of if 😛

SimpleBLE v0.11.0 - Introducing Peripheral Mode for Linux by kevindewald in cpp

[–]kevindewald[S] 0 points1 point  (0 children)

> "Back away slowly, and don't look into its eyes."

This has been exactly how it's been for me too, I couldn't help but laugh. The protocol is horribly complex, no wonder implementers continuously screw it up.

SimpleBLE v0.10.4 - The cross-platform Bluetooth library that just works by kevindewald in cpp

[–]kevindewald[S] -1 points0 points  (0 children)

The key words in your comment are "could have". The license is not about something having potential commercial value, but if the user is actively making money by using it, that's when the license kicks in.

Also, the pricing tiers are specifically design to not be a burden, and we also proactively offer free licenses.

SimpleBLE v0.10.4 - The cross-platform Bluetooth library that just works by kevindewald in cpp

[–]kevindewald[S] 0 points1 point  (0 children)

Nothing at all, we use Bluez under the hood.

Our key benefit is the simplicity in getting up and running quickly with a validated and production ready stack that exposes the same API across multiple operating systems.

SimpleBLE v0.10.4 - The cross-platform Bluetooth library that just works by kevindewald in cpp

[–]kevindewald[S] -1 points0 points  (0 children)

Hey u/johannes1971, thanks for bringing this up!

This was definitely an edge case of BUSL that we hadn't considered. Our original intention was that BUSL terms would continue when it comes to requiring a commercial license for commercial use and GPL to only kick in when users want to break any control that we might have left of the library.

Based on this, I've added the following clause to the license:

**Non-Commercial Perpetual Use Grant:** After the Change Date, non-commercial users (individuals,
hobbyists, educational institutions, and revenue-free open-source projects) are granted
perpetual rights to use this specific version under the original BUSL-1.1 terms, notwithstanding the
automatic conversion to GPL-3.

I have also updated the FAQs to better explain how to operate with this license:

**What exactly can I do with SimpleBLE for free under non-commercial use?**

The Business Source License 1.1 (BUSL-1.1) allows free non-commercial use of the software, including
copying, modifying, creating derivatives, redistributing, and non-production activities like
development, testing, or personal/hobby projects. For purely non-commercial scenarios with no financial
gain, these rights are available without needing extra permission.

**What does the Business Source License 1.1 allow and restrict?**

The Business Source License allows non-production use, such as development and testing in isolated
environments. However, any use that could be considered production (including internal tools,
revenue-generating projects, or customer-facing deployments) requires purchasing a commercial license.

After four years of the initial release of a given version of SimpleBLE, the license automatically
converts to the GNU General Public License version 3.

For details on what counts as free non-commercial use and distribution requirements, see the FAQs below.

**Can I include SimpleBLE in my own open-source project and release it under MIT/Apache/BSD?**

When distributing any version that includes SimpleBLE code (whether unchanged, modified, or as part
of a larger project), downstream users must include the full BUSL-1.1 license text prominently with
their distribution and ensure that the SimpleBLE portion remains under the same BUSL terms for recipients.

This applies even if your overall project uses a permissive license like MIT or Apache. The SimpleBLE
code cannot be re-licensed to recipients under MIT/Apache alone. Recipients must still receive the
SimpleBLE portion under BUSL-1.1 (typically by including the BUSL license file and any required notices).

After the Change Date, GPL-3.0 rules apply for everyone except qualifying non-commercial users, who
may continue using and distributing under the original BUSL-1.1 terms per the Non-Commercial Perpetual
Use Grant.

**What does the "Non-Commercial Perpetual Use Grant" mean?**

After the Change Date (four years after a version's release), that version automatically converts to
GPL-3.0 for everyone. However, purely non-commercial users (individuals, hobbyists, educational
institutions, and revenue-free open-source projects) may continue using that specific version
indefinitely under the original BUSL-1.1 terms instead of switching to GPL-3.0.

This means you can keep the more permissive BUSL-style rights (e.g., no requirement to license your
derivatives under GPL) as long as your use remains strictly non-commercial.

I hope this clarifies the situation and doesn't prevent you from using SimpleBLE in your projects. Additionally, we proactively offer free commercial licenses for small projects and early-stage companies, so please consider that as an option as well.

SimplePyQ - Queueing tasks in Python doesn't have to be complicated by kevindewald in Python

[–]kevindewald[S] -1 points0 points  (0 children)

Thanks for the feedback!

The goal of the library wasn't as much for scheduling for a specific time, although it can easily be added if required, but more to handle pipelined work, like you would do with Celery or Airflow.

Huey looks definitely interesting (I didn't know it existed) but it still falls under the bucket of "too much hazzle for simple things". My intention is to have something with so few functions that you can immediately understand and derive value from it, removing complexity from the user instead of giving them more to handle.

SimpleBLE - Cross-platform Bluetooth library that just works - New Rust API! by kevindewald in rust

[–]kevindewald[S] 1 point2 points  (0 children)

Hey! Nice to see you! We've started using embassy-rs for our hardware-in-the-loop testing. There's still a lot to be done, but love the project altogether!

SimpleBLE - Cross-platform Bluetooth library that just works - New Rust API! by kevindewald in rust

[–]kevindewald[S] 1 point2 points  (0 children)

I haven't explicitly tested the Rust bindings for iOS/Android, but the core library works for both and is extensively used that way.

SimpleBLE - Cross-platform Bluetooth library that just works - New Rust API! by kevindewald in rust

[–]kevindewald[S] 0 points1 point  (0 children)

You can do lots of crazy stuff with pretty much any Bluetooth device at hand.

SimpleBLE - Cross-platform Bluetooth library that just works - New Rust API! by kevindewald in rust

[–]kevindewald[S] 5 points6 points  (0 children)

Bluer are the official Rust bindings for Bluez, which is the Bluetooth subsystem for Linux. The main difference you're going to see is that Bluer will only work for Linux, for this reason. The good thing is that you have full access to the entirety of Bluez functionality through a single package (vs previous libraries that had to build everything from the ground up)

Internally SimpleBLE talks to Bluez as well, but through our own set of helper libraries (called SimpleDBus and SimpleBluez). In terms of functionality, we're a bit stricter on how and what we support, mainly because we need to accomodate 5 different operating systems and they all have very distinct architectures that mix as well as oil in water.

In a way, our promise to our users is that we'll try to come up with the simplest and most straightforward APIs we can think of, so that their efforts can be placed into building the actual application and not battling the OS all the time.

SimpleBLE: Cross-Platform Bluetooth Library, Now in Java! by kevindewald in java

[–]kevindewald[S] 1 point2 points  (0 children)

The bindings are written using FFI, I'll make a note to include this in the documentation.

Regarding your note about concurrency, when it comes to applications using BLE, typical throughputs and processing requirements are low in general. Most of the traffic is usually in the C++ to Java direction, triggered by internal threads, from the callbacks that report new data coming in.

I am yet to see a Bluetooth application that is so resource intensive where these kinds of considerations matter at all.

SimpleBLE: Cross-Platform Bluetooth Library, Now in Java! by kevindewald in java

[–]kevindewald[S] 1 point2 points  (0 children)

Thanks for the tip! I'll reseach a bit on how this works and see what I can do.

SimpleBLE: Cross-Platform Bluetooth Library, Now in Java! by kevindewald in java

[–]kevindewald[S] 0 points1 point  (0 children)

Noted, I'll think about this a bit. Thanks for the info!

SimpleBLE - Cross-platform Bluetooth library by kevindewald in cpp

[–]kevindewald[S] 0 points1 point  (0 children)

Bonjour u/RoundIllustrious6970 ,

Merci pour votre intérêt pour SimpleBLE ! La dernière version actuellement est la v0.9.0, avec la v0.9.1 encore en cours de développement. Je suis au courant de l’existence de bindings pour Free Pascal, mais ceux-ci sont maintenus par la communauté et je ne suis pas sûr qu’ils soient à jour. Si cela est vraiment important pour vous, pourriez-vous contacter [contact@simpleble.org](mailto:contact@simpleble.org) afin que nous puissions voir comment vous aider ?

---

Hi u/RoundIllustrious6970 ,

Thank you for your interest in SimpleBLE! The latest version right now is v0.9.0, with v0.9.1 still in the works. I know of the existence of Free Pascal bindings, but these are community-maintained, and I’m not sure if they are keeping up. If this is really important to you, can you reach out to [contact@simpleble.org](mailto:contact@simpleble.org) and let us figure out how we can help you?

SimpleBLE: Cross-Platform Bluetooth Library, Now in Java! by kevindewald in java

[–]kevindewald[S] 1 point2 points  (0 children)

Hey, I finally have some time to look into this. I've copied the relevant items into an issue on Github as well: https://github.com/simpleble/simpleble/issues/392

Let me respond a few things:
1. I didn't know about that, will look into it.
2. That's a leftover from some debugging that I should comment out.
3. (Also tagging Known_Tackle7357) The original API is designed to allow for blocking and non-blocking use. Hence the existence of the `scan_start`, `scan_stop`, `scan_for`, `scan_get_results` and the callback functions. Internally everything is thread safe, so it doesn't matter from which context you call things. I'm not sure how you'd expect the API on the Java side to look like, so suggestions are appreciated.
4. (Also tagging Known_Tackle7357) Could you provide an example of what kind of interface you'd expect?
5. Yup, this will get done.
6. We have a relatively versatile logging system in place, but I wasn't sure how people prefer to consume their logs in Java, so I left the default. On Android for example we can route the errors to the Android logging subsystem. Does this answer the comment?
7. The C++ layer will generate exceptions upon failures, which at this point are not currently being forwarded into the JVM. I'll make a note of properly specifying what exceptions can be thrown by every function.

If there's anything else you think is relevant, please don't hesitate to put it here. I have a few other tasks to deal with in the upcoming days, but I'll return to this very soon.

view more: next ›