Bluetooth development is a mess. Too many datasheets, too little documentation and SDK fragmentation across platforms. I built this tool to improve documentation, version control and development speed for BLE programs.
Even though shunned by Apple and Mozilla, Web Bluetooth enjoys wide support and just works. It makes sense to build the frontend for OpenBLE using web Bluetooth. No SDK hell, no installations, wide support albeit experimental. I could ship the spec, SDK, code generator and testing framework in pure JavaScript.
That’s an interesting way to say Chrome Only feature but you shouldn’t care because Mozilla ran Firefox into 3%/ground and Safari doesn’t matter.
IDK… to the point of the project… I guess that’s cool. But once you have defined and tested your GATTs, it hasn’t been my experience to come back to it a ton of times.
I just wrote unit and systems tests along with a BLE speedtest that also confirms protocol so I could run it where it matters - on different phones.
It was my experience to care more about distance, speed, interval, and MTU on actual hardware than protocol confirmation to a PC.
> It was my experience to care more about distance, speed, interval, and MTU on actual hardware than protocol confirmation to a PC.
That's exactly my concern, coupled with a (perceived) small pool of Bluetooth developers. Do you think there's a market for a Postman style commercial cloud product for team collaboration?
A lot of hardware devices pretty much implicitly trust the device on the other side of the data connection, because historically anyone able to run software on a machine also has physical access to the device. This resulted in devices accepting firmware updates over Bluetooth, for example, because how else would you update the firmware?
And now with protocols like Web Bluetooth, the only thing standing between between the average user and a random website completely owning their physical hardware devices is a single "I agree" permission popup.
We would never have had PCs with the attitude seen in this thread.
I agree WebBluetooth is easily the sanest way to access BLE devices. The iOS API is not too bad either but then you have to deal with Apple. The Android API is terrible, and the Android Bluetooth stack is unreliable and buggy.
It is truly the worst. Up until API level 33 (Android 13 from 2022!!!), all characteristic read/writes were memory unsafe. Now readCharacteristic is async for memory safety, but you're still expected to send a value synchronously with BluetoothGattServer#sendResponse when onCharacteristicWrite gets hit, so sending a value that's derived from any characteristic values is impossible before you fall out of scope. And notifying/indicating is just never reliable -- it just fails to work consistently device to device. And the high level API for the CCCD often doesn't work and requires you to set the 0x2902 descriptor manually.
CoreBluetooth handles BLE so elegantly and Android just botches it. Sad.
> 1. Define your GATT services in YAML.
Uh, nope, thank you.
A far-less-error prone and faster approach I've taken recently is just having two busses -- one read/write characteristic for inbound messages to the peripheral, and one r/w/notifying characteristic for inbound messages to the central. Then all messages just get defined as protocol buffers. Adding new characteristics for new functionality is a massive pain. Easier to just add new protos and use the same pipe.
OpenAPI is useful because it not only generates a frontend for testing an API, it also can be used to generate the skeleton of an API's implementation. Can I generate Zephyr macros using this tool? Can I generate Android or iOS code? A complete tool should be able to generate firmware, Android, and iOS code for both a GATT server and client.
As a professional firmware engineer working in IoT, I'd advise against hanging your hat on Web Bluetooth. Bluetooth is already rife with security problems, and exposing direct control of it to a browser is asking for zero-day nightmares. This is beside the antipattern involved in asking web apps to directly control a peripheral's communication interface.
Which is why (quoting OP) Mozilla has 'shunned' it. Apple too perhaps (though the reasoning isn't open afaik, and Safari omits more or adopts more slowly in general than can be ascribed to security/privacy concerns).
As of today it can generate an Arduino GATT server; I'm working to support more platforms, Zephyr, iOS etc.
A lot of hardware has very minimal protection against attacks, because the general idea is that anyone able to run software on a machine could also just trivially physically attack the device itself. The result is that you can often update device firmware over Bluetooth or USB.
Allowing random websites to suddenly have unlimited access to poorly-secured devices is a terrible idea. Google's opinion seems to be that a permission popup is enough, but you get basically identical popups for a website wanting to send you notifications, get your current location, or completely own your physical hardware.
Last I saw, that's not really true - you get asked for BT access in general, but then you have to directly select the device you want the site to connect to once scanning happens (site can specify basic filters to limit devices shown, but little else). Sites can't see what devices are available until you actively select the device from the browser UI, and can't just show you a 'click to give full access to BT with everything'.
Put the door behind a permission the user has to explicitly activate, and if you are still concerned, add more friction to the process, or in this case, argue for a better permission system, but please do not argue for "infinite friction" (a.k.a prohibiting, banning, censoring)
If you still think we should not do this because users won't care and will accept any permission anyway, then you are arguing against the freedom of users to have control of their devices and run whatever algorithm they want on them
I've also dabbled with bleno and noble for emulating and/or communicating with peripheral and central devices, respectively. (https://www.npmjs.com/package/@abandonware/bleno)
It's technically straightforward on linux, or using a BBC microbit (there is example code in the Nordic SDK).
It is very useful, I use it often. I can't think what security exploits there could be given that the user has to select the device and until they do the API can't access any devices or even scan for them.
The previous commenter seems to have found a use :)
From https://news.ycombinator.com/item?id=37522059 :
> https://github.com/DJm00n/ControllersInfo: HID profiles for Xbox 360, Xbox One, PS4, PS5, Stadia, and Switch
> "HID over GATT Profile (HOGP) 1.0" https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?d...
It's like magic when using an LLM to convert the spec to YML to runnable apps.
There absolutely needs to be a general consensus around defining a GATT profile. The challenge is that each company has their own way of using GATT and documenting how it works.
