webCoRE mobile app - iOS Source Code


My inner radius for example means I can’t drive past the house without triggering current place… and the outer radius covers several surrounding roads.


Yes, this is the same issue I have.

I can get horizontalAccuracy down to 10M. If I can shrink the circles and make them tighter, I believe the false triggers will go away. I truly like the location capabilities, It’s just not manageable with the current restrictions.


And you think that tweeking the diameter of the outer ring is going to solve any of that? If it does, I’ll be the first to admit I was wrong but I think even if it solves those problems it’s going to cause others.


Where is this? I am looking through the code in the smartapps, but can’t find it.

You did find the correct place though :smile:


You’re able to have 10m accuracy all the time? Remember, you don’t just have to look at arriving and leaving…you need to think of staying home as well. If things happen when you leave home, you don’t want them to trigger all the time out of nowhere.


I have considered that as well. I would just like to experiment with my geo fence sizes and go from there. I understand it is at my own risk.


It’s not in any of the smartapps, it’s in the dashboard JS file I linked to above.


So where/how would I make the changes locally?


you would need to host the webcore dashboard (website) locally on a server, using the various JS modules etc. shared on GitHub… I wouldn’t have a clue myself!!!

Then you would still have the problem with the mobile app pointing towards webcore.co instead of your local address.

Gonna need to be addressed by the webCoRE team but from what I understand there has been tonnes of issues with smaller radius’s, loads of questions from disgruntled users and lots of repeating ourselves (telling users to make their radius bigger)… so unlikely the change will happen.


Understand. I also see disgruntled people that are having all kinds of piston cancelling issues and, “false”, arriving/departing notifications.

When you get these, the pistons are cancelling because it gets an arrival followed a split second later by a departure.

From a practical sense I cannot see how 250M is reasonable for anyone in a city. I live in a suburb and these fences are way too big for normal roads. What is worse is, the DH will not allow me to filter the arrivals/departures out when I have my horizontalAccuracy set super low (10M). I get the arrivingAt triggering 100-150M away even though my arrival geofence is 50M. If I could at least truly filter those out, maybe these absurdly large geo fence requirements could work.

Seeing there won’t be any further support on this, I will start changing all my pistons back to presence and not arrivingAt/DepartingFrom as this is not usable at this point. I use these to open/close my garage door and it is important it is at least closing.

Overall this is pretty disappointing since this is really a great idea. I would like to at least have the option to change some of these at your own risk, take the feedback and make the appropriate changes that works best.


So I assume this is a dead end and there will be no assistance on this? :disappointed:


The smaller zones will make it so that i am not driving in/out/in of the geo-fence.

The current geo-fence on arrival is 2 blocks from my house and overlaps roads.


I don’t think the min radius is going to get changed any time soon… but on testing further I’m getting reliable notifications only when entering the under zone and exiting the outer zone… so driving past the outer zone now has no effect.

Can you post your piston?


So have you made changes to the application or are you handling this in your pistion?


Piston… please post what you are using.


Here you go:

What happens is 2 things:

  1. When the Departure geo-fence is momentarily crossed, the piston gets executed, then executed a split second later, which cancels the piston.

  2. We both have presence sensors in our phones and they trigger somethings (when we leave/arrive together) a split second apart from each other and produce the same issue above, where the piston that is trggered had not finshed yet, thus cancelling it.


Why don’t you have it trigger when you’ve been gone for a period of time…say a minute or even 30 seconds. That should get you away from the threshold you keep hitting.


Not sure how to write that.

Also, would it solve the piston cancelling if it was triggered again before it could complete (one current issue).


The first trigger would never happen until you hit the time so it shouldn’t run twice. Instead of selecting changes to just select “stays”.


I made the modifications and will see how that behaves.

Thank you.