I do embedded development, and BLE is just another stack. It's actually very well documented in the official Bluetooth Core Specification. It's thousands of pages long, but it's a big stack with lots of layers and protocol.

Just like any networking stack, there's a decent learning curve, but its not like it requires any fundamental tool foreign to firmware development. On the other hand, your average arduino tinkerer has been handed so much abstraction of low level details, learning BLE, at least on the device side, would be a tall task.

Specific implementations of stacks and sdks will obviously vary in quality and documentation. On the device side, Nordic does a very good job with tools and documentation for their parts. There are several companies that make modules with nordic parts and provide libraries and example projects.

I've also used noble, which is a node js module that allows you discover and connect to devices. On a Mac, all you need is Xcode.

Thank you. You make some good points. I've kept myself from touching BLE too much in favor of wifi and zigbee. I'll give noble a try on my mac. :)

You should seek out a primer of the general architecture. Its definitely a departure from IP networking. Here's a brief overview:

Devices advertise their presence when they are not connected. The usual connection is one device to one client, although multiple simultaneous connections are possible. Clients can look at advertisement data to see what services the device offers. Once a client connects to a device, it can interrogate the device further.

A BLE device makes multiple pieces of data available individually, called characteristics. So if your device had a heartrate sensor and a battery, your bluetooth profile would likely have a heart rate characteristic and a battery level characteristic. A client that connects to this device could discover these characteristics, and read/write them, as well as set up notifications, so the device can asynchronously send the client data.

An IP based system treats its connection as a single pipe, whereas in a BLE system, on top of a single physical connection, you effectively plumb a separate pipe to each piece of information you make available to the client. Each characteristic has its own read and write callbacks, and each characteristic can be individually customized with things like read write notify permissions, data type, description, etc.

I just started a little BLE work to get into things. I've found it really odd there's a definitive list[1] of services that can be advertised. Why is it not just a specified key/value to advertise?

Like "Health Thermometer" is crazy specific.

[1]: https://developer.bluetooth.org/gatt/services/Pages/Services...

You can make custom services and characteristics.

The nice thing about standard services is that 3rd party apps that know how to interact with those services can work out of the box.

Nope. Mi Bands (fitness trackers by Xiaomi), for example, use some weird scheme until you can access the heartbeat sensor.

DRM and obfuscation is even present in these devices -...-

Well, there's certainly no requirement to adhere to in terms of access. Apple's HomeKit runs on BLE but has its own layers of pairing and encryption.

I'll agree though that you are more likely to find compatibility on a development board level than in a commercial product.

Thanks, really helpful info.

You're welcome. It's always a treat when HN wades into the embedded world, and I can be the expert for a second.

Go to www.bluez.org and try to figure out how to use BLE. Like how to scan for BLE devices, connect to one and read its GATT, interact with characteristics, etc. Bonus points try to figure out how to do it using their APIs and not command line tools. Good luck! (here's a hint, I hope you like dbus)

Zeus! You are right. I'm going to try and get in touch with them to see if we could collaborate and improve documentation.