Konrad Dzwinel of Making Waves has put together a proof of concept using Estimote beacons, PhoneGap and Sencha Touch. He even posted the code on GitHub so we could take a look – a fast little prototype, maybe, but there are some handy code snippets you can take a look at.
Now, I’d love it if the Estimote API was swapped out for standard Bluetooth LE region monitoring with developer-specified device ID numbers but maybe someone else will tackle the task?
Have a look:
BEEKn 
Hi Doug, I’m glad that you found that interesting! My proof-of-concept app code is not publicly available (yet), but the PhoneGap plugin is, indeed, on GitHub. It’s based on the Estimote SDK because my company cooperates with Estimote. I do agree that more generic solution (based directly on the core location and core bluetooth) would be probably more useful for others. However, it’s not a rocket science to create one! I (somehow) managed to write one with no Objective-C training 🙂 If someone decides to write it, I’ll be glad to help.
LikeLike
Konrad – thanks for the clarification. And sorry if it sounded at all like a criticism! Was more like an invitation to others. I found your code to be super clear…and even as someone who isn’t a coder I figured out how to tweak it to make it work in non-Estimote scenarios, so you’re right – – I’m not a rocket scientists and it worked 🙂
Thanks for your contributions to the community and taking the time to document it and show us the power of beacons.
LikeLike
It haven’t sounded like a criticism, I totally agree with you 🙂 I’m glad that you were able to adjust my code to your needs!
LikeLike
Given this video, it doesn’t seem like businesses that host these beacons/estimote will be of value to customers and retailers. The phone has to be out of the users pocket and the user has to walk very slowly for proximity to work. Was the lack of performance due to PhoneGap, hardware/estimote, or Estimote’s software? An opportunity for retailers are the heatmaps that can come out of users walking around the stores. It doesn’t seem likes its feasible/reliable yet and all of these businesses are doomed. Am I seething this wrong?
LikeLike
Hi John, I’ve made this video and I’m playing with Estimote beacons for the last couple of weeks. From what I heard from the Estimote guys, these beacons are not meant to provide micro-location data, but only to answer the question ‘is user inside or outside the beacon zone?’ Therefore, my demo shows an unconventional use of these beacons (you won’t find anything about the heatmaps on their website). However, other devices seem to be a bit more powerfull, checkout these: https://www.youtube.com/watch?v=jyzw8c419xs . This however, doesn’t change the fact that bluetooth signal can be easily blocked or limited making whole technology a bit unreliable.
LikeLike
Hey John –
Not quite sure what you mean by ‘feasible/reliable’ – for what exactly?
First, no, the phone doesn’t need to be out of a customers pocket. Using Apple API, the app works in the background regardless of whether it’s open or closed, and regardless of whether the app is open or not. It’s one of the powerful features of iBeacon.
Second, it depends on what you mean by “for proximity to work” – work for what? The phone/beacon run on about a 1.5 second cycle in most of the tests we’ve looked at and Apple has different settings for general scanning, being in rough range of a beacon, and then checking for proximity once a beacon is found.
So, for example, you walk into a store and you can trigger a message which shows up on a person’s lock screen. The phone could be in someone’s pocket, the app could be off – but the message is still triggered.
Now, is there latency? Sure….measured in a second or two possibly.
If you want to trigger something within miliseconds, you’re probably talking about something that uses the M7 chip say with all its APIs and Bluetooth LE on a wrist band or something like Pebble.
If what you’re looking for are ‘down to the square foot heat maps’ then maybe you’re right – or if you’re looking for micro-precision in proximity you’re absolutely right. At a distance the precision varies +/- 15-20% if you’re, say, 70 meters away.
But I guess otherwise I’m not sure if this answers your question – because I’m not sure what you mean by ‘value’ – happy to try to clarify if it’s useful to you.
LikeLike
Hi Doug! Two notes from me (maybe someone will find them usefull):
– ‘Apple API’ doesn’t allow to start the closed app whenever you enter specified beacon region. This was advertised by Apple but is not available for developers (yet?). That’s what I’ve heard from Estimote people.
– “At a distance the precision varies +/- 15-20% if you’re, say, 70 meters away.” – again, I have experience only with Estimote devices, but in the real life scenario (walls, computers, WiFi networks and other people) the precision is much worse.
LikeLike
Konrad – great feedback. Sorry – I didn’t mean to imply the APP would open. But you can send a message through the lock screen to prompt the user to OPEN the app correct?
With Estimote, we weren’t getting a range of 70m by any stretch. Out of the box we’re getting MAYBE 40m but only when there isn’t a lot of interference. Estimote says you’ll be able to adjust the power settings but we haven’t seen that yet…at 40m we’re having +/- 20% so I’m with you – it’s quite ‘imprecise’.
LikeLike
Yes, as far as I know, you can send a ‘push’ message or show a notification when app is in the background and user enters a specific region.
I extended my app so that I can change the ‘power’ (and ‘frequency’) value on each beacon. This was quite simple and I have no idea why Estimote haven’t released an app for that yet. Anyway, FYI there are 8 possible values for ‘power’ property (1 being the weakest and 8 being the strongest). Factory default on our devices was 7.
LikeLike
Hi Konrad and Doug,
Let me clarify something, regards the “app in the background” question.
My understanding is that:
A) when a user enters a specific region, the system core location object will call the app’s delegate object and that delegate can process some amount of logic (for example, determining if this particular beacon does, in fact, merit a lockscreen notification) and
B) then based on that logic, the app delegate can decide to show a lockscreen notification. That’s how the AirLocate tool from Apple works, anyway.
C) I’m further extrapolating that when the app delegate looks at the beacon id that has “called” it, it might also change the lockscreen message and/or image depending on the beacon id or major or minor identifiers. So in the case of a retail store, even if that store’s app is not open, the user can get a succession of message popping up on their lockscreen (shoes, clothing, kitchenware, whatever).
D) If you tap the lockscreen notification when it pops up, this opens the background app. I don’t know if different lockscreen messages (as described in C) could be made to jump to different types of content within the calling app.
Does all this make sense and sound correct?
LikeLike
Tom –
That’s correct. Here’s a code snippet from Estimote’s sample app:
-(void)beaconManager:(ESTBeaconManager *)manager
didEnterRegion:(ESTBeaconRegion *)region
{
// iPhone/iPad entered beacon zone
[self setProductImage];
// present local notification
UILocalNotification *notification = [[UILocalNotification alloc] init];
notification.alertBody = @”Entering a Beacon Zone”;
notification.soundName = UILocalNotificationDefaultSoundName;
[[UIApplication sharedApplication] presentLocalNotificationNow:notification];
}
Using the beacon manager delegate, the app detects it has entered a region and then pushes a local notification. This notification could be used to push a specific image or ViewController when the user ‘opens’ the message.
On iOS, you must KNOW it’s your beacon – therefore, the message is only triggered if it’s a beacon you’ve told the app to look for.
There’s a difference between region monitoring (geographic) and beacon monitoring. In most cases, we’ll probably want to monitor for region and then ‘hand off’ to beacon monitoring.
Check the app developer guide here, which also outlines some stats for delays in region monitoring:
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/LocationAwarenessPG/RegionMonitoring/RegionMonitoring.html
LikeLike