Serious Bug on Estimote Cloud

1

Here’s the situation. I logged on to Estimote cloud in my account, changed the beacons uuid. Open Estimote app on my mobile device, and propagate changes.

  1. Some beacons managed to sync the changes with the cloud, with the new UUID registered on both the cloud and the beacon itself. Verified this with the Estimote app and the my test app

  2. Some beacons remain stuck in pending changes in the cloud. Within the Estimote app, the beacon has an error message stating this beacon does not belong to the user. When I click claim, the error message was “Claim failed due to Bluetooth problem. Make sure your device is close to the beacon and try again.”

  3. This is the worst problem. Within the Estimote cloud, some beacons show up as having their new uuids configured with no more pending changes status. However, Estimote app still displays the old uuid, along with the 2 error messages that the beacon does not belong to the user and the user cannot even claim it.

I can verify that the beacon is not actually synced with the cloud because my non-authenticated Estimote app could still pick up the beacon and it showed the old uuids. My test app that registers the new uuid also does not pick up the beacon.

3 is the WORST problem because it creates the illusion that the beacons are already synced with the cloud.

3 is the most unacceptable bug from Estimote to be honest, because those beacons that are thought were synced and configured with the new UUIDs were already deployed physically in multiple locations.

Would greatly appreciate any advice.

2

Both (2) and (3) seem to stem from the fact that your beacons’ UUIDs went out of sync with what we have on record. I’ve just sent you an email with a detailed explanation. I’ll paste it here as well, in case anyone with a similar problem comes searching for a solution here on our forums:

Basically, once the beacon goes out of sync with the cloud (i.e., cloud says its UUID is “X”, but the UUID of the beacon really is “Y”), it’s a situation that’s virtually indistinguishable from you trying to access somebody else’s beacon (as in, our records indicate that you have the beacon with UUID “X”, but you’re trying to access a beacon with UUID “Y”). Hence the “does not belong to you” message.

We’re still trying to pinpoint why exactly beacons go out of sync in the first place, to fix the problem at its root. In the meantime though, good news is, the symptom is relatively easy to fix yourself. Since our “pending settings” mechanism actually operates on beacons’ MAC addresses, and not UUIDs, it’ll still recognize the beacon as yours. So all you need to do is queue a pending settings change on cloud.estimote.com—any change, really, could be e.g., changing the adverting interval by 1 ms. Then, if you open the Estimote app near the “broken” beacon, the “pending settings” mechanism will notice that there are settings to be applied to that beacon, fetch the full configuration from the cloud, and apply it—including the UUID. This should bring the beacon back in sync again.