Rethinking Bluetooth for IoT | SimpleBLE's Kevin Dewald.

Table of Contents

1. Introduction to SimpleBLE
2. The Mobile-Centric Nature of Bluetooth
3. Desktop as a First-Class Bluetooth Platform
4. The Challenges of Bluetooth Dongles and Firmware
5. The Economics of Commercial Open Source
6. The Future of Desktop Bluetooth and AI
7. What the IoT Ecosystem Gets Wrong

---

Introduction to SimpleBLE

Host (Ryan Chacon): Welcome Kevin to the IoT ForAll podcast. Thanks for being here this week.

Kevin: Thank you for inviting me Ryan.

Host (Ryan Chacon): It's great to have you. I'm looking forward to this conversation. Before we kick things off, it'd be great to have you introduce yourself to our audience.

Kevin: So my name is Kevin. As a background, I'm an electronics engineer, but I've sort of migrated more and more throughout my career into the the software domain. I'm the creator of SimpleBLE, which is part of the California open source company (CAOS). It's a sort of bigger ecosystem. SimpleBLE started pretty much as a personal frustration around um working with Bluetooth. So as an electronics engineer, many things you work on will have Bluetooth because it's a great cap capability from a technology perspective. It's awesome. It's everywhere. You can connect to anything. But the what I noticed was that the software stack to use Bluetooth especially when you're when it comes to desktop devices was lacking. like most of the project that existed would either be incomplete, have problems or would just be abandoned and it was it was a problem I was running into consistently until one day I don't know like five years ago at this point I decided you know what I'm doing it myself and it started more as a sort of again thing that I built for myself because it was part of my work but as it kept evolving more like it was adopting more and more people because I've put a lot of effort into like into the design to to make it really easy to use, very straightforward. it's the same API across all languages. So there's a lot of work that has to go into unifying the API. Okay, what's the actual behavior that the user wants? Present that and then deal with the complications internally. So a lot of work has gone into it and the library has grown significantly since since we started and year and a half ago we decided to turn it into commercial product as a way of boosting its growth even even further.

The Mobile-Centric Nature of Bluetooth

Host (Ryan Chacon): So I do have a question I'm curious about because you know when we think of Bluetooth at least a lot of people that listen to this think of Bluetooth the first thing is more mobile centric in IoT. Um, so can you talk about like is is was that kind of a deliberate choice or just kind of how how things kind of drifted and changed maybe since we've really started to incorporate Bluetooth in a lot of what we we interact with seed do and so forth.

Kevin: Basically, when all of this started, all platforms had some degree of Bluetooth support, but it became very important for mobile devices because that's usually how we interact with any sort of Bluetooth device around us. Everything is controlled via the phone. So both Apple and Google were very motivated on building excellent Bluetooth stacks for their mobile devices. In the case of Apple at least they those sorts of that same API propagated to Mac OS because it's the same core Bluetooth u source base. However, especially for Linux and Windows, that was not the case. And even though they had all these capabilities, accessing them is a became a challenging issue. And in my case, an electronics engineer focused mostly on embedded development. You if you need to test every single thing on your phone, it becomes very slow. So having a way of running a test directly on your computer became very important. and to test like how things integrate like it the the computer is a lot more powerful and a lot more flexible for building things compared to your phone. So that's how the need was started and that's how everything evolved. So the first operating system we supported was Linux then we added Windows went on to Mac OS and at some point it's like wait why don't we just add all of them and that's how it evolved.

Desktop as a First-Class Bluetooth Platform

Host (Ryan Chacon): Yeah. You mentioned power you mentioned flexibility. So what what's really missing by not treating the desktop as a first class kind of Bluetooth platform?

Kevin: When it comes to desktop environments, you have you're not using your phone all the time. Most of us work in front of a computer with a phone next to us. Our main interaction with everything is actually the computer. So by bringing like using that as a starting point, it actually opens like it makes things more in a way more accessible because you you can have them right there with you. Your computer can also do more like more it's more again more powerful. You can you can do more things with it versus just a phone because you have to go ahead pick it up and then do something else. So you're very limited in that regard. And capability wise desktops can do everything and more than phones. So it's it's a very important niche that we're now slowly I see I'm starting to see trends moving in that direction where the expectation of using Bluetooth everywhere is sort of coming to to fruition.

Host (Ryan Chacon): That's awesome. So I guess from your experience, what have you seen hindered or or initially was, you know, slowing down the adoption of using desktop Bluetooth or is there something that was broken that people just couldn't get over in order to really understand and kind of go this route that we're talking about here? Because it sounds like the benefits are super easy and clear, but you know, obviously the the road to get here. Like what what was that like? Is there anything that's worth noting?

