Geofencing issue

Looking for help on geofencing set up.

I set up Vera to turn on my lights when I get home and added to do it only after dark.

However it turns on any time I pull up to the house.

What am I doing wrong?


In this case, two different triggers in the same scene won’t work in the manner you expect here. It takes any of the triggers independently.

What you want to achieve might be possible with some additional help from plugins like Reactor

I can’t test it and I’m not sure if it works, but I think this is how this automation might look. Maybe @rigpapa can confirm.

Sorin, this is a great start! One thing, though… the first two conditions should be placed into their own subgroup. Otherwise, the AND condition on the root group will not be met as expected (because the “Always run before sunset” group will also be part of the AND and thus must be true for the ReactorSensor to trip).

Once that’s done, the root group should be an “OR”, and the activity to run the scene only needs to be done when the root group goes TRUE (so just one action in one activity needed)…

  • Group root – OR
    • Group “Run scene after 5pm in geofence” – AND
      • Date/time after 17:00
      • Geofence user is home (or in a selected geotag) – +option after the date/time cond
    • Group “Always run before sunset” – AND
      • Sunrise/sunset condition, before sunset with offset

Activity – root.TRUE – run the scene

Note that with the “after” condition option restriction on the geofence condition, the condition is only met if the user enters the geofence after 5pm. This will not run the scene if the user is already in the geofence when 5pm arrives. If the desire is to get the scene to run at 5pm when the user is home (in fence), then the “after” option/restriction should be removed.

Also, in your geofence condition, you need to select a geotag/location. I would suggest using the “is home” geofence condition method if that’s applicable, as it’s a faster test and requires a lot less processing (Edward has solved the hefty processing problem for me in a future for release, but for the moment, it’s still a thing).

1 Like

I have done exactly this using reactor, day and night plugin and iPhone locator. We know the inbuilt geofencing has issues. Unless it really has been fixed in the latest iOS version


On Android 9, I have 100% reliability on exit, but only getting 50% success rate on enter, especially after my phone has been dormant for a while when I am on the road. My geofence area is like 900m. I have turned off battery optimization and I am using maximum performance. Not sure what else I can try, any suggestions?

I’ve been after Sorin a good bit about the geofencing issues in the Vera Mobile apps, and in a separate effort, I also undertook creating an alternative that a few people are testing now based on commonly-available location/GPS apps for iOS and Android. (Yes, I’m aware of iPhone Locator, but where’s Android Locator?)

Much has been learned, and suffice it to say, geofencing is a tricky business technically, and now complicated by geopolitical/legal issues. The principal issues I now understand to be this:

  1. On Android, phone manufacturers can and do customize the OS on a per-phone basis. Obviously, they optimize for battery life as a priority, so they often choose to kill or suspend background processes. Most manufacturers have a way to disable this for selected apps, requiring permissions from user in most cases (thus relying on the user to understand that permission is necessary for consistent operation and grant it when asked–this sometimes doesn’t happen). In some cases, notably some Huawei phones, they kill background apps and there is no workaround/disable provided, so it’s simply not possible on those devices. These behaviors can and often do change from version to version of the phone OS, so an upgrade can at any time take a working scenario and turn it into a non-working one, sometimes permanenetly. The upshot is that the success of the app on Android is highly dependent on a combination of the user’s sufficient, clear understanding of the phone’s settings and permissions combined with adequate support and performance available from the OS, and neither is consistent, creating mixed results and support nightmares.
  2. Also on Android, newer OS’s that do allow background apps to source location data continuously are now required to post a permanent notification so that the user is aware that location data is being shared. Some users “don’t like this.” Nothing can be done about it, and in fact, I believe it’s the right thing to do.
  3. Apple/iOS fares better than Android in the geofencing stability world, largely because of the uniformity of the OS across devices. However, there are occasional lapses in location performance that often place the user at a great distance from their actual location (happens on Android as well, though less often–this is believed to be an effect of both systems using cell tower and wifi location data to correlate/triangulate, and the loss of a tower, for example, can suddenly result in large shifts of position that don’t quickly correct). But the net performance on Apple devices is, predictably, more consistent than Android. Apple iOS 13 introduces new privacy features, presumably in support of GDPR compliance, that routinely announce to the user that location data is being shared and requesting ongoing permission (seems to be an analogue to Android’s mandatory notification mentioned above, although Android requires no activity on the part of the user to maintain ongoing permission… yet).
  4. GDPR clouds (no pun intended) both the requirements and the desirability of having this feature at all. It’s a huge compliance (and liability) hurdle for a solo developer of a community plugin/feature, so at the moment, my plan is that if I release this as a product to the world, it will not be available in any location where its users expect to be protected by GDPR (and if other countries adopt it or similar laws in future that represent similar hurdles, they will be eliminated as well). The liability simply far outweighs the effort and return.

So, I have a functioning geofencing system with a supporting Vera plugin and web site for management and control. It is not meant to be a replacement for Vera’s, but rather an alternative. However, I am weighing the viability of releasing it publicly, because of both the technical issues above and the non-technical (GDPR, liability, etc.) issues. On the plus side, though, the majority of users testing it right now seem to be successful most of the time. It also supports multiple phone apps and methods, so the chances of finding a combination of tools that works is, perhaps, greater. But there are just too many variables and reliance on too many moving parts for geofencing to ever be 100% reliable, IMO; but perhaps 90%, or 95%, or even 99% is achievable, and I want to try.

