Light Switch Design

[joeyh]

We are working on the BLE Smart Switch.  The requirements are pretty generic:

• Low Power consumption
• To be used by multiple smartphones within the house

The obvious configuration is to have the smartphone as the Client and the NRF device (i.e. the switch) as the server.  Because we are still new to BLE technology, we are wondering:

    When a Smartphone is nearby, should the mobile App connect to the devices automatically and stay "Connected" (with the BLE connection)?

The problem with "staying connected" is that:

• Staying connected will probably cause the device to consume more power than necessary.
• How can multiple smartphones connect to the same switch at the same time?

I suppose all BLE switches would have these same issues.  So I would assume someone else must have already solved this.

The only solution we can think of is to have the switches stay unconnected, and will only connect when the user clicks "On" or "Off" in the mobile app.  This means the mobile app would have to first connect, then update the specific characteristic.  Wouldn't this cause a longer delay to switch the light on or off?

Any advise would be greatly appreciated!

Joe

[MartinBL]

To make an informed decision I think you should read up on the concept of BLE GAP roles. It is particularly important to understand the roles of the peripheral and central, how they connect, and how your system configuration will affect your current consumption and latency. Here are two relevant articles:

1. Introduction to Bluetooth Low Energy: GAP
2. How GAP and GATT Work

Staying connected will probably cause the device to consume more power than necessary.
Probably (but not necessarily). When you are advertising you probably want to send out advertising packets at least a couple of times a second to keep the latency low. These packets (probably) need to include some data bytes to identify the switch. When you are in a connection, the only thing you need to do to stay connected is to exchange empty packets "once in a while". Probably a couple of times a second as well. Once again it will be a trade off between current consumption and latency. But the packets can be empty which means it will require less energy to transmit them. There are also mechanisms you can use to skip packets altogether (slave latency).

How can multiple smartphones connect to the same switch at the same time?
It is not true that a peripheral can maintain only one link at the time. It used to be true, but in the past couple of years we have developed BLE stacks that allow you to run up to 20 concurrent links in any peripheral-central role configuration you want. We even have dedicated examples in the SDK for this. You can read more about how it works here. 

EDIT:
More useful blogs:

1. https://devzone.nordicsemi.com/b/blog/posts/bluetooth-smart-and-the-nordics-softdevices-part-1
2. https://devzone.nordicsemi.com/b/blog/posts/bluetooth-smart-and-the-nordics-softdevices-part-2

[joeyh]

First, thank you for the insightful explanations and new information about multiple central connection that I didn't know before.  You provided exactly the information that I need.

In our use case, allowing multiple phones to access our device any time is important.  Using the algorithm in the example you gave is helpful, but it will not save any power used by our device because the device needs to keep on advertising in order to allow other Centrals to connect any time.  In some cases, it will be probably use more power to maintain the connections of the connected devices.  Of course, have Centrals already connected should speed up the time it takes to read or update a characteristic.

From our tests, follow my original described algorithm that when access the device, the mobile client will first connect > then retrieve the list of services > then read/set the characteristic > then disconnected.  The whole process takes anywhere from 1.5 seconds to 5 seconds, depending on range and on interference from other devices.  We think that the response time is acceptable.  Measuring the power usage of the device using PPK, it averages 55uA while advertising at adv interval of 250m, which is not bad.

Anyway, we will think about the two approaches a little bit more, before deciding which way to go.  Power vs Simplicity vs Response Time.  At least, I think I now have all the information for the analysis.