How I could use the storage, based on the store scenario you presented on your site:
1) Customer service: every time a mote gets a ping from a customer, log it. If the customer pinged the area 2-3x, send a message asking if they would like a sales rep to help them.
2) Analytics: building on 1), collect the logged hits from the devices and learn how customers move through the store, who moved through it (i.e.: any customers registered on a loyalty program?)
3) Admin user uses an app to configure coupons to store on the devices.
4) Track stock levels. If I could store stock levels on the beacons, then I could build an app that can be used to make queries ("Where can I find Levi's 501 Jeans with a 36 waist, 36 length?" "Oh, we have one pair left, look here…")
Currently, the way you have to do these things now requires too many moving parts: a mobile app, the motes, and a web server for the mobile app to talk to. I believe the web server is unnecessary: if a user has data disabled, or if the store doesn't want to provide free wifi, then there's no way to facilitate these types of interactions.
Robert, I'm fairly certain that is not possible with any BLE system. Main obstacle is that a slave device, such as a beacon, can only be connected to a single master at a time to do things like stock look up or other things you've listed. So while customer A is connected, customer B can not connect. There is also security issue of customer A connecting and then leaving the connection open, denying access to customer B.
The way beacons work is turn the problem around. Your phone looks at the beacons that are near it, and make an educated guess as to it's location based on relative signal strengths and then go to a web app to fetch the data.
Beacons don't get a "ping" from the customer. They are, just like their name suggests, beacons. They send a ping out with their id for whoever wants to listen.
You can use passive BLE devices to listen for customer's BLE device, but only if those devices are in advertising mode which you'd have to put them into by an app running in the foreground. Usually stores use WiFi requests to track customers.
Thank you, bravo22. I appreciate the clarification - I obviously misunderstood the capabilities iBeacons offered. Kind of sad though, I think there's a huge opportunity in providing hyperlocal capabilities the way I described.
So let me check my understanding: what I'm seeing is that there are only two scenarios that make iBeacons useful:
* the mobile app has to have all possible beacon id's hard coded (or configurable by the user) and mapped to desired responses. The tradeoff is that any growth in the iBeacon network necessarily requires an app update.
* the mobile app has to function like a dumb terminal, receive a ping, then query a separate server asking what's special about that ping. This avoids updating the app, but adds a whole new point of failure to the system.
You are correct. Think of iBeacons as kinda of like GPS. They feed you data, not the other way around. You can certainly have more advanced capabilities w/ BLE -- similar to what you suggested -- but you'd have the single master problem.
To comment on your understanding:
The app doesn't need them hardcoded, it can query a server and say: here are the beacons I see, where am I?
Alternatively you can include location information in the data broadcast by the beacon. So one of them can say I'm at the end of isle 1, the other says I'm at the start of isle 1, and yet another says I'm at the end of isle 2. You can figure out your approximate position by their relative signal strengths. They can even have broadcast the exact GPS coordinates of where they are located (hardcoded in them of course) which if I recall correctly Apple can use to update their location service to give you very accurate positioning.
Bear in mind though that beacon data, unless encrypted, is public but even if encrypted it can be duplicated so someone can mess with you by creating a duplicate tag and placing it nearby.
Not sure where in the article specifically you are referring to.
What I saw: "The software uses wireless beacon-driven technology that operates in tandem with smartphones based on a user’s micro-location to exchange data and information." "To help guide people through the r/evolution workplace showroom, Knoll employed Bounce by Knoll, a brand new mobile app that will push information to users as they encounter Bluetooth beacons positioned throughout the showroom." suggests that beacon broadcast an id, or position and the app uses that info to fetch data from the cloud relevant to the user's position, which is roughly triangulated from relative signal strength of each beacon.
They can analyze user's movement through the cloud.
1) Customer service: every time a mote gets a ping from a customer, log it. If the customer pinged the area 2-3x, send a message asking if they would like a sales rep to help them.
2) Analytics: building on 1), collect the logged hits from the devices and learn how customers move through the store, who moved through it (i.e.: any customers registered on a loyalty program?)
3) Admin user uses an app to configure coupons to store on the devices.
4) Track stock levels. If I could store stock levels on the beacons, then I could build an app that can be used to make queries ("Where can I find Levi's 501 Jeans with a 36 waist, 36 length?" "Oh, we have one pair left, look here…")
Currently, the way you have to do these things now requires too many moving parts: a mobile app, the motes, and a web server for the mobile app to talk to. I believe the web server is unnecessary: if a user has data disabled, or if the store doesn't want to provide free wifi, then there's no way to facilitate these types of interactions.