Earlier this year, we made the decision to retire SensorMesh™, a product that was built on top of the standard Bluetooth mesh framework. At first glance, Bluetooth mesh appeared to be a promising technology—serverless, open, adaptable and with an extended range compared to standard Bluetooth LE. However, as we got into its implementation and use, we found that the limitations outweighed the benefits.
Our SensorMesh™ was designed to be a versatile solution for various applications. It provided a new Bluetooth Mesh model that allowed the participation of any Bluetooth beacons or other devices without them requiring firmware updates. The system also allowed for payload filtering and time-based control to manage throughput. It was capable of transmitting data from a variety of sensors, such as location, movement, button press, temperature, humidity, air pressure, light level, open/closed status, and proximity, over the mesh network:
One of the first issues we encountered was the complicated provisioning and setup process. Unlike turnkey solutions, Bluetooth mesh required a provisioner, usually an app on a smartphone, to store encryption keys. This made the initial setup far from straightforward and ongoing management difficult.
Another significant limitation was the very low throughput, which was in the order of a few thousand bits (yes bits!) per second. For most applications, especially those requiring IoT data transmission, this was not sufficient. In many cases, using gateways proved to be a more effective solution.
The Bluetooth SIG’s chosen flooding architecture, while excellent for low latency, consumed too much power for battery-operated devices. As a result, we had to resort to installing firmware on USB dongle -style devices, which were permanently powered. This was inconvenient for many applications we saw from potential clients where mesh networks would have been ideal, such as in mines, hospitals, factories, farms and even battlefields where existing networks are already congested or non-existent.
We also found that Bluetooth GATT clients at the edge of the mesh, responsible for relaying the mesh data somewhere else, easily became congested despite the low throughput. Our workaround involved using USB dongle with mesh firmware and a COM port rather than GATT.
Bluetooth mesh offered no way to trade latency for less power consumption. Its throughput was too limited for most uses, a problem inherent to the technology. Since its announcement in 2017, Bluetooth mesh hasn’t seen many implementations outside the lighting industry. We believe this is because it was driven, designed and optimised for lighting scenarios, which require low latency and permanent power but can tolerate low throughput. Sadly, enhancements recently provided by Mesh 1.1, such as directed forwarding, device firmware update, remote provisioning and subnet bridging have come about mainly to solve problems found in Network Lighting Control (NLC).
In the end, we retired SensorMesh™ because it didn’t have a good product-market fit. The underlying characteristics of Bluetooth mesh were too limiting to make it a useful solution for the applications our customers envisioned. While Bluetooth mesh may have its niche uses, we believe its limitations make it currently unsuitable for broader applications.