If you’d like to test my prototype system, drop me a note via PM with your full legal name, real email address and your home country (if you are in a GDPR-protected country, please don’t request, I won’t approve). It’s still a work in progress, so be ready for some nasty configuration (long URLs, API keys), and of course, it’s strictly “as-is” (worth every penny you pay for it, as they say), but I’m really interested in doing whatever I can do understand and solve as many problems in this area as possible.


Very insightful post. Kudos to Patrick.

For having attempted a few things with Android I concur with the difficulties. It is facing the same issue on mobile as windows did (and to some degree still is) on PCs to support a large base of hardware and vendors so in order to do so, the platform is having to make a lot of compromise for customization, stability and security. iOS on the other hand is much more controlled and uniform and… much greater in quality of apps. Just try publishing an app on both platforms and you will see what I mean. For these reasons, I don’t believe you can ever have a reliable and consistent solution over the long term on Android unlike iOS. For these reasons and combined with the other behaviors I am observing from google, I have been gradually getting rid of Android (and everything google related). The most unreliable devices in the house? Both run Android device which can’t be updated because they are highly customized by their manufacturers which abandoned their update support a few months after release.

1 Like

When it works Ezlo should Buy it from you implement it directly into Vera. Then they can take the GDPR problems…

Keep up the good work!

/ GDPRslave from Sweden😂

1 Like

Do you by chance use the Alexa app on Android? You can set up “routines” which can include scene/device commands using the Vera skill, and you can have those routines triggered by the location of your cell phone entering or exiting a circle you define. I have found the Alexa app to be 100% reliable on GeoFencing over the last couple of months that I have been using location triggered routines.

I was getting about 50% reliability using the Vera app, and very low reliability on Vera Proximity.

I set up routines to Leave and Arrive. For Leave I have an action that runs a scene using the house modes plugin to change the mode to Away and for Arrive i have an action that runs a scene to change the mode to Home. When I play the Leave routine it works as expected changing from Home to Away but when I play the Arrive routine it wont change back to Home. I know the scene works because I can tell Alexa to turn Home on and it will. Can’t figure out why it wont work when I play the Arrive routine.

So if I understand … you have a scene on Vera that uses House Modes plug-in to change to Home. You have the Alexa routine “turn on” this scene, and the routine has a location trigger. And if you manually play the Alexa scene – either by saying “Turn On (scene name”) or by clicking the “Play” button on the routine in the Alexa app, it does NOT change to Home.

If you trigger that scene directly on the Vera, does it change to Home mode?

You’re just using one mobile device, right? The location triggered routines are triggered only by the device where you created them, NOT across all devices on your account like any other routine.

Perhaps this will help you debug, from my experiences fighting with Vera app and Vera Proximity:

In each routine I have that is location triggered, in addition to the Vera command, I have Alexa say “Entering Inner GeoFence” or whatever is appropriate on my phone. Then in the Vera scene that I have to process GeoFencing (I avoid all but a few plug-ins and I do everything myself in Lua), it will send a text to my phone that says “Entered Inner GeoFence” or whatever is appropriate. That way, if there’s a breakdown somewhere in the communication path, I can localize where it was.

I’ve had some “learning events” with the House Modes plug in. If you set the mode with the plug in, there is a small delay before the Vera house mode actually changes. Similarly, if the house mode changes on Vera independent of the plug in, there will be a bigger delay before House Modes plug in sees it.

So you can get into some unexpected behavior when in a scene you’re using both Vera’s house mode and house mode as reported by the plug in. For example, if you have the scene trigger on the House Mode app and you have house modes as a qualifier for the scene to run.

I do my GeoFencing with three virtual switches on Vera that I created (not through any plug in, just by using “Create Device” and a little custom XML file) – one for my Inner GeoFence (about 150 yards from home), Middle GeoFence (4 miles), and Outer GeoFence (50 miles). Then I use the change in state of those switches to trigger my scene in Vera that figures out what to do. If the location triggered routine ever doesn’t execute for some reason, I can always tell my Echo Auto something like “Alexa, turn on Inner GeoFence” and Vera will take it from there.

1 Like

I used to use an iOS app called skylark to set my nests to home / away which would then be used to trigger the Vera home / away functions.

This app was 100% reliable running on my wife and I’s phone’s. unfortunately the dev wasn’t able to cover his costs From app sales alone and shutdown the service.

Since then I’m using iPhone locator which is also very reliable but requires a lot more manual config and tweaking.

It’d be great if Vera bought Patrick’s solution (assuming it’s also rock solid) from him and baked it into the Vera app’s.

Thank you All for your input!!!

I am a newbie with this so trying to make the most from it!

Rigpapa great videos thank you! They got me here so far.

Didn’t test it out yet so not sure if it will work lol

Looks like a good start, logic-wise. This is how you do it. Small step. Then another. And another…

Vera’s native integration doesn’t run when house mode is away or vacation. I took a look at their code.

DeAmelia - I removed the Home scene, created a Nite scene with the House Modes plug-in and added that to the Arrive routine and it worked. So then I removed the Nite scene and put back the original Home scene to the routine and now it’s working! Tried running the routine a few times going back and forth between Leave and Arrive with no issues. Have no idea why it’s working now. Also tried it out a couple times actually leaving and arriving to make sure it triggers correctly and all seems good. Time will tell as far as reliability.

Glad you got it working @packman

© 2019 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy