Recently, we told you about two approaches to physical-world context: Proximity vs Location, and praised the simplicity of the former—“tag” a certain area with a beacon and your app can detect when the user enters and exits that area. At the very core of this approach lies an API called “monitoring”, which allows apps to detect when somebody is entering and exiting the range of beacons. This method is baked into iOS’s native Core Location framework & iBeacon support, and is what most beacon apps are using. However, as we learned over time from our community, it’s farfromperfect.
Today, we’re releasing Estimote Monitoring. It addresses many of the problems with Core Location Monitoring, enabling your beacon apps to deliver much better microlocation experience. Let us walk you through what exactly Estimote Monitoring improves over Core Location Monitoring and and how to integrate it with your own app.
Step 1: identifying the problems
When the amount of feedback we received on Core Location Monitoring reached a critical mass, our first step was to round up the most important problems and areas for improvement:
1. I do not get enter/exit where I expect it
Core Location Monitoring is an extremely simple mechanism: it fires an “enter” event when the beacon’s signal strength (RSSI) crosses a fixed threshold. But signal strength depends on the beacon’s transmit power, the environment, radio wave physics, etc, which makes it very difficult to “calibrate” where exactly the “enter” should happen. A single spike in RSSI can cause the event to trigger much further than you’d expect.
2. I get erratic exits and enters
With Core Location Monitoring, it often happens that even if you’re right next to a beacon, it’ll trigger a “false” exit—and a second or two later, an “enter”. This flickering can ruin the desired experience and leads developers to add their own workarounds, usually in form of a debouncer. That however increases the code complexity and its maintenance burden, just to tackle a bug in the API.
3. Exit events have a fixed 30-second timeout
To receive an exit event you need to wait approximately 30 seconds after leaving a beacon’s range. It’s supposed to prevent ‘false positive’ exits caused by RSSI spikes, but we developers like being given options to customize the behavior of the APIs. Many use cases warrant much lower timeouts and it should be up to the developer to decide how long after leaving beacon’s range an action in their app is taken. The delay also makes testing Core Location Monitoring a nightmare!
4. I can only monitor up to 20 regions
Core Location Monitoring limits the number of regions you can monitor at a time to 20. What’s more, not everyone is aware that the 20-region limit applies to both beacons and GPS geofences—so if you’re monitoring for 20 beacons, it leaves you no space for geofences.
This limit made developers come up with clunky workarounds: juggling which beacons they monitor depending on the user’s GPS location, short-term ranging in the background, etc. That’s even more complexity, making beacon integrations harder to write and maintain.
Step 2: Estimote Monitoring is born
Once we identified all the potential areas for improvement, we attacked… each and every one of them!
What we have actually done?
- We took the Estimote Location packet from our Location Beacons, designed to improve Indoor Location, and based Estimote Monitoring on that.
- This means that we’re no longer restricted by the 20-region iBeacon limit.
- We’re giving developers more granular enters/exits not just for beacon’s range—inspired by original iBeacon concept of proximity zones, we have enter/exit events for three distances: near (around 1.5 m), medium (around 7 m), and far (around 15 m).
![enter image description here]()
- The whole thing works so well, that we removed the exit timeout completely. The exit event is triggered as soon you you exit the zone.
Ta-da! All 4 problems addressed!
How to use it
At this time, Estimote Monitoring works exclusively with Estimote Location Beacons. First, you need to to configure your beacons and enable the Estimote Location packet. You can find instructions here.
When your beacons are all set, you can test the improved enter and exit events with the Notify Demo in Estimote iOS app. Make sure to switch to the Estimote Location packet using the button in the top-right corner of the radar screen!
I want to use it in my own app:
Enabling Estimote Monitoring in your own app is possible with just a few lines of code. Import the Estimote iOS SDK into your project and find the identifier of the beacon you want to use—it’s on your Estimote Cloud dashboard. Then use this code snippet for the selected beacon:
let monitoringManager = ESTMonitoringManager()
monitoringManager.delegate = self
monitoringManager.startMonitoringForIdentifier("BEACON-CLOUD-IDENTIFIER", inProximity: .Near)
...
func monitoringManager(manager: ESTMonitoringManager, didEnterRangeOfIdentifier identifier: String) {
print("Entered range of beacon \(identifier)")
}
func monitoringManager(manager: ESTMonitoringManager, didExitRangeOfIdentifier identifier:String) {
print("Exited range of beacon \(identifier)")
}
I want to create a new app:
We have a template just for you! Use the Estimote Cloud apps dashboard to add a new app, and choose the Estimote Monitoring Notification app template. We’ll automatically generate an Xcode project with all the code and beacon identifiers already in place.
What do YOU think?
Our work on Estimote Monitoring definitely doesn’t stop here, and with your help, we’re confident we can make it even better in the coming future! Share your thoughts on our forums or drop us an email. Give it a go and let us know how you like it!
Bartek & Alex, Beacon Reliability Engineers at Estimote