I wonder how all the cheap-ass Android device makers get BT(LE) running... or wait, often they don't and the user is screwed...
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.
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.
Like "Health Thermometer" is crazy specific.
[1]: https://developer.bluetooth.org/gatt/services/Pages/Services...
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.
DRM and obfuscation is even present in these devices -...-
I'll agree though that you are more likely to find compatibility on a development board level than in a commercial product.
The documentation is a bit on the weak side, but it's small, easy to use, and low-power (~1.3mA @ 3V connected, ~0.2mA advertising)!
I recently used one to make a BLE smartwatch that uses my iPhone as a network connection (http://workhardanywhere.com/smartwhatch)
It is based on a single-chip wireless microcontroller that has both support for both BLE and IEEE 802.15.4 (6lowpan/ZigBee). It is supported by the Contiki OS (http://www.contiki-os.org/). The learning curve is probably quite a bit steeper than that of an Ardiuno, but the board and the chip can be readily included in commercial products. There are reference designs with design files, BOMs, schematics available from TI.
Since it has both BLE and 6lowpan support, you can do some pretty nice things with it, such as providing both quick discovery via smartphones and secure remote access: http://www.thingsquare.com/blog/articles/proximity-control/
http://www.cypress.com/documentation/development-kitsboards/...
FCC Certified, how neat! It's got a tiny CPLD on it with programmable analog routing logic as well (DACs, ADCs, op amps).
I was trying to use one of these to drive my Nixie Tube Clock and using the CPLD to do the multiplexing in hardware but I accidentally touched 12V on one of the pins and it blew up :(