Can't connect or read anything from Location beacons with iPhone 7 and iOS 10.2.1

I ordered a bunch of location beacons, and had success reading their motion, and had success connecting sensors on the GPIO port. With my new phone (or maybe the new iOS), I now can’t read the motion activity, I can’t change the name of the beacons (although it seems I can change the UUID), and most importantly, I can’t read the high/low from the sensor I have connected to the GPIO.

Basically, I can’t do anything. Are other people having this sort of problem. Is there a way to detect if the problem is on the phone side of things or the Estimote side of things?

Update on March 04, 2017:

I tried a bunch of things and it looks like a bunch of these location beacons are faulty, or are just not communicating with my phone. I have one location beacon that is correctly sensing motion, and is picking up the correct activity on the GPIO. And you can update the name.

The rest of these location beacons seem to connect, with the flashing light. But then I can’t change the name. They don’t sense motion, and the GPIO ports do not pick up activity like on the other one.

Most of the beacons I ordered are not functioning in the same way. I tried another person’s phone, and they had the same problem. I haven’t done anything with these since they were shipping to my house over Christmas.

I tried updating the software to the latest version, but that didn’t do anything. Could it be that the hardware is faulty? Is there a way to troubleshoot this further. I have a project that is supposed to start later in May, but I essentially only have 1/25 location beacons that is working correctly.


Hi, I have had some similar issues, not clear exactly what is the root cause, but I am suspecting because I progressed to have more than the “20 limit” of beacons, something to do with the remote management set-up in such cases has had an impact. Check you have the Motion Detection set to on for your individual beacon in the estimote cloud for your problem beacons. I am running latest beacon firmware 4.9.3, with hardware revision F2.3 for my location beacons. Using an iPhone 6 and latest ios update (10.2.1), and can use the app to see when the beacon is moving okay, have also set the telemetry packet update to 200ms just to see the immediate response in this case. I am currently trying to figure out if the GPIO pins are properly working and report their state myself…


Interesting. This does seem like the right line of thinking. Because I ordered a set of 20 location beacons, plus the old ones I have lying around. And these new ones just don’t seem to be enabling. So I’ve got 15 out of the 20 that I ordered that are not working at all. It seems unlikely that Estimote is having those kinds of quality problems.

The cloud interface doesn’t allow me to update the beacons remotely unless I pay for a subscription. So the settings I see for these new beacons in the cloud interface are not the settings I desire. And when I change them one by one from the mobile app, the changes don’t seem to stick. For example, the motion sensor, shows that it’s on, but can’t pick up any motion. Where as the cloud interface shows the motion sensor as off.

So, I think I’m in some twilight zone that basically disables almost half of the beacons I ordered.

I have seen similar behaviour to you. We are a large organisation with 150 beacons, and only last week did I transfer additional beacons into a single account ready to deploy and have 24 beacons now listed there. My suspicion is something happens to the settings mechanisms on beacons when you go past the 20 limit, i.e. there’s either some wonky or purposeful logic that resets things and as we have both experienced doesn’t enable the app to apply settings separate from the cloud state for the beacons, I guess we could experiment with turning off cloud sync (haven’t tried that yet).
I think Estimote ought to rethink their approach here, its not good for customer relations with those of us who have made a big investment in their tech, to have these constraints applied like this… I’m hoping its a bug/oversight on their part. I have contacted them directly to query this.

@crusty - By the way, I’d be really interested to know how you got the GPIO pins to register input with your original <20 beacons. I’ve been able to drive output (turn on an LED), but not register any input so far…


Cloud Sync
How do you turn that off? I don’t see the capability in the remote management dashboard.

I have attached a pressure sensor to the GPIO, so my use case sounds a bit simpler. Basically when you press it, it takes the resistance from an open circuit, to a short circuit. So, I use Ground, and GPIO0 or GPIO1, and it flips from high to low when I press it. Pretty cool. Not sure about the impact on battery life.

Ah, apols, I was confusing myself with the auto-firmware update option, doesn’t seem you can turn off cloud syncing.

I want to do exactly the same thing as you regards a pressure sensor basically using a variable force resistor, so good to know you have something similar working - thanks!

Great. Well, if you hear back from Estimote, let me know. And I’ll tell you if I hear anything.

BTW: What industry are you working in? I’m in healthcare.

@crusty ok have heard back from Estimote and I think I understand what has happened regards the subscription being required. This all came into place at Estimote in November - we bought our beacons in July, so this was not a thing back then. We have a single account that has been “grandfathered” (yet to confirm myself) so that we can use the management functions on all our 150 beacons, but not the account I was selectively transferring ownership to to make the deployment easier.

I have pointed out the fundamental issues though regards not being able to update any of the beacons’ settings with the app, by some behaviour that kicks in when you have 21+ beacons and no subscription for cloud management. Also not all beacon settings can be set with the app (two particularly important ones for us) so there is a flaw there, in the sense that you are meant to always be able to set a beacon’s configuration with the mobile app…

Piotr is very helpful and on the case, so hopefully hear more back soon.

