Estimote + PushCuts question

Hi all,

Just got a set of Estimote beacons and believe I have them all configured. The problem is it seems that my phone doesn’t respond to being near my iBeacon consistently unless I open the Estimote app and tap on the Beacon Details section (then PushCut triggers a notification).

Has this happened to anyone? Any suggestions?

Teddy

  • Can you share any screenshots of what you have configured for the settings of the iBeacon and the configuration in PushCut?
  • Do you have the location services set as “Always” for PushCut?

Thanks @sylumer! Images below, from both the Estimote app and Pushcut. Happy to share any additional info that would be helpful.

They look okay at first glance.

But by location services settings for PushCut I didn’t mean the location settings in the app, but the OS level settings like this:

Yep! I’ve got it set to Always as well (apologies for not including that too).

It does seem like adding a background web task is causing some of the problem, because I’ll sometimes get a notification that a background action failed to run when leaving my iBeacon.

Okay, so what if you try triggering something else to validate if that is the case? Maybe just fire a shortcut to open a particular app for example.

Also, maybe try increasing the transmit power a little. Maybe it’s currently so low as to be suffering too much from interference and attenuation from things around and close by. A bit of a boost could make it more reliable if that were the case, or you could try it in a open space.

Try the things in each paragraph above independently so as to narrow it down should one prove to change the behaviour consistently.

two thoughts from my side:

I know that iOS gets a bit sceptical if it sees beacons turn on and off right next to it (for testing/initial setup). my experience was that after too much “unreliability” iOS will ignore the beacon completely for a while. maybe you were in a phase like this? when I messed around too much with beacon signals, restarting the iOS device made everything work again…

about the error: is it possible that you do not have a good internet connection when the beacon event occurs? does the “background action failed” notification give you an error description in this direction?

Thanks to you both. I will try each suggestion when getting to work tomorrow. I have a suspicion that there’s some kind of WiFi dead spot when I leave my office which would explain why the trigger fails when leaving but not when entering.

I really like using a background action (as opposed to notification) because it can pull a currently running timer from Toggl and present info about it in the notification that it ultimately triggers. Still, if it’s more reliable to stick to notifications (at least as I get this figured out) I’ll do that.

Thanks again,
Teddy

Hey all - hopping on with a slightly different issue.

I have three Estimate beacons configured, just like @tedsvo above. All three are in different physical locations, miles apart. They seem to be working consistently. But when I enter or leave the area of one beacon, and my pushcut notification is triggered, I then also get pushcut notifications from the actions of the other two beacons. And sometimes I randomly get two pushcut notifications (from those same beacon local triggers) when I’m not near any of the beacons.

My location settings are set to Always. Anyone experience the same?

not sure if this is related, but I did find an issue a few days ago that might have caused glitchy notification scheduling.

could you try, with the latest version of Pushcut, to open each local trigger and:

  • turn enabled to off
  • save
  • turn enabled to on
  • save

This should re-create all the behind the scenes stuff, and this time without potentially weird race-conditions. My apologies if that is what caused your trouble… software sometimes just ain’t behavin’…

also, you might want to try setting newly generated, separate UUIDs for your beacons - could be a total myth, but I had one user report that setting “fresh” UUIDs fixed all their problems with “phantom triggers”.

1 Like

Thanks for the hands-on support. Okay, I’ve turned them all off and back on. If that doesn’t work, I’ll change the UUIDs and report back!

1 Like

Shoot, no luck. I’ll try to change the UUIDs later today!

Reporting back - so, interestingly, changing the UUIDs did seem to work. I don’t know why, but thank you for the suggestion.

What I’m noticing now, and I think this was always the case, is that Pushcut doesn’t seem to “catch” the iBeacons when a good bit of time has past, until I do something to “remind” the phone. To explain:

If I play with the beacons in the Estimate app, all is good. But a day or two later, I am no longer getting Pushcut Notifications from the iBeacon related Local Triggers. If I open the Estimate app, suddenly I will get a pushcut notification. What was interesting - today, I noticed I was not getting any notifications (beacon related), so I opened up the Eddystone scanner app on my phone, and as soon as I opened that app up, I received a Pushcut notification for arriving near the iBeacon that is sitting right next to me.

I wonder if there’s an issue with my phone, not with Pushcut? FYI, I have restarted Pushcut and restarted the phone multiple times!

1 Like

I am having similar lossy experience with iBeacons and Pushcut. I have not tried your Estimote cure (yet), but I have observed that the behavior is swingy… works a bunch… then stops a bunch. TY for the extra insight(s).

I am hoping Apple eTags come out at the next Apple product rollout, and that they provide reliable (and more localized, controllable) location triggers. The iBeacons seem too powerful even on their lowest (-40dB) setting, IMO. Great if you need range, but not great when you want triggers limited to a single (e.g.) room or small space.

Just wanted to mention that I use the RadBeacon iBeacon. Looks like a small usb mouse dongle and stays plugged in all the time. It has worked very reliably for me in triggering notifications when first picking up signal.