Let's say I have 500 iBeacons deployed that I want to use with one app.
Can I have one UUID for all 500 beacons and specific major and minor identifiers to each of the 500 beacons?
If so, can I monitor the region of my UUID and start ranging for the specific major and minor identifiers once the region is entered?
I'm confused as to what ranging actually does. Can I get the major and minor identifiers from ranging, or I will only get the distance from the device?
Yes, you can have all your beacons included in a single region defined by the UUID. It can be 500 beacons or much more: there is no upper limit. Then if you enter this region and start ranging, you'll receive a list of beacons in range, along with Major and Minor IDs. Keep in mind though that not all beacons in this region have to be in range.
I think this article we posted on Estimote Community Portal explains difference between monitoring and ranging quite well: https://community.estimote.com/hc/en-us/articles/203356607-What-are-region-Monitoring-and-Ranging-
Cheers.
The major and minor values are unsigned short integers, so that means they can store a number no greater than 65'536 within them, so in theory you can monitor and see up to 4'294'967'296 beacons per UUID, and you can have 20 of those.
Monitoring can be done in the background, Ranging needs to be done in the foreground.
Monitoring is a low power activity, ranging I read isn't.
Monitoring can be slow to react, too slow for many, especially if your looking at region triggers, entering is ok, leaving can take 10 to 15 seconds or more. Ranging in contrast is almost immediate, and quite dependable. I tried both and gave up on relying on monitoring, you need your app to be running in foreground; ranging in an ideal world.
Related
Hi i trying to detect iBeacons.
in case of region monitoring, i knew that maximum UUID number is 20.
How about beacon ranging in CLLocation?
Have maximum UUID number limite?
Thank you in advance.
There is no hard limit to the number of regions that can be ranged by iOS Core Location. I have personally set up 100 regions to range to cover a large number of Proximity UUIDs.
That said, once you get significantly over 100 it starts to have real performance impact on the phone. There will be one callback to the delegate for each region, so with 100 regions, you will have 100 callbacks per second, and even with minimal processing in the callback CPU starts to spike. The ultimate limit will be hit when the system simply cannot keep up, and depends on other variables like the number of beacons in the vicinity, the phone model, and other processing going on at the same time.
I want to track all nearby beacons using global region, then i create individual region for each ranged region from the global region, is there any regions limit for android phone ? i've read that in the ios regions are limited into 20 max.
Any help would be appreciated
Short answer: The Android Beacon Library has no hard limit on the number of regions you can range or monitor.
Longer answer: If you go beyond a reasonable number of monitored or ranged regions (a few dozen), you may experience some issues:
Elevated CPU and battery usage will be needed to process all the region matches
A maximum of 50 monitored regions will has their state persisted across app restarts. If you go beyond 50 monitored regions, then this persistence will no longer happen, and the app will receive duplicate region entry events for nearby beacons each time the operating system restarts the app due to memory pressure.
As an alternative to monitoring a very large number of regions, consider using broader wildcard patterns in a smaller number of regions (basically specify fewer identifiers that must be matched) and then read the specific identifiers in ranging callbacks and custom logic based on the identifier patterns you see there.
It is worth noting that with iOS CoreLocation, there is also no limit to the number of regions that may be ranged. The limit of 20 regions is for monitoring only, and applies to both geofence regions and beacon regions.
We are using one UUID, and major and minor combinations for different actions.
And we need to know major and minor numbers in iOS background monitoring.
The ranging can get major and minor numbers but this needs launching delay and battery consuming. So this is not the proper solution for us because we want immediate detecting and low battery consuming.
So we want to get major and minor numbers in same UUID on iOS background monitoring status.
This mechanism is necessary because we make an iOS application not for typical usage.
Is it possible?
You cannot read individual beacon identifiers using monitoring APIs. All you can do is access the CLBeaconRegion identifiers used to start monitoring. In your case, this is probably just the ProximityUUID with a nil major and minor.
The alternative is to combine ranging with background monitoring. Whenever you get a didEnterRegion event, you will also get ranging callbacks for about 10 seconds afterward, even if your app is in the background. You can use this callback to read all the identifiers.
While it is true that ranging in the foreground uses much more battery than monitoring, background ranging is actually pretty battery friendly. Consider that you will be only ranging for 10 seconds each time you enter or exit a region. (Even though ranging is still turned on, the OS automatically stops it after 10 secs in the background.) Unless you expect user to be constantly entering/exiting regions, then battery should not be a concern with such short periods of background ranging.
I have been working on a prototype iOS app utilizing iBeacons to provide location-relevant information to office employees depending on where in the office they are. The ideal use case is that whenever an employee enters or exits their office, a callback is fired which provides them some information in the form of a notification (it might make a server query to get information first, etc - that sort of thing). We also want to be able to do this when the app is backgrounded or terminated; fortunately, we already know that beacon region boundary crossings trigger the appropriate CoreLocation callbacks even if the app is backgrounded or suspended.
From looking around, I understand that broadly, I have two options for how to approach the beacon region monitoring:
Give each iBeacon its own CLBeaconRegion, and monitor for each of these regions independently.
Monitor for CLBeaconRegions that correspond to multiple iBeacons - for example, each iBeacon has the same UUID and only monitor for a CLBeaconRegion corresponding to that UUID - then try to determine which beacon triggered the boundary crossing using ranging.
Thus far, I had chosen option #1. The advantage of this approach is that I get didEnterRegion: and didExitRegion: calls for each individual beacon and immediately know which beacon I have entered/exited. Also, I only get one enter call and one exit call, which is exactly what I want. Unfortunately, I just realized that this approach also limits me to 20 beacons (since each beacon gets its own region).
I'm not as familiar with the exact implementation details of #2, so correct me if I'm wrong. But it seems that this approach has more drawbacks:
Apple discourages ranging when the app is in the background because the results may not be as accurate.
The ranging calls fire once every second, while I only want to have "enter/exit" callbacks.
If the beacons have region overlap, the ranging calls might continually flip which one is "closest", which would further complicate things.
Basically, I'm wondering if there is a way to utilize option #2, but still have the benefits of option #1 - a quick and easy way to immediately determine which beacon triggered the region change with only one enter or exit callback?
I hope this question is clear enough. It's not all entirely clear in my own head, especially how ranging works.
Option #2 is absolutely more complicated, but you must accept these complications in order to get around the 20 region monitoring limit.
A few points:
In the background, you only have around 5 seconds of ranging time, which does not give you as much time to average RSSI (signal strength) from each beacon to get a good distance estimate. So, yes, the estimates will be less accurate. If you understand this limitation and can live with it for your use case, there is nothing wrong with ranging in the background.
Yes, you will get multiple ranging calls per beacon after region entry, and you won't get any callbacks on region exit. You have to write extra code to take care of this. I have done this by maintaining a NSMutableArray of all the unique beacons (same uuid/major/minor) seen and update it in the ranging callback. You can then access this array in the region exit callback, so you know which beacons disappeared. Of course, it is possible that additional beacons were seen after the 5 seconds of background ranging time expires, but your app will never know about them. With this option, you must accept this limitation.
While it is true that errors on the distance estimate in ranging may incorrectly tell you which beacon is closest, you have an even worse problem when doing monitoring, because you don't get a distance estimate at all. If multiple beacons come into monitoring range around the same time, there is no guarantee that the first entered region callback you get will be for the closest beacon. So if your use case requires taking action based on the closest beacon, then you must do ranging (knowing that there may be error on the distance estimate.)
The drawback of the second approach is detecting the entry of a particular beacon will be purely based on ranging, that will not work if the application is killed. The reason is we will get didEnterRegion only once, because we are monitoring only one region with a particular UID. The next beacon with same UID will not be detected again if the application is terminated or if the background ranging stopped.
I recommend a combination of the mentioned approaches ,
Use same UID for all the beacons.
A beacon is uniquely identified using major/minor value that is collected when ranging.
As mentioned in apple doc, always keep number of monitoring regions below 20 by removing and adding beacons when the user moves from beacon to beacon (better to keep a beacon neighbour relationship graph in the server.)
Start ranging when entering the region ... and identify major/minor and calculate proximity.
Stop ranging when exiting the region.
Find the closest beacon from ranging method (need to skip unknown range beacons).
Monitor only the neighbours of the closest beacon in a given time.
When implementing both options, We should consider one fact, An iBeacon will be detected in 200feet distance. There may be multiple beacons in 200feet range.
If you use the same UUID for every beacon, you can just set the major/minor numbers to differentiate between the different beacons. This way, you are only monitoring for 1 beacon instead of > 20. Then just sort out which one is which from the other identifiers. This is how it works currently with Starbucks and other retailer apps. 1 beacon no matter where you are in the world, and different identifiers to sort things out on the back end.
From what I have understood, minor and major ids in beacons are used for segmentation (for instance, major for physical stores and minor for different locations within a given store).
Then, as a beacon does not deliver rich payload, I guess those ids will be exploited to deserve the adequate information to the user - and probably through webservices.
Finally, UUID are said to be for the whole fleet. From what I understand, an app (e.g for retail store) is likely to register for only one or a few UUID (generally one, more for complex architectures or overload of services).
At the application level, you can (1) range for beacons when the app is foreground (with catching capabilities for minor/major ids), and (2) detect region exit/entry (monitoringForRegion:) while in background + deliver UILocalNotification to wake up the app (going back to (1)).
Now lets deal with the end user. I think we can assume that the average one will not go through a whole retail store with the app in foreground in his hand, and is more likely to have it running in background.
Consequently, case (2) will be the most common one.
But as all emitters will share the same UUID and as the geolocation manager running in background is monitoring for region linked to UUID, didEnter and didExit regions delegate methods risk no to be triggered intelligently depending on the range/configuration of emitters. Finally, not all the indoor location-based advertising you wanted to broadcast to your customers will be received and catched.
In fact, I fear that only the one when the customer will arrive at the store location will be systematically suggested (in a background mode context).
Am I missing something?
You are mostly right. The one thing you are missing is that you can monitor on 20 different regions simultaneously, and these regions can optionally include the major and/or the minor. So you could trigger many times in a (big) store by intelligently designing your iBeacon identifiers and region monitors.
Two caveats: in-region monitoring callbacks fire when the beacon first comes into range (about 50m). They are also not simultaneous. They can take up to 15 min on an iPhone 4S with the app in the background, although it is faster on an iPhone 5.
To phrase what David said a little differently:
You can define a beacon region using a UUID, a UUID and a major value, or a UUID + a major and a minor value.
If you define a region using just the UUID, any beacon with that UUID will trigger a didEnterRegion message, and the OS will treat all beacons with that UUID as part of the same region.
However, if you create a region with UUID+Major, or UUID+Major+Minor, only beacons matching those values will trigger a region notification. You can have 2 beacons with the same UUID and major value right next to each other and different minor values. If you've registered 2 different regions with specific UUID+Major+Minor value, you'll get independent enter/exit/ranging messages about each region. A third beacon with the same UUID and major value but a different minor value will not trigger enter/exit notifications.