Bluetooth Mesh - Smart Lights

Lighting Control Models (Sections 6.2 and 6.5 of the Mesh Model Specification) are the cream of the crop in Bluetooth mesh. Let me explain why I think so.

Most of the time when I discuss smart lights, people tend to think they are lights you can control with a phone app or lights that can be controlled by another device, such as a switch or a dimming slider on the other end of a room. To be honest there is almost no "smart" in such scenarios. There is wireless connectivity involved, but the light itself, apart from being connected and responding to incoming messages, is not smart at all. It is a dumb slave server reacting humbly to whatever a client may want it to do.

This is how many connected (and called smart) lighting systems are designed. There are client devices, usually in a form of a controller box, that have the smarts built in. The controllers have sensors connected and they run their own clocks and determine what they wat the lights to do. There is software running in these controllers that executes a lighting control strategy: occupancy, vacancy, daylight harvesting and more. If the controller is gone, the lights don't have a clue what to do. Traditionally controllers are also the single points of failure. As an example, to experience this, in a Philips Hue system, try to shut down the bridge: neither your phone nor any Tap switch is able to control the lights anymore.

As I pointed above, the controllers are essentially software blocks, with some inputs and outputs. The reason of building them as separate devices is historical. They needed more processing power and were expensive. Fast forward to 2017 and you quickly realize a typical Bluetooth LE SoC, present in every mesh lamp, is powerful enough to run the controller software.

So what if we multiply the controllers? Creating multiple copies of a software block does not cost anything (assuming we have the hardware in place already). So why not have an instance of a controller running INSIDE each light? As long as we are able to apply identical configuration (such as timing parameters and presets) and feed sensor inputs to all of them, they will work in perfect synchronicity! And the controller box disappears, as suddenly each light becomes smart, capable of interpreting the sensor messages and computing the resulting state on its own.

I consider this a real breakthrough in how smart lighting systems are architected. By embedding a fully functional controller inside every light, we've eliminated the external controllers - the system bottlenecks and single points of failure. Lights are now really smart and the system is completely redundant. You have a bunch of sensors (occupancy, ambient level) that publish their readings. The lights subscribe to the sensors and each light executes its own copy of the control logic. If a light fails, it fails. But a failure affects only this single light. The rest keep working as usual. And if you look at an individual light, you can say it is really smart, because it is capable of understanding the sensors around. Each light knows that IF [there are people in the room] AND [the reported light level is below the preset value] THEN [it should lighten up]. Each light also knows that IF [there are no people in the room] OR [the reported light level is above the preset value] THEN [it should dim down].

This concept may sound very basic, but it introduces an incredible simplification to how lighting systems are built: you only need a supply voltage bus (two wires) to reach each light and stick a bunch of sensors in a ceiling. No control boxes, no central panels, no additional wires. Thanks to Bluetooth the system is configured on site using a smartphone or a tablet, a configuration template is applied to all nodes and that is it. Fully autonomous, redundant, simple. Can we call it smart?

P.S. A recently published white paper by Silvair explains how to use the mesh lighting models to build variety of devices complementing the lighting ecosystem.