Smart Homes: Why Bluetooth Smart ?

As we started meeting potential customers (and investors), one of the most commonly repeated question has been: "Why Bluetooth Smart?". Or more precisely, "In a residential environment, what would be the problem it can solve, while WiFi/Zigbee/Zwave can’t?". The answer is: there are several use cases where Bluetooth Smart helps. A lot! Let me talk about some of them.

The key difference between Bluetooth Smart and all other wireless protocols is it is the only one communicating directly with a smart phone (or a tablet or a smart watch...). Even WiFi is not direct, as it goes through an access point. Being direct peer-to-peer the devices know if they are close to each other. We call this proximity. Scenarios? Indoor location is #1. You enter a room (well.. your phone enters a room - but we start considering this equal :) and the lights come up. You leave the room (your phone or a smart watch does) and the iron goes off. This is simple. But can be more sophisticated., like setting down the HVAC temperature setpoint by 1 or 2 degrees when there are more people (=more phones / wearables) in a room. We can  do this on per - room basis, as every (Bluetooth Smart) light bulb or every (Bluetooth Smart) wall switch can capture and relay such information.

Then there is the iBeacon feature - an App can be triggered in proximity of a Bluetooth Smart thing. Which is helpful when you want to open the garage door or a door lock. If they are Bluetooth Smart - based, the corresponding App is already on your screen, offering the "Open / Unlock" action. Additionally you will still be able to unlock the door when the main hub has gone down (a rare case, but just knowing you do not depend on this, makes you, as well as the door lock manufacturer, feel better).

RSSI (Relative Signal Strength Indicator) is helpful even without the iBeacon: a phone can group devices close to each other together and dynamically adjust the presentation. When I'm in the kitchen, most likely I want to control devices in the kitchen, so why not promote them to the main control screen?

Direct connection between a smart device and a "thing" gives us more than just RSSI - based location and triggers. It allows a smartphone to be a remote screen / keyboard attached to the "thing". You can connect to a lamp and configure which scenes it participates in. You can connect to a wall switch and configure the actions it triggers. Your kettle can connect to you (when you are near by and it is easier to draw the attention) it needs a descaling kit. All directly from a phone, no gateway nor hub nor computer required!

Also implementing a Bluetooth - based smart infrastructure at home helps the home interact with your wearables. There is no doubt wearables will be Bluetooth - Smart based. Bluetooth has won this battle already. But why should not the Jawbone UP24 be able to start your coffee maker when you are about to wake up? With Bluetooth Smart this can be done easier than bridging several technologies.

Then there is the power consumption problem. Bluetooth Smart has been designed with coin-battery powered devices in mind. It is by far the most energy efficient protocol. Coin battery - powered sensors last for years. Try that with WiFi.

And last but not least is the radio, designed from the ground up to live in the crowded 2.4GHz spectrum. Bluetooth Smart simply knows there are many occupied channels and a lot of interference. It assumes there can be many packet collisions. It is not surprised by the fact the sub-GHz bands are now endangered by new LTE allocations. It just works. Designed to withstand the poor propagation conditions.

Plus it is a single frequency allocation, world-wide. Plus, because of the combined wearables + other use cases scale, the BOM of adding Bluetooth Smart to any device is the lowest. Plus it has a high data rate. Plus it offers a very high implementation flexibility, while still staying within a strictly defined standard.

Minus? It is more difficult to implement (especially for building automation) than it seems. The main reason is, it has been designed for peripheral sensors talking to a central controller, not for a controller to fire commands to peripheral actors. But there are solutions ready. We can help with that ;)

Comments