Let's Talk About Beacons

Indoor SDK is still in very early phase, but we're pushing very hard to roll out a series of updates with new features like multiple rooms support, cloud integration and even better accuracy, so you can expect more comprehensive solution in the near future.

And if you're interested in bigger deployments we also offer beacons in bulk quantities with much better pricing.

We're treating R&D very seriously as we're thinking of beacons as much more than simply hardware. There's still a lot of ideas to explore and we try to support the community as much as we can, so I hope you'll give it another chance.

Thanks again for sharing your thoughts. That's extremely important to us and makes it possible to address issues people have with beacon technology ASAP

The thing where everyone has some idea of what they want people to see it as useful for (Ads, etc), but don't understand how to jive this from what consumers want from them.

At this stage, it still looks like a technology solution in search of a consumer problem (it certainly solves the "how do i push indoor location based ads/etc" problem, but consumers don't care or want that).

Watching most of these companies is like watching microsoft announce the xbox one.

Everyone tries to sell indoor location, but there are better ways to do indoor location, cheaper, than placing $200 of beacons and meticulously mapping where you put them. So that isn't going to go very well over time (highly likely to be supplanted by something better).

Even some of the examples are just a result of otherwise poor planning on companies part.

For example, i don't want to know "things on my shopping list are nearby", i want to know, ahead of time, exactly where the things on my shopping list are.

It's only recently (past year or two) home depot or lowes would even tell me what aisle stuff was in. I still can't go to a safeway website and get an idea what aisle my items are in.

In some cases, this is deliberate - they want you to have to browse. In any case, beacons solve none of this problem (except maybe the "i'm in aisle 46 and i still can't find x" problem, but the distance issues often stop this from being particularly useful use case).

I struggle to think of an interesting use case on the consumer side for beacons.

Maybe locations for things that move like booths at a farmers market or something.

You could treat the UUID as a domain name, have a DNS-style system where an app looks up a UUID, gets some structured data, and caches it.

That does mean, for your bus example, that you would have to have seen one of those UUIDs before while internet connected, in order to have the route data already cached.

If someone is going through the effort of placing bus beacons, there's a good chance that the location either already has good data coverage, or they could place a wifi hotspot at the same time.

---

Alternatively, certain UUIDs could be taken to mean "connect to this device over wifi, and download structured information". This does have the battery issues mentioned in the article, but I expect that, for permanent installations, people will prefer externally powered beacons anyway.

Pairing can be combined with connecting in a lot of situations though, and I believe the Bluetooth standard, as well as implementations are moving towards simplification. For example, I'd rather have a list of BT audio speakers around me directly in my music player app, then I'd just tap on one of them and hear music playing straight away. This is a protocol/API/UI issue rather than a fundamental limitation.