Monitoring not detecting beacon right next to device

I’m having trouble with Monitoring.
I have my ESTBeaconManager monitoring for a specific region, with UUID, Major, and Minor values.
The beacon is right next to the device but the didEnterRegion method is never fired.

If I start Ranging for the same region, the beacon is detected just fine.

Am I missing something?

didEnter only fires when you move from outside the range of the beacon into range. If you start monitoring while the device is already in range of the beacon, it won’t trigger an enter. It will however trigger the didDetermineState delegate with CLRegionState.Inside, so if you want to determine the initial state of the beacon region, this is a good option.

Honestly, these days I mostly use the didDetermineState delegate instead of didEnter and didExit. It gets triggered alongside these two, with the new state, and also works for determining the initial state.

@heypiotr
I tested the didDetermineState method and while it does fire, it is showing the state as being Outside when the beacon is still right next to the device.

I’ve double checked the UUID, Major, and Minor values to make sure they all match.

So what could be happening here?

Bringing attention to this topic again because a resolution has not been found.

Monitoring is not detecting a beacon right next to the device. See my previous posts here for details.

We’ve had to push out the app using the more energy consuming Ranging in the feature where we were going to be using Monitoring.
Being able to do background monitoring is a big deal so we need to resolve this as quickly as possible.

Thanks for bumping. In the didDetermineState callback, can you double-check the region parameter? didDetermineState will fire for every single region the app is monitoring for, so let’s just make sure this outside value you’re getting is for the proper region.

You can force a call to didDetermineState for a particular region with the requestStateForRegion method of the ESTBeaconManager; I sometimes add this to my ranging callback to easily identify if I’m inside or outside, and track how this changes, maybe you could do the same for debugging purposes?

I’ll give this a shot as soon as I possibly can (which might not be for several hours).

I’ll also check if I can unpack the region object in the didDetermineState call and see if it still matches the parameters I gave to it when I started monitoring. There is only one region being monitored in this test so I’m not sure what could have happened.

I’ll reply with my findings as soon as I have them.

So somehow, by using requestStateForRegion, receiving an Unknown state for the region initially, the method didDetermineState finally returned Inside for the beacon region.

Looks like it’s finally working properly.

Sometimes it takes a few seconds after startMonitoring for iOS to decide whether it can or can’t detect the monitored beacon. During this time, forcing a call to didDetermineState via requestStateForRegion yields Unknown. As far as I’m aware, that’s the only time when it can be Unknown—ordinarily, didDetermineState is only invoked when the state (a) is determined for the first time (i.e., transitions from Unknown to either Inside or Outside), and then (b) whenever it changes from one to another.

(Haven’t tried disabling Bluetooth yet, I can imagine it might also transition to Unknown then.)