On the side note: I have also done many years in healthcare related IT myself and many other sectors too. Right now I am focused on developing IoT solutions in the academic context.

Thanks for reporting all this.

I created myself a fresh Estimote Account and transferred 21 beacons to it. Here’s the problems I’ve been able to reproduce, we’ll look into fixing these:

  • changing the name in the app doesn’t work
  • “beacon in motion” doesn’t work => beacon detection in the beacon works fine, if you try e.g. the Estimote Telemetry packet, or the Estimote SDK, it’s just broken in the app

All the other settings in the app that I tried (packets, flip to sleep, GPIO) worked just fine for me. From what I gather from your posts, you mostly had issues with motion and name though, is that right?

@Piotr thanks for looking into this quickly.

There was a question mark over GPIO - did you get both GPIO output and input working and being reported correctly in the app? - I’m going to test this myself later today and will report back.

@heypiotr @simonc

The temp and light sensor seem to be working. The remaining battery life of 2 years with fresh batteries doesn’t seem correct, but I’m not sure on that one.

I haven’t checked the telemetry packets because I’m trying to get enough functioning units to start this project in a few weeks and just wanted to get the basics working first.

As for the GPIO, it does not seem to be functioning on these certain units. When I’m on the main “Beacon Details” screen in the Estimote iPhone app, and I go to the bottom of that menu where the GPIO is, it will not flip from high to low when I activate my pressure sensor. I’m using the pressure sensor in “Input Pull Up” mode connected to GND and GPIO 0.

(By the way, there’s another bug in Estimote app. On the beacons that are working correctly, the flip from high -> low does not show up on the GPIO view, only on the GPIO row of the “Beacon Details” screen.)


Regards battery life, for me the default out of the box config, has IBeacon and telemetry packets turned on, and the packet send rate is quite high. Turning off iBeacon and reducing telemetry to once every 2 seconds gives me a battery life of up to 7 years. If I tune telemetry to once every 10 seconds which you can only do through the cloud configuration options (app only gives you range 2 seconds to 100 ms) then you can get this up to 8+ years, which is very good in my opinion.

Interesting to see your GPIO issues, explains why I couldn’t seem to get GPIO input state showing any changes on the app. I can get GPIO output to switch using the app toggle button and turn an LED on/off okay.

@crusty just out of interest what kind of pressure sensor are you using - do you have a link you could share ?


Not to be paranoid, but maybe we can email about this topic, and I can share what we’ve learned. It’s sort of the Wild West in this space ,and we’ve had to work quite a bit to get this working. And then we can leave this conversation for this particular issue. Cheers.


Piotr: While we’re on the topic, I’m having trouble reading the telemetry data for the GPIO using Swift.

Do you have sample code for reading GPIO 0 or GPIO 1? Including how to do the initialization. I’ve written a few lines of code, but I just don’t seem to be able to get it working.


@crusty the following might help you, though I am working in Micro Python…

Bascially the BLE advertising estimote telemetry packet maps out like this:

# See:
# Telemetry is a 31 byte bluetooth advertising packet, example:
# data = b'02 01 04 03 03 9a fe 14 16 9a fe 12 b6 ff 4f fa 45 3f 5c d2 00 f5 06 3d 04 e5 f0 00 00 00 00'
# pkt idx: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
> def estimote_getSubframeType(pkt):
>      return(pkt[20] & 0b00000011)
> def estimote_getGPIO(pkt):
>     # Only available if this is a subframe A telemetry packet (0).
>     if (estimote_getSubframeType(pkt) != ESTIMOTE_SUBFRAMETYPE_A):
>         return(None)
>     # GPIO
>     # byte 15, upper 4 bits => state of GPIO pins, one bit per pin
>     # 0 = state "low", 1 = state "high"
>     pin0 = 'low'
>     if (pkt[26] & 0b00010000) >> 4:
>         pin0 = 'high'
>     pin1 = 'low'
>     if (pkt[26] & 0b00100000) >> 5:
>         pin1 = 'high'
>     pin2 = 'low'
>     if (pkt[26] & 0b01000000) >> 6:
>         pin2 = 'high'
>     pin3 = 'low'
>     if (pkt[26] & 0b10000000) >> 7:
>         pin3 = 'high'
>     return (pin0,pin1,pin2,pin3)

@simonc, right, GPIO, I missed that. Just tested it, I know it’s using the same mechanism that Beacon In Motion does, so I was expecting it to be broken as well … and yes, it is :stuck_out_tongue: I believe our Mesh support broke these two in the iOS app, we have a fix in progress.

In the meantime though, GPIO and motion/accelerometer work just fine, they’re only broken in our iOS app (; I tested GPIO with the Android app (very simple test where I connected GPIO0 to GPIO1, set 0 to Output, 1 to Input, and then I switch 0 between high and low and check if 1 reacts) and it worked okay. Also tested w/ the Telemetry Packet (used this:, and it worked too.

@heypiotr - Thanks Piotr, I came to the same conclusion and am able to receive the Estimote GPIO status correctly by directly reading the telemetry packet, so that part works for me, its just the ios Estimote app itself (as you describe).