Kevin: That's also part of the challenge of this is that using Bluetooth on desktop is a lot harder compared to doing that kind of development on mobile devices. to give a few examples. So in the case of Android and Apple, both iOS and Mac OS, like the API, even though it has its quirks, it's relatively straightforward and it's well supported within their ecosystem, especially. But in the case of Linux and Windows, there's no like default language. You have system tools that you interact with. In the case of Linux, that would be BlueZ. In the case of Windows, you access it through WinRT. But you need to code WinRT. you need to handle how like the language, how all the parts connect. So it's not it's by no means trivial. Most of the like heavy lifting for the development actually was on on Linux because we have three different layers to expose this functionality nicer. The first one is just to be able to talk with the operating system then to bring BlueZ to us and then wrap BlueZ into something that's easy to use and has the same API as everybody else. That's the biggest lift. It's not something you you can do right away. You need to understand a lot of of how the internals work and it takes time. It takes effort and most platforms that you see that are crossplatform conveniently ignore this part when it comes to Bluetooth because especially doing it on Linux and Windows, it's really hard.

The Challenges of Bluetooth Dongles and Firmware

Host (Ryan Chacon): Another topic I know we had a note here to talk about is around I guess existing dongles and being more of an issue than one would think. like you talk you had a note here about a client experience very tense client experience that had delays right talk us through that talk us kind of you know around what what's potentially out there that's causing issues maybe why you've started to do your own Bluetooth work and kind of you know what led to that and just help educate us there

Kevin: the thing to understand is that the Bluetooth protocol is extremely complicated it's if you if you look at the the actual manuals it's thousands of pages of definitions of actions that need to happen within a certain interval. So it's it's not an easy thing for implementers to properly implement and the way that the standard that everybody is sort of settled on which is the HCI standard. It's great for a few things but it also there's a lot of room for either errors or or just issues in general. And the the moment you start you go a little bit off script when it comes to developing like applications that don't use what everybody does. So that you're using a code path that is less tested. You start to run into issues. And a very interesting case we had over a year ago was with a company trying to implement a peripheral mode. their device didn't have a Bluetooth capability with them. So they were using a USB dongle. And turns out that depending on how you set that up, most dongles will fail. They're going to crash. They're going to either make mistakes during parent pairing and not correctly hold the pairing information. All sorts of unexpected issues that are mostly firmware related because some part of the implementation there went wrong. But because the standard is so big, it's very hard for manufacturers to to test absolutely everything. So there's a sort of layer that you're losing there. And on top of that, the operating systems themselves impose limitations such as Windows for example only letting you have one active Bluetooth dongle at any given time. And sort of like hearing these things and dealing with these same issues because we'd have clients ask us, hey, I want to use Windows with two dongles and our answer would be like, you can't. So BR like it's sort of like it's a sort of need we're we're noticing and we decided to go down a different path where the communication layer between SimpleBLE and a dongle we design in a way mimicking what the userfacing API has so that um we basically we move a lot of this complexity towards the dongle itself. So we know what use cases we need to support and we're only focused on those. And that way we make sure that if for whatever like whatever a client needs, we can support it. And it's also it's much easier to test versus this whole sort of blank field of oh you have you have to be able to respond to like 150 different messages going back and forth.

The Economics of Commercial Open Source

Host (Ryan Chacon): I wanted to ask you another question just about open source in general. So can you talk about the like economics of open source? Maybe how it affects availability of different tools. what you all have done to help solve this and what has it really allowed you to do because I think there's this expectation especially when you just mentioned open source that that it needs to be free right like different infrastructure libraries things so I'm I'm sure that causes problems as well so take us through kind of that whole the economics as well as you know the problems it faces and then what you've been able to do to kind of help educate get around that and obviously you know go forward

Kevin: we all love open source as a sort of way of sharing information knowledge and our work it's great because it from an economics perspective, the adoption barriers are very low. Unfortunately, it's not as straightforward and the the sort of the main factor affecting this is the reality that we all have bills to pay. You get projects that especially in their initial phases have a lot of momentum. There's a lot of stuff happening, but at some point reality is going to set in and the developer has to somehow get their income from somewhere. And even though we all love to just again put our workout for free or whatever, we need um that doesn't pay the bills. So um what ends up happening is priorities start to shift and the the work that used to be now the the primary focus of attention has to go back to work or family or something else entirely. And if something even catastrophic or at least really big happens, all the all the work around that open source tool just sort of fades away. It's that's how most abandonware happens. Like there's a sort of initial push but unless you move out to a sustainable business model either by be going commercial like we did or finding either enough sponsors or a foundation to look after you or a company to look after you. it's basically you have a sort of death sentence for that project looming over you every single time and it's not the right thing for all but we're at least personally I've become a very strong advocate for commercial open source let's keep the transparency around open source in the sense that oh I can go in I can test it I can see how it works I can understand if it's useful for my needs or not but then I reward the creator with um basically cap giving them a small percentage of the value I capture as a customer. We did this as an experiment again a year and a half ago and to our surprise it worked because turns out having a solution like SimpleBLE was really useful for companies and the moment we sort of asked them to pitch in they were more than happy to because hey we're we work closer now we they can share us their needs we can better service them we can guide features towards what they need. So there's now a dialogue happening and at the same time you know what to prioritize because you know if it generates value or not and the benefit of that has been that we've been able to invest a ridiculous amount of hours improving SimpleBLE since we went commercial precisely for this reason. We've been able to to complete Android support peripheral support adding new languages. We have Rust. We have three more in the works. It's we've we've added I don't know I I did the math the other day like more than 2,000 hours of developer time to the to the project where especially small users or hobbyists can now enjoy for free thanks to this partnership with the companies that decide to pay for it. That's the that's the sort of magic of this and we're noticing that this sort of approach can happen for pretty much any kind of really valuable piece of software.

