Beacons are great for indoor positioning, but Estimote took them one step further with nearables. One can say the step is towards IoT-ization of simple objects, and we were excited to see how far they can go. This article is all about squeezing the juice out of Estimote Nearables and combining them with mobile & wearable tech to see how they would perform in real life situations.
To share our impressions and showcase the results, we created a short video, featuring our experiment.
Nearables Wearables Experiment featuring Beacons Stickers from ELEKS Digital on Vimeo.
We chose tracking people’s movement as the use case for running our experiment. In reality it’s not as creepy as it sounds. Big offices often face the difficulty of locating and finding employees within the building, especially if they are busy with lots of meetings and rarely stick to their desk. Sure, you can use the magic of mobile phones to find a person, but not everyone carries their phone around (shocking, I know) and interfering in meetings with phone call is plain rude. It would be much easier to just know where you can find the person to solve a critical issue in a brief personal conversation. Even though this case looks more like a traditional beacon one rather than a job for nearables, we chose it simply because we faced a similar problem of finding the necessary people in our five-story office building with 600 employees. We also wanted our experimental app to lay ground for statistical analysis and future optimization of employee location inside a company.
At ELEKS, we don’t think much of hackneyed solutions, so the idea of connecting nearables with phones was rejected at once. Instead, we decided to use smartwatches (both Android Wear and Apple Watch) as target devices for tracking. This basically means that the smartwatch will be disconnected from the phone and the app will be 100% standalone. Another reason for choosing smartwatches is simply to see if it’s actually possible, considering the limitations of smartwatches like Bluetooth Low Energy API, HTTP transport, background services, etc.
The idea is simple: we would stick nearables near the key spots of the office like exits, elevators, kitchens, gym, etc. Every nearable’s UUID would be linked with a certain place. Meanwhile, employees would install the application on their smartwatches and register (which, of course, requires accepting an agreement). That would be the only interaction required from a user.
The application would primarily have the following functions:
Additional functionality would include
We didn’t encounter any problems with the SDK when working with samples on smartphones. So we were ambitious to think that everything will work the same way on watches as well. A smartwatch receives data from a nearable, sends it to the server and your current location becomes available for other people. That doesn’t sound difficult right?
Using the same system on the phone and the watch allows using all existing libraries, animations and SDK features on a small screen, so we were expecting to use Estimote SDK on the watch the same way we would on a phone. With the recent Android Wear update’s Wi-Fi support (if it is available on the hardware level), we wanted to use wireless connection to send data from the sticker to the server.
We have already seen nearables monitoring work on iOS when testing Estimote SDK. What we really wanted to find out was if standalone Apple Watch apps could detect Estimote beacons, since watchOS 2 allows access to watch hardware and communicating directly with remembered Wi-Fi hotspots.
Fortunately, we had no problems with running Estimote SDK on an Android Wear smartwatch. Guys from Estimote prepared exhaustive examples (just don’t forget to add required permissions), so It didn’t take much time to write a simple service for the smartwatch to communicate with nearables in the background.
We did face some problems, though. For example, we couldn’t rely on the SDK to handle events when the device appeared in or fell out of the range of a nearable. It worked with beacons but not stickers. We just didn’t receive events from stickers. As a workaround, we had to use another option: the listener, that handles every event received from a nearable (about 2 sets of events from all stickers per second). And voilà - we managed to receive data from stickers. Now it’s time to share them with the server.
Previously, to send data from the watch to the server, we would use one of DataLayerAPIs to pass data to the phone, and then the phone would send it to the server. But with Wi-Fi on the watch on, can data be sent directly to the server? The answer is yes. But, of course, there are some details you should be aware of:
*Also, keep in mind that Wi-Fi can be automatically disabled when the battery is low (this can be configured in the watch’s settings).
Following these statements, you can use your regular code to send HTTP requests. In our case, we used the OkHttp library. We received data from the server to display locations of other people the same way. One of downsides here is that you can’t debug your app while your watch is disconnected from your phone. Basically, this is how it worked on my table with nearables, wear, phone on it.
When monitoring the area to locate nearables, the existing Estimote WatchKit SDK works only for watchOS 1. The applications run on the iPhone and the Apple Watch is used here only to display the notifications. As far as for OS2 the applications run on the watch directly, we could not use this SDK here. We also tried different workarounds to make Apple Watch detect nearables, but it seems like Apple worked hard to prohibit this feature for the Watch.
The Geeky Part
We found that the native iBeacon SDK CoreLocation works with watchOS 2, and were excited to see if it could detect beacons. Unfortunately, all monitoring APIs are marked with the __WATCHOS_PROHIBITED attributes and are not available for watchOS2. This was shortly mentioned by Apple’s engineer during CoreLocation session at WWDC15, meaning that the smartwatch cannot monitor beacons the same way iOS does, especially in the background.
Another option to detect nearby beacons was to use CoreBluetooth and scan for peripherals when the app is in the foreground. This framework is hidden by default for Apple Watch but it can be added to the watch app extension. We saw that CBCentralManager is not visible in headers but exists in the runtime, so we tried to call scan for peripherals can find beacons on the iOS. Unfortunately none of the
CBCentralManagerDelegate methods is called on Apple Watch.
We came up with several theories to explain why Apple decided to disable monitoring on the Watch:
We wrote a simple demo app to search for the “known” nearables and send location updates to the server. Background mode had to be allowed for the app to perform background monitoring: “App communicates using CoreBluethooth”
There are 2 APIs that allow searching nearby beacons on iOS using Estimote SDK:
There are two options available while working with the APIs:
While both these options work great when the app is in the foreground, they behave differently when the phone is locked:
And one more thing. If the application was terminated by the user, the system will not launch it even if a monitored beacon was found. By killing the app, users sort of say they don’t want this app to perform any operations, so it’s quite logical that it doesn’t launch on its own. But if the application was killed by the system (e.g. because of memory pressure), iOS will launch and notify the app about the found beacon.
Certainly, testing our experiment in the real environment gave us more insights and revealed some issues that the theory couldn’t. Nearables turned out to be not that stable, as each of them behaved differently. The signal intensity changed for the same nearable in the same conditions. Moreover, 4 stickers refused to work by the end of the testing.
Two most important findings:
|The optimal distance between devices||SmartWatch||1 m||With distance increasing, the signal becomes unstable.|
|The maximum distance between devices||SmartWatch||2 m||At this distance the signal is very unstable, often nearable is invisible.|
|Nearable connection time||SmartWatch||3-15 sec||The time of connections depends on the quality of nearable signal.|
|Distance||Nearables to SmartWatch connection time|
|0.2 m||2-3 sec|
|1 m||4-5 sec|
|2 m||6-15 sec|
|Barriers for nearables (interrupt the signal)||SmartWatch||No signal||Smartphones, laptops, monitors, microwaves, refrigerators, ceramic cups filled with water, the human body. If any of these is in the line of sight, the signal is lost or partially interrupted (transmission quality is deteriorated).|
|Not barriers for nearables (do not interrupt the signal)||SmartWatch||Signal present||Doors, clothes, outerwear, bags, backpacks.|
|Connection of several nearables with a single smartwatch||SmartWatch||OK (4 nearables)||Only the information about the last nearable to be discovered is displayed.|
|Connection of 2+ smartwatches with a single nearable||SmartWatch||OK (2 devices)||The number of devices connected does not affect the nearable signal.|
Despite all this, we consider our initial goal reached with Android Wear (the app received data from a beacon in range, sent it to the server and received information about the location of other beacons, being run on a smartwatch that wasn’t connected to the phone) and partly reached with watchOS.
Our experiment with nearables left us with mixed feelings. I mean, we weren’t impressed with the results. Mainly because, even though the nearables were located with no significant delay in time, the distance to the object has to be no longer than 1 meter, otherwise it wouldn’t get recognized. But if you think about it, on the estimote.com website the beacon stickers are in the “Waiting for certificates” status, and we were lucky enough to get them now. We also used early versions of the SDK (the first version for Android) and probably a lot of its issues have already been fixed and features improved in later versions. One thing we can say for sure: beacons are an amazing technology that has all the potential needed to become huge in the future.
From our experience in IoT software development, we can say that beacons and wearables are quite promising technologies allowing you to create additional touch points with your customers, as well as to streamline your business operations. But as you can see from our experiments, the deployment of such a solution is not an easy-to-do thing and requires a laser-like focus on various tech details.
With our R&D team, we can help you to validate, design and build innovative IoT solutions. Don't hesitate to contact us!
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.