Smart Lights

It was December 2016 and we were entering the last straight to finalizing the Bluetooth Mesh specifications. I felt we were missing the crucial part of the architecture though,

We had lights and sensors and other stuff specified. All good. The lights could react to on.off, dim level, color temperature and hue / saturation. And I was especially happy about how we defined sensors, reusing the wealth of data already defined by Bluetooth such as (GATT) Units - things like Celsius temperature or catalytic activity concentration (katal per cubic metre), and GATT Characteristics, giving us instantly definitions of close to 200 sensor types. 

But lights and sensors had been in separate domains. Sensors could report occupancy and (too) low light level, while lights would still remain off, waiting for an "on" or "dim up" message to arrive.

This is how everybody else have been doing things, from Z-Wave to ZigBee and DALI. There the protocol defined and messages within that protocol. It is then "left to the application" to use the messages, such as receive sensor messages, figure out what they mean, and send commands to actors (such as lights - turn on!). What standards call "applications" are in practice "automation controllers", known also as hubs or control centers. None of the standards specifies what the application controller should be doing.

None except Bluetooth mesh.

So this is what I was struggling with, strolling through dark and cold Boston streets in Winter 2016. And it started dawning on me we absolutely should make the lights understanding sensors directly. By dropping the application controller concept entirely.

Or - to be more precise - by moving the controller logic to each light. From the center to the edge.

A light could then subscribe to both occupancy and light level sensors an be able to figure out ON ITS OWN what to do: turn on or off or dim up or down.

"They would be really smart lights", one of my colleagues commented. Indeed.

As there was no example anywhere on how to actually DEFINE the application controller in a standards specification, we struggled initially developing the document structure - defining state machines, events, transitions,. It ended up being quite complex (and novel) specification. And immediately we started appreciating the benefits of what we had just done:

• Redundancy - no point of failure. A light fails - the other lights continue to work, even compensating for the lost one. A sensor fails - the light continues to work, as it may be subscribed to multiple sensors. 
• Scalability - you do not need ANY control messages in the network (except for special cases). All that is needed are the sensor readings. The lights will know what to do.
• Latency - there are no round-trips to the controller and back.
• Cost - the standalone controllers are not needed anymore, together with their backup systems, housing cabinets, etc.

(click for a short animation on how that works)

This 2016 Boston Winter was the defining moment for Bluetooth mesh. It set the Bluetooth architecture apart, offering what no one else had done before. The decentralized architecture is now the key differentiator and one of the ingredients that "make this whole system work". In other words, why customers like it. "It just works" - the feature sometimes the most difficult to deliver.