We are announcing the release of version 1.08 of our STSW-BNRG-Mesh, , which will be followed by X-CUBE-BLEMESH1 1.3 and FP-SNS-BLEMESH1 1.2. The first solution is a software package enabling the creation of Bluetooth mesh applications while the second is an expansion for STM32Cube. Finally, the last one is a Function Pack with pre-compiled binaries for our lighting demo. Among the new features available, developers can now use two application keys to enhance their network’s security while also benefiting from out-of-band (OOB) provisioning to authenticate new devices. This announcement is also highly symbolic because ST is celebrating the first anniversary of our Bluetooth mesh 1.0 Profile Certifications that we officially received in August 2018 for our tools that make Mesh easy, scalable and user-friendly.
A critical advantage of our software solutions that’s easy to overlook is their ability to assist developers that target battery-powered applications thanks to the support of two fundamental nodes: low-power and friend. To reduce its power consumption, a node must turn off its RF, and low-power nodes do just that by decreasing their duty cycle to only enable their radio receiver when necessary. To ensure that these nodes don’t miss important information, a friend node will store messages and only transmit them to the low-power node once it wakes up and sends a request. For instance, sensors spend most of their time in sleep mode and receive very little data. They are thus great low-power nodes that need to wake up to send data before pinging their friends to get relevant messages, if any, and go back to sleep right away.
Bluetooth Mesh with Application Keys, and Out-of-Band Provisioning
The ability to use multiple application keys is a tremendous security advantage. The provisioner, meaning the system (PC, tablet, phone, etc.) that will allow a device to become a node within the network, shares the network and application keys. Having multiple application keys signifies that various programs don’t have to share the same cryptographic element. Ergo, only the relevant nodes get to decrypt a particular data from a node. For instance, a smart thermostat or doorbell won’t get to decrypt messages from the lighting application. As a result, hackers that compromise one of them (e.g., the doorbell) will still not be able to control nodes that rely on other applications keys (e.g., door lock).
When authenticating a new node, a provisioner may use one of three out-of-bound methods: Output OOB, Input OOB, or Static OOB. With Output OOB, the device requesting access to the network will output a random number. For instance, light can flash three times, or a smart node will display several digits. The user can then enter the number in the app running on the provisioner to authenticate the new device. Inversely, with Input OOB, the provisioner generates a random number, and the user enters it on the unprovisioned device. Finally, in Static OOB, both the provisioner and unprovisioned devices create a random number, and the user must enter them in the other system. Provisioning is a necessary but complex process. By using our source code, developers can quickly implement the OOB method that makes the most sense for their application.
Vendor Models and so Much More
Our Bluetooth software solutions further differentiate themselves from the competition by offering an unexpectedly large number of models. Bluetooth mesh uses the Model Layer to standardize the exchange of messages and the implementation of features between devices. Bluetooth SIG defines mandatory models (Foundation Models) to ensure proper communication between the server and its clients. We also offer standard application models (Lighting, Sensors, or General Template for time and scene, among others) since last year to help developers create solutions faster, regardless of the type of program they are writing. Whether engineers are looking to develop a system detecting ambient light or an on-off-dim switch, we have models that will assist them and take away the inherent complexities of such programs. And by continuing to offer an increasing number of models, we also guarantee the flexibility of our solutions.
The new ST Bluetooth mesh solutions that we released also provides developer-friendly Vendor Models, making our software even more interesting for teams looking to implement some specific functionalities. Bluetooth mesh stacks available to developers traditionally limit themselves to a few vendor model message examples. We take a completely different approach by offering a vast number of message examples because we want companies that use our Bluetooth SoCs to spend more time on their features, mobile applications, or graphical user interfaces, and less time struggling with fundamental Bluetooth mesh implementations.
Bluetooth Mesh with BlueNRG-Tile
Developers will notice that the new demos in our software solutions now support our BlueNRG-Tile module (STEVAL-BCN002V1B) and we will soon also support BlueNRG-Plug (STEVAL-BLUEPLUG1). The former was recently at the center of our smart shelf demonstration and one of the focuses of the STM32 Summit in China. The latter is a development platform for home automation and IoT applications that includes a Bluetooth 4.2 SoC, and an STPM32 for smart energy metering applications. The new Bluetooth mesh software solutions offer drivers and pre-compiled binaries, enabling programmers to quickly take advantage of the module’s sensors or other components to shorten the prototyping phase of their design. The software also brings low-power and friendship nodes to the BlueNRG-Tile to facilitate the creation of a mesh network of battery-powered systems.
Our mobile application ST BLE Sensor for iOS and Android is now compatible with the new board and features, and we provide their source files to help significantly with the implementation of complex functionalities on both of these mobile operating systems.