We commonly see the following methods of interaction with Bluetooth equipment:
1) Direct to Bluetooth – This is the optimal path. In this case, the Bluetooth device manufacturer has either subscribed to a common API for connection (such as HLE 4.0) or, if they have instead published their spec so that we can still connect via Bluetooth, but must follow their steps in order to get the device to register data with our app.
2) Direct to Bluetooth to the device manufacturers app – This is less desirable. The device manufacturer requires that their app be placed on the iDevice and that they receive all data. They will then set up a cloud-to-cloud transfer of the data to our services. The reason this is less desirable is that it forces the user to use multiple applications.
3) Direct to Bluetooth and into HealthKit – In this model, the manufacturer uses Bluetooth, but keep their interface with Bluetooth secret and instead, publishes data to HealthKit. In this example, the user still has to deal with multiple applications and the data is limited to iPhones or Android devices that support the “HealthKit” database (iPads don’t work in other words).
4) Other manufacturers provide hubs that are placed in the home and the hub communicates with the various devices. The hub directly sends our servers the data that is received from the devices. The Bluetooth Hub model works well, but there is often a monthly expense for using the hub, primarily to cover the data communications cost for the hub vendor, as many of the hubs are using cell phone networks to post data out of the home. An example of the hub model is the Capsule 2net hub (formerly Qualcomm). That hub connects with a wide variety of devices, using Bluetooth to do so, but then the data is transmitted directly over a cellular network to our servers for processing. No extra apps are required on the iDevice in this model.
It’s not the underlying communications mechanism that makes the difference. Rather, it’s how the data flows from the device outward. As a non-Bluetooth example, we integrate with the Foobot air quality sensors. This sensor communicates to the device manufacturer over a WIFI connection. The sensors data then is pushed to our servers by the device manufacturers’ cloud servers. The connection mechanism is handled by the device manufacturer and the data is pushed to us via the cloud. No extra apps are required on the iDevice in this model.
We have worked with vendors that provide specialized sleep sensors. Those sensors did not use a Bluetooth connection either. Rather, they had their own proprietary “dongle” that was attached to the phone and did the communication. Similarly, we integrated with a Bluetooth dongle that connects to proprietary glucometers. The glucometers talk to the dongle in a variety of proprietary ways and the dongle intercepts those signals and transmits them to us via HLE 4.0.
When it comes to simple home automation devices like say, Philips Hue, or perhaps some of the sensors that work with the Samsung hub; again, the hub model shields us from having to care whether the device uses Zigbee or Z-Wave. The data gets transferred to us via the cloud after going through some hub, or by way of a 3rd party intermediary like IFTTT.Com.
So, In summary, it really doesn’t matter to us whether the device is Zigbee, Z-Wave or Bluetooth based. What matters is how the device makes data available, and whether it is “open” or “closed” with respect to interaction with other applications. We are comfortable with all low level communication mechanisms and cloud-based services as well. We prefer manufacturers who publish their API through Bluetooth, as it makes it so no other data movement (or apps) are required other than directly to our app from the API.