Light Switch Design

RE: Light Switch Design

joeyh — Thu, 13 Sep 2018 08:24:27 GMT

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.

RE: Light Switch Design

MartinBL — Tue, 04 Sep 2018 11:11:29 GMT

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:

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:

RE: Light Switch Design

brian fleming — Mon, 03 Sep 2018 23:01:04 GMT

It al depends on the Rx dBm value, and there does not seem to be a set formula. It could even depend on other unrelated BLE devices within range, but my experience of about -60 dBm, the connect time is from 5-30 seconds.

RE: Light Switch Design

joeyh — Mon, 03 Sep 2018 14:49:31 GMT

I wonder what the typical and worst-case response time for making a Connection to the BLE device is. Will it add significant delay if the mobile needs to Connect first, before updating the characteristic value?

RE: Light Switch Design

brian fleming — Sun, 02 Sep 2018 06:55:24 GMT

Sorry, a mistake, but it is difficult because I do not know exactly what you are doing. If you have several BLE devices in a vicinity which are discoverable and they all have the same device name, you will have problems. All BLE devices within range which you wish to connect to, must have different device names.

RE: Light Switch Design

joeyh — Sun, 02 Sep 2018 04:05:07 GMT

Yes, Exactly. "Anyone can access the device, but only one at a time. All your BLE devices probably should have the same 'device name' which is programmed in".

That's why I said, we will cannot keep the connection between phone & device forever. It must disconnect from time to time to allow other phone to access the device. Thus, the suggestion to disconnect immediately after every button click.

I guess we will experiment with the speed of BLE connection, and see if reconnect every button click is acceptable or not.

Another option I see is that, our Mobile App will try to connect to the BLE device (and keep connected) whenever our Mobile App goes to the foreground. It will disconnect as soon as the Mobile App goes to background, or when the phone is turned off. This means once a phone grabs the connection to the BLE device, another phone will not be able to access that device until the original phone switches to another app or have the phone turned off.

RE: Light Switch Design

brian fleming — Sat, 01 Sep 2018 15:02:42 GMT

I should have said, anyone can 'connect' to the device, but only one at a time.

RE: Light Switch Design

brian fleming — Sat, 01 Sep 2018 14:56:06 GMT

Just a note about Stack Overflow. There are lot of trolls on that forum which will do anything they can to humiliate and degrade you, don't take it seriously.

RE: Light Switch Design

brian fleming — Sat, 01 Sep 2018 14:51:07 GMT

Paragraph 1, yes, once a connection is made, advertising stops, until the connection is lost, by whatever means.

Glad you clarified on the power source.

Anyone can access the device, but only one at a time. All your BLE devices probably should have the same 'device name' which is programmed in by you with your firmware so that your app will only search for those devices and not find your BLE keyboard etc.

Creating the code to connect to your BLE device via a smart phone can be a real challenge.  Assuming your app will be for Android, here is link to Stack Overflow which I posted, which is as close to 'copy and paste' that you will ever get to paste into your Android app and get it talking to your BLE device.

stackoverflow.com/.../send-about-ten-two-digit-numbers-at-a-time-to-a-bluetooth-device-at-random-inter

RE: Light Switch Design

joeyh — Sat, 01 Sep 2018 13:24:44 GMT

Maybe I hadn't made myself clear.

These are "battery" powered switches/lights that are meant to be used by anyone in the house. They need to be controllable by anyone's phone in the house at any time. As we all understand, if 1 phone stays connected to the device all the time, the device will never advertise, and therefore no other user will be able to access the device.

Without employing a gateway/hub, how can we make it possible for everyone to access these devices? That's why I suggested "letting the switches stay unconnected", and only connect when someone press the button on the mobile app.

AC wiring does not come into play in our use case scenario.

Joe

RE: Light Switch Design

brian fleming — Sat, 01 Sep 2018 11:44:26 GMT

This is my experience. The BLE device advertises to all masters ('it says hello world, I am ready for a connection') until it makes a connection either automatically, or by the user making a selection on the master. When it has connected to a master, it stops advertising, and other masters can not 'see' it. If it automatically made a connection to a master in the same area, that master would have to move out of range, or the user would have to disconnect if another master wanted to connect.

Re: How can multiple smartphones connect to the same switch at the same time?, the BLE device can only connect to one master at a time, otherwise chaos would result, if several masters were connected and tried sending data to the BLE device.

Also from a usability perspective, when a user initiates a connection, the connection may take several tens of seconds in a worst case scenario. Users might not be happy with that.

Each 'switch' would have to have some sort of identifier programmed into it by the user, like bathroom light, bedroom night stand, dining room light, or the app would have to have those selections programmed into it by the user if one switch were to control several lights which is very possible of course, however, the AC wiring for all lights it controlled would have to be routed to the switch when the building was constructed, this could be a problem.

I hope this helps!