Host (Ryan Chacon): Yeah, I think it's interesting just to think about what really changes when tooling has a real business model behind it while at the same time when we're talking about open source you all have a great example of being able to make SimpleBLE sustainable without killing openness. So I think you know thinking through that is just a really fascinating story on how you approached it and I'm sure many people who have thought about it in the past were worried that the second you start to attach payment to something will that push people away will they be less interested will it not have the same value but people seems like people are willing to pay for things they find valuable um as long as those right characteristics of you know being very transparent in what you're doing how you're doing it is there, they're willing to pay because they're getting value out of it on their side as well.

The Future of Desktop Bluetooth and AI

Host (Ryan Chacon): I wanted to go back to the desktop Bluetooth conversation for a second. Um, if if desktop Bluetooth is properly supported, what new opportunities do you think that opens up for the industry as a whole? Like we talked about the benefits and you know, the things that are valuable there, but if you were just think about this, you know, where this is now, maybe where it can go in a few years, if if it kind of all worked out the way you would like it to, what are, you know, what's what are the benefits there?

Kevin: One of the things I'm most excited about is moving things from the phone towards a centralized location like my computer. So, for example, I'm a big fan of IoT and I'm going to move to a new place soon and we're going to I want to basically sensorize my entire home and controlling all those things from from the phone is complicated. But if I have a central location where all the information gathers and then maybe my phone connects to my computer, I can suddenly like it becomes a lot more flexible. I can even give instructions to my computer to hey adjust the thermostat or tell me I don't know turn things on off what whatever you need. It sort of grows in that direction and you can then and especially now this with the most latest trend with AI this also goes in that direction because if suddenly you have good desktop support for that AI agents can leverage your own personal AI agent can control all these things and smartly decide oh do this do that it's a lot of things that are sort of opportunities that open up but only if you're running things on the platforms that actually support all the underlying tools that you want to use And especially now both with AI, but as well with peripheral support that we're adding and all these other things, it becomes possible. The your computer is it's just another device you connect to. It's just incredibly powerful. It can access the internet. It can do it can do a lot more complicated things that no other like I mean no smartwatch or I don't know temperature sensor can do, but now you can.

What the IoT Ecosystem Gets Wrong

Host (Ryan Chacon): Last question I have for you before I let you go here is around just it kind of relates well to just your general interest and I guess obsession with IoT that you know our audience loves to hear about. if if you look at the ecosystem, what what do you think the ecosystem right now gets wrong about building serious IoT products today? Like what what are the like besides the stuff we've already talked about related to BLE like just generally thinking about IoT, the products you interact with, the products people listening to this probably interact with. What are companies getting wrong that should be more of a focus than it probably is?

Kevin: The thing that annoys me is that every vendor tries to force their own app and software stack or cloud stack upon you. Especially nowadays, if you're an IoT enthusiast, and given that the barriers for coding your own things have lowered significantly, self-hosting becomes a much more interesting solution. But the way everything is built is still trying to force you towards someone's ecosystem. Either a certain vendor or Google Home or Alexa or Apple iOS Kit or whatever it's called. It's all the same. Everybody they're trying to force you on their same thing and they're not I don't think they're building with a user in mind. And what the the shift that I would like to see is to let people build what they need, let others learn from that. I think there's a sort of like big the same way it happens with other technologies where like people build their own things and share them and sort of a community and great ideas come out of that. I haven't seen that same thing fully happen when it comes to IoT. I know there's Coleman system there's some tools around that but there's no sort of commitment toward from these from these vendors of hey here's my device this is a protocol this is how you interact with it go nuts

Host (Ryan Chacon): yeah no that makes total sense I think it's been interesting just to see how the IoT industry has evolved so I think your point is very valid and I'm curious to see if if people or I guess if companies understand that as well and start to kind of build in that direction

Kevin: There was an interesting story a long time ago about a Linksys router where they had to open-source the firmware due to some open-source IP issues. It turned out to be one of the most sold models precisely because everyone could hack around with them. So I I think there's an opportunity there that a lot of these companies are missing because they think that open source means giving away control and that's not the case. You can structure this in a way where you can, but by giving others the freedom to do what they what they think is best will basically blow your mind because you're they the creativity of of people when they want to solve a problem is beyond limits.

Host (Ryan Chacon): That's a great way to end. Um Kevin, thank you so much for the time. this is great great conversation. Appreciate you educating us on some very interesting and important topics. Love what you all have going on. For our audience who wants to learn more, connect in any way, follow up, what's the best way they can do that?

Kevin: I think the best way is just to visit our website is simpleble.org. Everything you need you can find there and you can reach out to us whenever you need.

Host (Ryan Chacon): Well, Kevin, thank you so much for the time. Appreciate it. We look forward getting this out to our audience.

Kevin: Thank you.