Is there any process in place right now, or is there a plan for somehow establishing a custom data dictionary (key-value structure) in the beacon.
An example might help:
-As a developer, I want to insert a key-value lookup that contains "MyBusinessName" -> "Andrew Inc.". I then want to be able to attain that value, and display it in the app.
It will hold a little more specific data than the example above, but so long as it doesn't surpass the memory limit, it might be a highly function-able feature for the beacons.
The only data contained in an beacon is its advertising packet: the ID of an individual beacon and its measured power; these are used by mobile devices to estimate proximity.
Estimote Beacons are unable to deliver content on their own. Instead, installed apps on a mobile device are triggered to send content to the mobile device's screen based on that estimated proximity.
Content may be stored in a cloud and to fetch it a WIFI or mobile carrier network is required. If your deployment location does not offer a network you can embed content into the app itself.
So, really, I'm wondering if there is a possibility that this could be an added feature if it's not already in place?
If I could put in something like a small key-value store inside of it's advertising packet, or if there is a way that I can make a call to the beacon to return the key value store (how do you call the beacon to return the temperature and accelerometer data? It'd be close to the same thing in my case), I think it could open a whole new doorway to great ideas and awesome products. If you need a longer explaination of what this could be used for, or need some more examples, let me know. I thoroughly think however that if this were a feature of the beacon, it would surely please a lot of developers!
tl:dr -- The bottom line is, can adding a small key-value store to the beacon be a feature request?
Fair point, but I'm afraid that we're limited by the Bluetooth Smart advertising packet size. iBeacon packets are filled to the limit, there's simple not a single bit left to add any other information to the packet.
Accelerometer, temparature, battery data—this is all available only after you connect to the beacon, at which point we're not limited by the advertising packet anymore. Only one device can be connected with a beacon at a time, and connections usually takes a few seconds.
Would still love to discuss your use case more in depth—basically, I wonder if it'd be possible to move the key-value storage onto an external server, and use beacon's ID to identify which dictionary to use. Let me know your thoughts!
I see, unfortunate that there is not some room left to use, but limitations occur, especially with such a small amount of memory in the units. And the connecting between device to sensor definitely would not be the perfect scenario either.
But, I have thought about, and could introduce the step you mentioned before in order to attain some context specific information while still keeping the mobile app generalized in how it acts. I would just have liked to cut the process of having the app communicate with my webservice out of the mix, as all it really needs is a few pieces of information in order to operate the way I envisioned, yet none of these pieces of information is something I want to hardcode into the app (basically, the app needs room to organically grow as more people adopt it, and without a way to make the information available via the beacon, or making that web call with the ID, it would be a lot more hard to accomplish).
So, now the question stands, what would be the best way to create a lookup table using a beacons ID and expose it via a webservice? Is there going to be an absolutely consistent ID somewhere that can be linked within my webservice that I can then return data to the mobile app based upon that ID?