Re: Options for passively communicating with BLE devices
Re: Options for passively communicating with BLE devices
- Subject: Re: Options for passively communicating with BLE devices
- From: Spero Koulouras <email@hidden>
- Date: Fri, 13 Jun 2014 18:07:06 -0700
Our use case, for home automation, requires that many BLE Peripherals (lights, plugs, locks, etc) can be controlled by multiple smartphones acting as BLE Centrals. Our approach has evolved to a hybrid iBeacon/long running scan model:
- All peripherals act as iBeacons, triggering a notification when the phone comes in range. Our app can be brought to the foreground as a result of the notification.
- When in the foreground our app uses long-running scans for our automation service uuid's. We continue to scan in the background at a significantly reduced rate.
- Our peripherals advertise our service UUID and also advertise MFG specific data including current device state.
- When the smartphone scans and receives the MFG specific data it updates local state for each discovered device. This has an impact on the smartphone UI of indicating a light is on/off or a lock open/closed whether the change was caused manually on the peripheral or via command from any controller.
- When we need to control a device the smartphone connects, updates a characteristic, then disconnects. Our connection lifetimes are as short as possible.
Operating in this "disconnected" mode allows multiple controllers to operate with the same set of peripherals. State updates are conveyed through the advertising packets without a connection required. The downside to this method of operation is that even though control messages are secure, state information in the advertising packets is transmitted in the clear. Other issues include a potential race condition when two controllers try to update the same device (very small window, safely ignored for us) and latency on slave updates proportional to the frequency of advertising packets.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden