Live data from Hacker News

Show HN: OpenBLE, Swagger for Bluetooth

demo.openble.org

1–10 of 45 posts

Show HN: OpenBLE, Swagger for Bluetooth

#1
OpenBLE is an API specification language and client generator for Bluetooth services built on the generic attribute (GATT) profile.

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.

Show HN: OpenBLE, Swagger for Bluetooth
demo.openble.org

Re: Show HN: OpenBLE, Swagger for Bluetooth

#2
> Even though shunned by Apple and Mozilla, Web Bluetooth enjoys wide support and just works.

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.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#3

> Even though shunned by Apple and Mozilla, Web Bluetooth enjoys wide support and just works. 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…

What justification is there for not implementing this across all browsers?

Re: Show HN: OpenBLE, Swagger for Bluetooth

#4
I use Nordic's app nRF Connect for this - last I used it it was fantastic. Nice to have alternative options though.

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.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#7
post #4

I use Nordic's app nRF Connect for this - last I used it it was fantastic. Nice to have alternative options though. 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.

>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.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#8
post #4

I use Nordic's app nRF Connect for this - last I used it it was fantastic. Nice to have alternative options though. 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.

nrfconnect exposes the services, but if they arent registered with the bluetooth SIG then you won't have much more detail than the ids of characteristics and services and their data types. You won't know what the purpose of each service and characteristic is.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#9
post #5

> Features > 1. Define your GATT services in YAML. Uh, nope, thank you.

I mean, defining the service in some sort of universal definition format is clearly the way to go. Working with BLE across platforms is incredibly terse and error-prone. The UUIDs should only be in one file -- human eyes aren't going to notice a single-character mistake in those things.

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.

Post reply on HN