Why did you lock the estimote beacons?

We are developing a prototype of an app and using estimote beacons for big part of it. I have to say that we were using the beacons more as a generic ble device rather than what they were probably meant to be.

So we were accessing the device services and characteristics directly. What a surprise it was though when I upgraded 2 of the 3 beacons we have to new firmware and everything broke down! After inspection of the services I found out that you made all characteristics read only. Is there any particular reason for that? Doesnt make sense to me…

I’m sorry about your experience. You’ve run into a side-effect of us tightening the security of our beacons. Across the entire technology industry, security always comes at an expense of something (performance, convenience, flexibility, you name it), and we decided to accept some trade-offs in order to make it harder for unauthorized parties to access/modify somebody else’s beacons.

We now require to use our SDKs with their built-in authorization mechanisms in order to write to our beacons’ characteristics. Would it be possible for you to switch to our SDK instead of utilizing generic BLE tools?

We hope for your understanding!

Hi,

not rally because with your sdk its very limited what I can actually write into the beacon (minor, major). I need to be able to edit the beacons name and other characteristics. It is not usable for us that all beacons have name EST… and I don’t really see reason why not enable it.

I do understand that you are trying to tighten up security, but at the same time you calling it “developer kit” which is not really through since developer cannot do much with it (apart from what you tell developer he should be doing with it).

I think it should be optional how much you want to secure your beacons, or it should be easier to switch between different frameworks. - Is there any way I can downgrade?

I think its important to understand that 90% of estimote beacons are probably not used in real life scenarios, but to develop prototype and proof of concepts (same as us - developing proof of concept app for innovateuk grant) and therefore require full control over our tools.

Can you please propose how to downgrade, or what else I could do to get the beacons “unsecure” again?

Thanks

Thanks for elaborating, I understand your point of view. What prototype are you working on and why do you need to modify the name of the device? Maybe we’ll be able to suggest an alternative, equivalent solution to the problem you’re trying to solve that doesn’t require you to de-secure your beacons, exposing them to the outside world in case you decide to deploy.

I’m afraid there’s no way to downgrade beacon firmware at this point.

I sorry but since there are patent applications coming along this prototype I really cannot disclose what are we doing with the beacons.
I guess Im gonna have to turn to other beacons then because now I am left with only one beacon that is able to do what we need…

just PS: not sure why its not possible to downgrade the beacons, its just a firmware overwrite?