Sensors and Controllers: the Bluetooth Mesh Difference

Halfway through the architecture design of Bluetooth mesh (wow that was 6 years ago!) we dived deeply into the application layer. Lighting control was a clear target, so we had had already specified "lightbulbs" and "switches". Connected lightbulb was a symbol of IOT and smartness for many years and even today, in a layman engineer's view it represents what is today knows as NLCs (Network Lighting Controls). But diving a bit deeper under the surface it became clear a the lightbulb would not be a breakthrough.

We felt sensors were needed, as almost any "smart" scenario included a sensor - typically an occupancy sensor, triggering light in presence of humans. But was it really smart? In very simple environments - such as windowless rooms - maybe. But was it sufficient for the new standard to make serious inroads into the market? Definitely not.

At that time there was another standard - Z-Wave - which had very complete application layer definition. In Z-Wave indeed has sensors very well defined. And there are many Z-Wave products combining multiple sensors in one, with ambient light and occupancy being the most popular duo. They can be configured to turn the lights only when presence was detected AND it was dark. But the Z-Wave architecture has a very serious flaw: the decision what to turn on and when, is made in the sensor, which simply sends a light-on or light-off command to the light bulb. This is probably good for simple home scenarios, but the drawback is: you cannot use such sensor for anything else. Like turn on lights in an adjacent space to lower dim level. Or use this sensor for another subsystem like security or access control. Because it is sending a "light-on" message.

The Bluetooth mesh solution has been to invert the roles, bu putting the control function in the lightbulb. Let sensors be just that - sensors. By designing them to send out (or publish) sensory information: "occupancy detected" or "light level is 85 lux" (or both). And let the lights (or any other devices interested in this information) subscribe to it and act upon it, independently.

Luminaires a room may be configured to maintain light level of 300 lux when occupants are present. So they subscribe to in-room ambient light and occupancy sensors. And if the sensor reports under-lit condition and presence, the lights will dim up. Luminaires in the corridor may similarly subscribe to corridor sensors. But they can also subscribe to the occupancy sensors in the adjacent rooms, so the corridor is lit whenever people are in any of the rooms, regardless of the room light level.

As you see the configuration flexibility is achieved by placing the decision - making logic is in every luminaire. We say this logic is distributed among the participating luminaires, bringing other significant benefits to this design: no point of failure and reduced network traffic. And the three together: flexibility, no point of failure and scalability (through vastly reduced network traffic) are the winning combination Bluetooth mesh offers today.

To see how it works in practice, I encourage you to watch this video by Sylvania on Bluetooth.com and read the Bluetooth mesh NLCs whitepaper.