Internet of Things is not a new concept, but it is quickly becoming mainstream nowadays. And a “thing” is, by definition, a “connected thing”.
In these days we’re increasingly interested in “Low Power” technologies. Why? Not only because we’re green and we don’t want to waste our resources and pollute the earth, but also because we want to be able to use devices able to communicate using a small battery, lasting for years.
Bluetooth Low Energy (BLE) is not a really a new technology but is increasingly used as a short range, low power communication way.
In this story, I want to highlight the main features of BLE and to show how it can be easily used for our goals.
I will use as an example an Intel Edison board, but in the near future (well, as always depends on my free time) I’ll add details for Raspberry PI 3. I’m working on a prototype that use Eclipse Kura on RPI 3 as an example of IoT gateway.
Bluetooth was born, now almost twenty years ago, as a wireless communication technology, short-range: a technology to implement at low cost a Wireless Personal Area Network (WPAN).
Historically, the first and principal use of Bluetooth was voice and audio streaming, for example from a mobile phone or Smartphone, to a headset or a wireless loudspeaker. Today, all the cars provide connectivity from a smartphone or other devices to the embedded set of speakers using Bluetooth.
In addition, many runner, like me, use Bluetooth wireless headset to listen to music stored on their Smartphone, when they run.
The advent of Bluetooth Low-Energy (BLE) or Bluetooth Smart has broadened the range of possible solutions and enabled realization of low-power wireless connectivity between devices with limited resources (e.g. powered by a tiny “cell-coin “ battery), fitted with sensors (heart rate, temperature) and a central device that receives, processes and displays data.
The central device often is a Smartphone or, better today, what we like to call a Smart-watch.
In fact, today the BLE technology is the simplest wireless communication technology short-range that can be used to communicate with a smartphone (iOS, Android, what else?).
BLE is a communication protocol that rightfully can be considered very important in the context of the Internet of Things. For this reason, it is increasingly supported, for example in boards used by Makers: we find an out-of-the-box support for Intel Edison and even in the latest version of the Raspberry PI, version 3.
Main Use Cases for BLE
BLE is a low-power wireless communication technology (low power).
It has a very low energy consumption compared to the WI-FI. In fact it is possible to fabricate devices (see the so-called iBeacons) that by using a “coin-cell battery” broadcast for years without having to change the battery.
It has a limited communication range (tens of meters) and the amount of data to be transmitted per second can not be high (say of the order of tens of bytes per second).
There are many scenarios in which you can think of adopting BLE.
Think of the case of use of the “Connected Car”: we want to collect a lot of data, produced by the various car components in real-time, allowing you to analyze the behavior, for example to predict the need for maintenance (Predictive Maintenance).
In this case an effective topology provides a “ field gateway”, a central device that connects via 4G network (for example) with an IoT Cloud Service, and a series of “resource constrained” devices acquiring data from sensors and communicating with the gateway via BLE. The gateway performs local analysis of the data, aggregates the individual readings (what we call Edge Processing) and sends messages to the Cloud Service.
Another use case is in Healthcare applications. You may think to measure vital signs such as heart rate (Heart Rate, HR) using a device with a sensor that transmits via BLE to a central monitoring system.
An iBeacon is a small low-power device, battery powered (e.g. the tiny CR2032 battery), which transmits periodically, every fraction of a second, a message that allows a detector (eg: an App on iPhone) to identify its presence and read the distance.
The specification of iBeacons was defined by Apple. An iBeacon transmits using BLE, using the advertising messages, with a custom usage of the optional data area advertising packet.
Each message contains a UUID, a Major and a Minor number, which allow you to uniquely distinguish the Beacon.
They are typically used as proximity indicators: to indicate that the detector is close to an iBeacon, and somehow identify the environment where it is located (example: I enter into a shop with Major number 2 (Paris) and I’m in the section identified by Minor number 40).
Another example: we can assign a distinct beacon to each member of our family and place a detector at the entrance of the House, near the door. Thus, as soon as a memberof the family enters in the House, the Beacon assigned is detected and person recognized.
The main benefit from Beacons, in my view, comes from their simplicity. The power consumption is extremely low (really in the order of micro-amperes) and then the battery can last some years, without having to be replaced.
A very well-made guide that explains how the technology of iBeacon works and how it can be used to add “Indoor Location Awareness” to applications is available on the Apple Developer website:
It is interesting that even an Apple iPhone can behave as an iBeacon. Activating an application on your iPhone, you can enable its recognition as soon as you get into an environment that “detects” the iBeacon.
BLE from the point of view of standardization is a “lightweight subset” of the Bluetooth Core 4.0 specification.
For the specifications, see, for example, the site:
According to the specification, the main characteristics of BLE are:
- Ultra-low peak, average and idle mode power consumption
- Ability to run for years usingstandard coin-cell batteries
- low cost
- Multi-vendor interoperability
- Enhanced range
A device using BLE protocol makes its presence known through an “advertising” mechanism.
As for the advertising and the connection to a central device, roles and actions are defined by the GAP (Generic Access Profile).
The GAP briefly defines how a BLE device can communicate broadcast to the rest of the world its presence, the services it offers and how you can establish a connection between the BLE device and a central device.
GAP defines two main roles:
- Peripheral: a low-power device, resource constrained, which transmits data via BLE;
- A Device Central, which collects data, for example from multiple devices.
The peripheral initially transmits in broadcast mode, by periodically sending an “advertising packet” that provides information on the device itself and can also carry data, if you want to transmit in broadcast mode, “connection-less.”
The central device typically performs a scan of devices, capturing the “advertising packets”, in order to identify devices with which to connect.
When the device is identified, the central device can establish a connection, thus enabling a bi-directional communication between the peripheral and the central device itself.
The specification defines a few simple rules:
- A device can be connected only to a single central device;
- Generally, after establishing a connection, the device stops to send advertising packets.
The GAP defines an additional mechanism: a central device can send a BLE Scan Request to a device, to which the device responds with a Scan Response: it is a mechanism that allows an additional sending of descriptive information on the peripheral, required from Device Central.
After having implemented the connection, the communication is ruled by GATT mechanisms (Generic Attribute Profile).
GATT defines how should be the communication between two devices where a connection has been made. It defines how a client can identify the services offered by a server (discovery), how information offered can be read and write, and how receive notifications about state’s changes.
GATT defines two roles:
- Client Device; the device requesting the connection and performing Read and Write Request;
- Server Device: the device that responds to requests.
The communication between the two devices is governed by GATT Transactions’ mechanism.
The exchange of data takes place using logical data structures. It is based on the concepts of:
Typically, a device defines (or supports) one or more profiles. A profile includes N services and each service provides M characteristics.
An example of profile
The specification defines, to ensure the maximum possible interoperability between devices and device, a whole set of profiles.
An example of a profile is the Heart Rate Profile (HRP) that is the recommended profile, for example, for the heart rate monitors that use BLE. As indicated in the specification, this profile “enables a Collector Device to connect and interact with Cardio sensors for use in fitness applications.”
The profile defines two services, as shown in the picture below:
- Heart Rate Service;
- Device Information Service.
BLE and NodeJS
After the theory, for those interested in implementation details, some code.
As previously mentioned, in general (see GAP) BLE will provide for two distinct roles: in other words, our device can be a peripheral device or a central device.
NodeJS provides a modular extension mechanism, based on modules. There is a very broad set of modules, many OpenSource, which can be downloaded from the Internet and installed.
Modules supporting BLE are all “wrapper” of C libraries provided by the underlying hardware platform.
Two Open Source modules can be usefully employed to carry out experiments based on BLE:
- BLENO, which can be used to implement a Device; https://github.com/sandeepmistry/bleno
- NOBLE, to implement a central device; https://github.com/sandeepmistry/noble
Both modules can be installed using NPM.
As we will see below, the code that uses the two modules can be tested on a device like the Intel Edison board and a MacBook.
An experiment: the environment.
To get a better feeling of BLE and how to set up communication with devices based on this protocol we will use the following working environment:
- Intel Edison board, connected to the sensors, which will act as peripheral device;
- A PC that will act as a central device; in my case I used a MacBook Pro (I’m a proud Mac user for years now).
On a Mac you can easily install tools that allow you to connect with BLE devices and to analyze and diagnose what is happening during the communication.
In our case, I have used the Developer Tools (Bluetooth Explorer, etc) that are integrated into Xcode.
These tools must be pre-installed by downloading from the Apple website.
In the illustration below, the Bluetooth Explorer is shown, after he has discovered my Intel Edison with BLE activated and initiated a connection (the hostname is thunder10 card and exposes a service of UUID AAA1):
Bluetooth and Intel Edison
In our experiments we will use as a Peripheral Device an Intel Edison board. It natively supports the BLE protocol and requires no additional hardware. Bluetooth management is implemented at hardware level by the chipset Broadcom BCM43340.
A very complete and updated guide on these subjects has been published by Intel and is available at the following URL:
For further details regarding the use of Bluetooth BLE with Edison the reading of the guide is definitely to be recommended.
Intel Edison is a powerful card and probably its best use is in the role of central device, but being small size and with low-power consumption it can be also effectively used in the role of peripheral device.
The stack of Bluetooth protocol in Edison is implemented using BlueZ, the official “protocol stack” of Linux 1 . BlueZ is an OpenSource project.
For more details on BlueZ you can visit their site:
Intel in the article linked above lists all the commands available at O.S. level, to enable/disable BT and perform most common Bluetooth operations (e.g. scan of visible devices).
The main command-line utility is bluetoothctl.
For example, the following sequence of commands shows how you can make “discoverable” by a Smartphone an Intel Edison board, as seen from the output of the console (obtained through an SSH connection via WIFI to Edison board):
In the second part of the log you see the interaction with a Smartphone (iPhone Louis) who made the discovery of the device and attempted to connect.
Sample code to implement a BLE device
The HW is made by an Intel Edison board, with an Arduino Breakout Board kit. The board is equipped with a Grove Shield to which a Grove Temperature Sensor is connected.
To manage in a simple manner sensors on the Intel Edison you can use the Intel UPM library and UPM_GROVE module (JSUPM_GROVE).
The choice made here, that is not the only one possible, is to define the service at the time of the start of advertising.
The code defines a service, identified by the UUID AAA1. Within this service you define a single characteristic, with UUID CCC 1 (well, you can choose better identifier, for sure!) . The feature has a value that can only be read and it is associated with the onReadRequest callback, which is invoked by the BLENO stack when it receives the READ request. The onReadRequest invokes the code to read the current value of temperature, which is returned by BLE.
In the code we only manage the events (1 to 5) listed above. In general, it should also provide for other events, such as: WRITE Request, Notify. But in our case the value exposed by the service (room temperature) can only be read and we assume that you do not want to provide notification of value changes, from the device to the Device Central.
Each event is run by a suitable callback, as usual in NodeJS programming model.
Using the NOBLE module for the implementation of a BLE Central Device
Another NodeJS module that can be used to implement in NodeJS the other side of the connection (the Central Device) is Noble.
I have personally tested Noble on my MacBook, but it also runs on Intel Edison (which can then act as Device Central, as aggregator node).
If you install Noble, in the directory
node_modules / examples
there are three useful sample programs that show how to use the module API:
- enter_exit.js, who simply writes a line each time a visible BLE device connects or disconnects;
- advertisement_discovery.js, performing a scan of the visible devices and displays the list of advertised services.
- Finally peripheral_explorer, to be launched with the <device address> parameter, which shows the services and features exposed by the specified device address.
Finally, a last module that can be used to implement a Beacon is: Node-bleacon
Some final thoughts
However, in tests carried out by me not always everything worked. In some cases I had to reboot the Edison board to resume the tests correctly, which shows that the two modules and the underlying stack arenot, yet, totally free of bugs.
Moreover, the daily experience with the Bluetooth protocol, by users, showed us situations where, for example, the coupling between the two devices is not successful end and attempts must be repeated.
As I told before, actually I’m working with the development of an IoT Gateway, based on Eclipse Kura, for demo purposes. One of the use cases is “Presence Detection”, based on BLE. That is why I re-discovered some old notes regarding BLE, refreshed them and decide to publish.
Suggestions for further reading
A collection of short but very clear and useful pages on BLE is available on the Adafruit website:
To learn more about using the iBeacon technology a very useful site is Apple Developers’ site: