Hot to add arbitrary data to beacons?

I am new to Estimote beacons platform but I’ve played with beacons from other vendors. I am trying to add arbitrary data to beacons (that I just purchased) and retrieve /fetch the values from an Android app. For example, consider a beacon with UUID “ABC” has data “paintingName=Monalisa” (key/value pair). One way is to maintain a SQLite database within the app, but what if the beacon is moved to another painint, I want a way I can configure the beacon in Estimore cloud and the new values can then be retrieved by the app. How can this be done?

In the recent past, I have done the same using other beacons. Arbitrary data in the cloud back-end is created as key/value pairs and OEMs Android SDK provides nifty API methods to retrieve their values. I’ll appreciate if someone can shed some light on this.


Our cloud at this time doesn’t offer the key-value storage. There’s already a ton of beacon-specific content management systems, and generic “Backed as a Service” platforms, so we didn’t want to reinvent the wheel, and instead focus on what we do best: beacon hardware, software, SDKs, fleet management for large-scale deployments, etc.

I suggest you take a look at Parse, one of the most renowned BaaS platforms:

They have great quick-start resources, an iOS SDK, and a free tier, so you should be able to get up and running in no time.

Thanks for sharing your perspective. But, I don’t quite agree with your opinion. Attaching data to beacons is a critical function for any provider, not “reinventing the wheel”. If the concept of attaching data to beacons was reinvention, Google would not have made attachment endpoints available in Google Proximity API.

Yes, you’re right, let me backtrack a little. We actually do want to add a simple key-value store to our cloud—no ETA yet, but it is on our roadmap. In our minds, it’s a great tool to considerably speed up prototyping (no need to spin up your own backend) and maybe for some simple deployments

From our own experience, once things get a little more serious, developers start integrating with their existing systems, or it turns out they need a backend for their use case anyway, or they want a full-blown CMS service, with a mobile SDK that handles the UI parts as well as data storage, etc.

So I partially agree with you, and I partially think that what I’ve said still holds true, maybe just wasn’t phrased the best way (:

If you have a use case that you feel would stand on its own with just a few simple additions to Estimote Cloud (like a KV store), we’d love to hear about it! We decided to deprioritize the KV store b/c we feel there are other, more valuable things we could be focusing on first—but we strive to be feedback-driven here at Estimote, and we’ll be happy to be proven wrong and adjust the roadmap accordingly (:

1 Like