Geofencing trouble (MOVED)

Plugins & Plugin Development Reactor
#1

Patrick,

I’ve recently had issues with Vera recognizing my location. I use Reactor for my geofence rules, primarily because I have an override switch that will disable the auto away mode for when there are guests staying.

It has worked flawlessly for months, but the past two nights it was not seeing my location (at least when I view the conditions in reactor). On the iOS app, it shows my pin inside the radius for home which I made rather large at 1250 m. Location is always on and settings are correct.

Please see the logic summary of my “auto away mode” RS, followed by a dummy RS that I set up to see if it recognizes that I am currently at work-in the iOS app, I created the geofence by using my location, naming it WORK.

I figured I’d ask you to see if there is a chance that Reactor could be the root of the problem since now Vera Support is very unhelpful.

INSTRUCTIONS: When pasting this report into the Vera Community forums, please include ALL lines below this one. The next and last lines will ensure proper formatting and must not be removed!

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 90
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1559646516; systemReady 1559646534; Lua 5.1
Local time: 2019-06-04T08:06:12-0400; DST=1
House mode: plugin 2; system 2; tracking on
  Sun data: { "stamp": 2019155, "civdawn": 1559639000, "nautdawn": 1559636340, "sunset": 1559695677, "nautdusk": 1559700407, "latitude": 42.7678, "astrodusk": 1559703611, "longitude": -78.6134, "civdusk": 1559697747, "astrodawn": 1559633136, "sunrise": 1559641070 }
  Geofence: running in long mode, last update 07:58:00, data version 2
            User 2464412 ishome=0 inlist= since=07:58:00
            |1559649381 "WORK" type="other" status="" since=07:57:00
            |1552711693 "HOME" type="home" status="" since=07:58:00
            Raw: { "updated": 1559649960, "users_settings": [ { "id": 2464412, "ishome": 0 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [ { "radius": 1250, "PK_User": 2464412, "color": "ff0000", "accuracy": 0, "ishome": 1, "name": "HOME", "address": "Strykersville, United States", "longitude": "-78.42427907211773", "latitude": "42.6970652287167", "id": 1552711693, "notify": 0 }, { "radius": 1250, "notify": 0, "color": "2c4eff", "accuracy": 0, "ishome": 0, "name": "WORK", "address": "Favor St, Attica, United States", "longitude": "-78.27419062152345", "latitude": "42.86152915101765", "id": 1559649381, "PK_User": 2464412 } ], "iduser": 2464412 } ] }
     Power: utility, battery level 93
====================================================================================================================================
AUTO AWAY MODE (#251) tripped
    Version 19082.4 06/04/19 06:37:18
    Message/status: Tripped
    Condition group "AUTO AWAY MODE" (OR) TRUE as of 07:42:54 <root>
      |-T-group "grpbi4hujw" (AND) TRUE as of 07:42:54 <grpbi4hujw>
      |     &-?-comment "When Auto Security Switch is on and Derek leaves geo fencen& not in vacation mode: SWITCH TO AWAY MODE" <condbi4hujx>
      |     &-T-ishome is not 2464412 [ => 2464412 at 20:05:04; T/T as of 20:05:04/20:05:04] <condbi4jbpn>
      |     &-T-service AUTO SECURITY SWITCH (229) urn:upnp-org:serviceId:SwitchPower1/Status = 1 [0 => 1 at 07:42:54; T/T as of 07:42:54/07:42:54] <condbi4jxd6>
      |     &-T-housemode in 1,2,3 [1 => 2 at 07:13:52; T/T as of 04-03.20:47:36/04-03.20:47:36] <condbi4nnh6>
      |-F-group "grpbvlhczp" (AND) false as of 08:00:15 <grpbvlhczp>
      |     &-?-comment "DOUBLE CHECK EVERY HOUR" <condbvlhczq>
      |     &-T-ishome is not 2464412 [ => 2464412 at 20:05:04; T/T as of 20:05:04/20:05:04] <condbvli077>
      |     &-T-service AUTO SECURITY SWITCH (229) urn:upnp-org:serviceId:SwitchPower1/Status = 1 [0 => 1 at 07:42:54; T/T as of 07:42:54/07:42:54] <condbvli89v>
      |     &-T-housemode in 1,2,3 [1 => 2 at 07:13:52; T/T as of 04-13.07:00:54/04-13.07:00:54] <condbvljcoc>
      |     &-F-interval { "type": "interval", "mins": 0, "id": "condbvljhz8", "hours": 1, "days": 0 } [1559646000 => 1559649600 at 08:00:00; F/F as of 08:00:15/08:00:15] <condbvljhz8>
    Activity root.false
        Change house mode to 1
    Activity root.true
        Change house mode to 2
    Events
        06/04/19 07:08:49 start: 
        06/04/19 07:13:51 devicewatch: name=REACTOR PLUGIN, var=HouseMode, device=90
        06/04/19 07:42:53 devicewatch: device=229, old="0", name=AUTO SECURITY SWITCH, var=urn:upnp-org:serviceId:SwitchPower1/Status, new="1"
        06/04/19 07:42:54 condchange: newState=true, cond=condbi4jxd6, oldState=false
        06/04/19 07:42:54 evalchange: newState=true, cond=condbi4jxd6, oldState=false
        06/04/19 07:42:54 condchange: newState=true, cond=grpbi4hujw, oldState=false
        06/04/19 07:42:54 evalchange: newState=true, cond=grpbi4hujw, oldState=false
        06/04/19 07:42:54 condchange: newState=true, cond=condbvli89v, oldState=false
        06/04/19 07:42:54 evalchange: newState=true, cond=condbvli89v, oldState=false
        06/04/19 07:42:54 condchange: newState=true, cond=root, oldState=false
        06/04/19 07:42:54 evalchange: newState=true, cond=root, oldState=false
        06/04/19 07:42:54 sensorstate: state=true
        06/04/19 07:42:54 startscene: scene=root.true, sceneName=tripactions
        06/04/19 07:42:54 runscene: scene=root.true, sceneName=tripactions, group=1, notice=Starting scene group 1
        06/04/19 07:42:54 endscene: scene=root.true, sceneName=tripactions
        06/04/19 07:57:03 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 07:58:03 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 08:00:00 condchange: newState=true, cond=condbvljhz8, oldState=false
        06/04/19 08:00:00 evalchange: newState=true, cond=condbvljhz8, oldState=false
        06/04/19 08:00:00 condchange: newState=true, cond=grpbvlhczp, oldState=false
        06/04/19 08:00:00 evalchange: newState=true, cond=grpbvlhczp, oldState=false
        06/04/19 08:00:15 condchange: newState=false, cond=condbvljhz8, oldState=true
        06/04/19 08:00:15 evalchange: newState=false, cond=condbvljhz8, oldState=true
        06/04/19 08:00:15 condchange: newState=false, cond=grpbvlhczp, oldState=true
        06/04/19 08:00:15 evalchange: newState=false, cond=grpbvlhczp, oldState=true

INSTRUCTIONS: When pasting this report into the Vera Community forums, please include ALL lines below this one. The next and last lines will ensure proper formatting and must not be removed!

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 90
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1559646516; systemReady 1559646534; Lua 5.1
Local time: 2019-06-04T08:09:09-0400; DST=1
House mode: plugin 2; system 2; tracking on
  Sun data: { "stamp": 2019155, "civdawn": 1559639000, "nautdawn": 1559636340, "sunset": 1559695677, "nautdusk": 1559700407, "latitude": 42.7678, "astrodusk": 1559703611, "longitude": -78.6134, "civdusk": 1559697747, "astrodawn": 1559633136, "sunrise": 1559641070 }
  Geofence: running in long mode, last update 07:58:00, data version 2
            User 2464412 ishome=0 inlist= since=07:58:00
            |1559649381 "WORK" type="other" status="" since=07:57:00
            |1552711693 "HOME" type="home" status="" since=07:58:00
            Raw: { "updated": 1559650140, "users_settings": [ { "id": 2464412, "ishome": 0 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [ { "radius": 1250, "PK_User": 2464412, "color": "ff0000", "accuracy": 0, "ishome": 1, "name": "HOME", "address": "Strykersville, United States", "longitude": "-78.42427907211773", "latitude": "42.6970652287167", "id": 1552711693, "notify": 0 }, { "radius": 1250, "notify": 0, "color": "2c4eff", "accuracy": 0, "ishome": 0, "name": "WORK", "address": "Favor St, Attica, United States", "longitude": "-78.27419062152345", "latitude": "42.86152915101765", "id": 1559649381, "PK_User": 2464412 } ], "iduser": 2464412 } ] }
     Power: utility, battery level 93
====================================================================================================================================
Reactor Sensor 20 (#292)
    Version 19082.8 06/04/19 07:58:18
    Message/status: Not tripped
    Condition group "Reactor Sensor 20" (AND) false as of 21:23:05 <root>
      &-F-ishome is 2464412 [ at 06:31:25; F/F as of 06:31:25/06:31:25] <conddxve31y>
      &-F-ishome at 2464412,1552711693 [out =>  at 07:58:04; F/F as of 07:05:37/07:05:37] <conddxwlny8>
      &-T-ishome is not 2464412 [2464412 at 07:05:37; T/T as of 07:05:37/07:05:37] <conddxwlgtk>
      &-F-ishome notat 2464412,1552711693 [out =>  at 07:58:04; F/F as of 07:58:04/07:58:04] <conddxwlyjs>
      &-F-ishome at 2464412,1559649381 [ at 07:58:19; F/F as of 07:58:19/07:58:19] <conddxyhgyu>
      &-F-ishome notat 2464412,1559649381 [ at 07:58:19; F/F as of 07:58:19/07:58:19] <conddxyhsbr>
    Events
        06/04/19 07:08:49 start: 
        06/04/19 07:57:03 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 07:58:03 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 07:58:04 condchange: newState=false, cond=conddxwlyjs, oldState=true
        06/04/19 07:58:04 evalchange: newState=false, cond=conddxwlyjs, oldState=true
        06/04/19 07:58:18 configchange: 
        06/04/19 07:58:19 condchange: newState=false, cond=conddxyhgyu
        06/04/19 07:58:19 evalchange: newState=false, cond=conddxyhgyu
        06/04/19 07:58:19 condchange: newState=false, cond=conddxyhsbr
        06/04/19 07:58:19 evalchange: newState=false, cond=conddxyhsbr
        06/04/19 07:58:39 action: action=Reset
        06/04/19 07:58:39 sensorstate: state=false
        06/04/19 07:58:46 action: action=Reset
        06/04/19 07:58:46 sensorstate: state=false
        06/04/19 08:00:17 action: action=Reset
        06/04/19 08:00:17 sensorstate: state=false
Using Reactor to Trigger House Modes (or other) based on Geofence(s) et al
#2

OK. This is an opportunity for me to help everyone learn how to decode some of the mysteries in the Logic Summary. The summaries are pretty light on formatting for humans because they’re really intended for my consumption, but there’s no reason anybody can’t figure out what’s in them. So, let’s study the geofencing bits a bit…

Geofence: running in long mode, last update 07:58:00, data version 2

This line starts the geofencing section and tells me that the geofence task is running in “long” mode, meaning that somewhere is a condition using a condition to test if a user is in a specific location, rather than simply “at home”. The geofencing task has two options when examining Vera’s data: the “short” option, which is used when only “is home” conditions are used, allows the geofence to only examine a very small part of the user_data where there’s a specific flag for that. The “long” option is used when “is at” conditions for testing specific locations other than home are used, and requires the retrieval and parsing of all of the configured geotags (locations) and an examination of those flags–it takes longer, much longer, actually, so Reactor attempts to optimize for the simple case when possible.

After this header comes the interpretation of the user_data per-user, which includes the “ishome” flag for the user:

User 2464412 ishome=0 inlist= since=07:58:00

The “ishome” flag is set on the user when Vera indicates that the user is in the geotag (location) marked as the “home” location. Your configuration apparently contains only one user that uses geofencing, and that user is marked not home (ishome=0) in Reactor’s interpretation.

Then comes the data for the individual geotags (locations), because we are in long mode:

|1559649381 "WORK" type="other" status="" since=07:57:00
|1552711693 "HOME" type="home" status="" since=07:58:00

Here we see there are two geotags defined. The “HOME” geotag is marked as the home location. The “WORK” geotag is an “other” location (currently, all geotags that aren’t “home” are “other”). Suspicious, though, is that there’s no status data. We would expect to see a status of either “in” or “out” for each location. But let’s move on.

If we pause here, we can plainly see that Reactor thinks that user 2464412 is not at home, based on its interpretation of Vera’s user_data data. That leaves the question… where’s the bug? Because if you know you’re home, and your phone location shows you at home, Vera should say you are home, and Reactor should agree. Why doesn’t it? And why isn’t there a status in Reactor’s data for the “HOME” geotag?

The last line in the geofencing section of the Logic Summary contains the raw data from Vera’s user_data that was used in the interpretation of results–the Vera data that Reactor used to build its data structures that we reviewed above. Let’s look at that…

Raw: { "updated": 1559650140, "users_settings": [ { "id": 2464412, "ishome": 0 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [ { "radius": 1250, "PK_User": 2464412, "color": "ff0000", "accuracy": 0, "ishome": 1, "name": "HOME", "address": "Strykersville, United States", "longitude": "***", "latitude": "***", "id": 1552711693, "notify": 0 }, { "radius": 1250, "notify": 0, "color": "2c4eff", "accuracy": 0, "ishome": 0, "name": "WORK", "address": "Favor St, Attica, United States", "longitude": "***", "latitude": "***", "id": 1559649381, "PK_User": 2464412 } ], "iduser": 2464412 } ] }

That’s hard to look at. Let’s “pretty print” it.

{
	"users": [{
		"id": 2464412,
		"Level": 1,
		"Name": "derekkirsch",
		"IsGuest": 0
	}],
	"users_settings": [{
		"id": 2464412,
		"ishome": 0
	}],
	"usergeofences": [{
		"geotags": [{
			"radius": 1250,
			"PK_User": 2464412,
			"color": "ff0000",
			"accuracy": 0,
			"ishome": 1,
			"name": "HOME",
			"address": "Strykersville, United States",
			"longitude": "***",
			"latitude": "***",
			"id": 1552711693,
			"notify": 0
		}, {
			"radius": 1250,
			"notify": 0,
			"color": "2c4eff",
			"accuracy": 0,
			"ishome": 0,
			"name": "WORK",
			"address": "Favor St, Attica, United States",
			"longitude": "***",
			"latitude": "***",
			"id": 1559649381,
			"PK_User": 2464412
		}],
		"iduser": 2464412
	}]
}

That’s better. I’ve also removed the updated (time) and mode keys from the data that are Reactor’s additions, so what we see left here are the parts of user_data, copied directly from it, that Reactor used to interpret the geofence state.

In the first section, users, we see the list of users configured, and that’s only one. Reactor only uses this section to get the user’s name.

In the second section, users_settings, we see that our one user is marked “not home” in Vera’s user_data.

In the third section, usergeofences, we see each of the configured locations, and specifically the geotag with the name “HOME”, we can see has ishome=1, but in this data structure that does not mean the user is home, it means that that geotag is the “home” location. If the user was in that geotag, it would have a status key with “enter” as the value… that key does not exist in either geotag. There’s no status for either geotag at all, and that’s… weird. The only time I see no status at all is when a geotag is brand new and it has been neither entered nor exited yet. An active location will usually have either “enter” or “exit”, signalling the most recent transition for that boundary.

So, based on examination of user_data in two different data structures, Vera’s data is not marking you home. At a minimum, we would expect users_settings to have ishome=1, and that’s all that is needed for your short-form conditions (is home/is not home). We would also like to see the “HOME” geotag have a (raw) status of “enter” (which would show as “in” in Reactor’s data structure), and the “WORK” geotag have a status of “exit” in user_data (which would be shown as “out” in Reactor’s result).

Now one thing before holding Vera’s feet to the fire… if you’ve been editing your geotags/locations and playing around and trying to get it work and pushing and pulling and what not… Vera seems to only change the state of geotags and users at the time of a transition–that is, at the time you cross into a goefence boundary or leave it. If you create a location that you are located in right this minute, in my observations, Vera will not update the state of that location until you leave it–it does not mark you in it right away (even though it could and probably should). You have to traverse the boundary to start getting status updated. That discovery caused me a lot of hair-pulling when I first started testing this stuff. So if you’ve reconfigured your locations as part of your attempts to figure out why they are not working immediately as expected, you can actually make the problem worse, and you need to let everything settle down, then go take a walk or drive to get out of, and back into, each location. And know that any time you create a location, it’s not going to work properly until you get that first traversal.

EDIT: The ID of your “WORK” location suggests it was created two minutes before this report. That may be enough to upset the apple cart. It certainly explains why that geotag has no status. Is it possible that when you created it, you accidentally marked it as the “home” location, and then fixed that? Or edited the radius of the home location? Either could disrupt the HOME data as well, and send everything back to square one.

In a separate thread, @Sorin also mentioned that the networking team has been doing some work of late, and this also can, of course, affect the response times for geofencing. I’ve also seen updates be missed altogether, for various reasons (I’m an Android user, and there are settings on Android that a user can easily and unwittingly enable that will quickly hobble geofencing into oblivion).

#3

Just confirmed that, at least when using the Android app, editing just the name of a location is sufficient to wipe out its status.

#4

Patrick,

You are correct that I just created the “WORK” location this morning from the office. As you can see from the logic summary below, it now recognizes that I am at work. (I drove out and back into the radius).

So back to my issue I experienced last night, could it just have been a fluke that it did not see me enter and I didn’t give it enough time before I started messing with the Geofencing? Because you guessed correct, as soon as I saw that reactor show that I was not home, I started editing my Home radius.

I did however give it significant time to recognize I was home before I dove into my settings- Every now and then when I get home Vera will not have recognized my entrance to the geofence (which again is 1250 m). So I’ll go on the iOS app and manually change the house mode to “home”. At that time, my RS triggers will occur, unlocking doors, turning on lights, ect. I just shrug it off that there was some lag with the geofence.

However, last night it never updated because my “hourly check” on the auto away RS reset my home mode to away and triggered the motion alarms. The second hour it did it is when I started messing with geofencing. But as you stated, I never left and reentered the geofence.

It does give me some resolution that Vera sees that I am at “WORK” so we’ll see what happens this evening. I’ll keep you posted.

Thanks

INSTRUCTIONS: When pasting this report into the Vera Community forums, please include ALL lines below this one. The next and last lines will ensure proper formatting and must not be removed!

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 90
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1559646516; systemReady 1559646534; Lua 5.1
Local time: 2019-06-04T12:49:20-0400; DST=1
House mode: plugin 2; system 2; tracking on
  Sun data: { "stamp": 2019155, "civdawn": 1559639000, "nautdawn": 1559636340, "sunset": 1559695677, "nautdusk": 1559700407, "latitude": 42.7678, "astrodusk": 1559703611, "longitude": -78.6134, "civdusk": 1559697747, "astrodawn": 1559633136, "sunrise": 1559641070 }
  Geofence: running in long mode, last update 12:36:00, data version 2
            User 2464412 ishome=0 inlist=1559649381 since=12:36:00
            |1559649381 "WORK" type="other" status="in" since=12:36:00
            |1552711693 "HOME" type="home" status="" since=07:58:00
            Raw: { "updated": 1559666940, "users_settings": [ { "id": 2464412, "ishome": 0 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [ { "radius": 1250, "accuracy": 0, "id": 1552711693, "PK_User": 2464412, "ishome": 1, "name": "HOME", "address": "Strykersville, United States", "longitude": "-78.42427907211773", "latitude": "42.6970652287167", "color": "ff0000", "notify": 0 }, { "radius": 1250, "PK_User": 2464412, "id": 1559649381, "status": "Enter", "color": "2c4eff", "ishome": 0, "name": "WORK", "address": "Favor St, Attica, United States", "longitude": "-78.27419062152345", "latitude": "42.86152915101765", "notify": 0, "accuracy": 0 } ], "iduser": 2464412 } ] }
     Power: utility, battery level 92
====================================================================================================================================
Reactor Sensor 20 (#292)
    Version 19082.8 06/04/19 07:58:18
    Message/status: Not tripped
    Condition group "Reactor Sensor 20" (AND) false as of 21:23:05 <root>
      &-F-ishome is 2464412 [ at 06:31:25; F/F as of 06:31:25/06:31:25] <conddxve31y>
      &-F-ishome at 2464412,1552711693 [out =>  at 07:58:04; F/F as of 07:05:37/07:05:37] <conddxwlny8>
      &-T-ishome is not 2464412 [2464412 at 07:05:37; T/T as of 07:05:37/07:05:37] <conddxwlgtk>
      &-F-ishome notat 2464412,1552711693 [out =>  at 07:58:04; F/F as of 07:58:04/07:58:04] <conddxwlyjs>
      &-T-ishome at 2464412,1559649381 [out => in at 12:36:05; T/T as of 12:36:05/12:36:05] <conddxyhgyu>
      &-F-ishome notat 2464412,1559649381 [out => in at 12:36:05; F/F as of 12:36:05/12:36:05] <conddxyhsbr>
    Events
        06/04/19 07:08:49 start: 
        06/04/19 07:57:03 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 07:58:03 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 07:58:04 condchange: newState=false, cond=conddxwlyjs, oldState=true
        06/04/19 07:58:04 evalchange: newState=false, cond=conddxwlyjs, oldState=true
        06/04/19 07:58:18 configchange: 
        06/04/19 07:58:19 condchange: newState=false, cond=conddxyhgyu
        06/04/19 07:58:19 evalchange: newState=false, cond=conddxyhgyu
        06/04/19 07:58:19 condchange: newState=false, cond=conddxyhsbr
        06/04/19 07:58:19 evalchange: newState=false, cond=conddxyhsbr
        06/04/19 07:58:39 action: action=Reset
        06/04/19 07:58:39 sensorstate: state=false
        06/04/19 07:58:46 action: action=Reset
        06/04/19 07:58:46 sensorstate: state=false
        06/04/19 08:00:17 action: action=Reset
        06/04/19 08:00:17 sensorstate: state=false
        06/04/19 08:15:19 action: action=Restart
        06/04/19 08:15:19 start: 
        06/04/19 08:24:11 action: action=Restart
        06/04/19 08:24:11 start: 
        06/04/19 08:24:15 action: action=Restart
        06/04/19 08:24:15 start: 
        06/04/19 08:24:20 action: action=Reset
        06/04/19 08:24:20 sensorstate: state=false
        06/04/19 12:35:04 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 12:35:05 condchange: newState=true, cond=conddxyhsbr, oldState=false
        06/04/19 12:35:05 evalchange: newState=true, cond=conddxyhsbr, oldState=false
        06/04/19 12:36:04 devicewatch: name=REACTOR PLUGIN, var=IsHome, device=90
        06/04/19 12:36:05 condchange: newState=true, cond=conddxyhgyu, oldState=false
        06/04/19 12:36:05 evalchange: newState=true, cond=conddxyhgyu, oldState=false
        06/04/19 12:36:05 condchange: newState=false, cond=conddxyhsbr, oldState=true
        06/04/19 12:36:05 evalchange: newState=false, cond=conddxyhsbr, oldState=true
#5

Everything worked as it should and normally does coming home.

So what I’ve learned is that if I experience an issue with geofencing, the solution is to exit the radius and reenter. Do not start messing with the geofence locations.

I know having scheduled code to basically poll the location of the device would add extra loading, but maybe have that option in a “refresh” command. It seems strange that even when viewing the location in the “geofence map” that it would not update the user location in Vera.

Regardless, thank you for your time and explanation. Also, awesome work with the Reactor update! I really like the updated interface.

#6

Since the genesis of the problem on the Vera side is the app/phone-Vera link not updating the Vera’s data, there’s no amount of refreshing that could address that. It is only when the app/phone finally gets the data to Vera’s servers and those servers update your Vera’s userdata that either the Vera on its own or Reactor could respond accurately and timely.

If it makes you feel better to add an Interval condition for periodic checks, that’s fine, but from my point view, and that of Reactor, it isn’t necessary. Reactor is ultra-efficient at detecting and managing change; it lives for change; it pounces on change. All by design. In this case, I’m certain you could remove your Interval condition and you’d see no difference whatsoever in performance or operation of your ReactorSensor. The intent of the Interval condition is to drive an action that needs to be repeated periodically, such as sending a notification of a door left open, not a repetition of tests on conditions.

#7

Not sure if this is helpful, but my solution to guests is to use a virtual switch (VS). I turn it on manually and my PLEG logic looks for that VS as well as the 2 iPhone VS’s to all be false (all are gone) to switch to Away mode. Similarly, if both iPhones are more then 100 miles away, it switches to Vacation mode. If we have a guest, and we manually set the guest VS on, then the mode stays on Home or Night, depending on the time of day.

#8

That is exactly what I have set up with using reactor. At least when I assume you are referring to geofence when you say iPhone VS. It basically allows you to disable an automatic home mode change with the use of a virtual switch. Which reactor handles flawlessly. The problem I expirenced was Vera did not see my phone enter the geofence so my Reactor sensor did not execute changing home modes.

Funny you bring that up. I added this “double check” condition after the exact opposite scenario occurred. I was at work and happened to check the vera app and noticed I was still in Home mode. Assuming that it was reactor that missed me leaving the geofence I added the interval condition. I realize now that it was Vera that missed the change, not Reactor.

A side thought- would it better to leave the “work” location with my geofence settings? If it is the entering and exiting of the geofence that triggers Vera updates, wouldn’t having multiple geofence locations force updating?

#9

In the current (Vera) implementation as we understand it, this may be right. The problem, however, may simply be that whatever causes one update to be delayed (or missed) may befall others. It has gotten a lot better in the last year, but still not quite there. But I think the more chances you give it to do the “right” thing, the better off you may end up.

#10

Sorry, I should have explained I have never gotten geofencing to work in Vera and I have used iPhone Locator with great success for many years.

#11

Just switched to using iPhone locator instead of geofencing. I’ve grown tired of Vera missing the location.

#12

I’m using it now as well. Still misses a few updates, though :frowning:
C

#13

Is there an equivalent app (to iPhone Locator) for Android phones? The Vera geofencing function is just not reliable.

Thanks!

#14

I found the big issue with Geofence is when the phone goes to sleep so does the the GPS (at least it does on my phone) and then it is hit or miss when entering and exiting the geofence… I found an app that keeps the GPS active when the phone sleeps. GPS keeper for android and when in use I find that Geofence works consistently as it should. Battery life is impacted but not too bad.

#15

Thanks - I’ll try that app.

But not holding my breath…

#16

Just curious, did you have any issues with Geofencing while you were also running a navigation app? I’m guessing no since the GPS would stay active.

#17

Never ran waze or any other Navigation app. My phone is ancient. Need to upgrade at some point.

#18

I have a Pixel 3a, and I run a couple of navigation apps quite frequently, nearly every time I leave the home fence. My experience is that the Vera app occasionally, say one time in 5 to 8, fails to register my return home, or decides that I am not home when I haven’t actually left home. I have only one fence, Home.

The performance of the Vera app is worse than using Life 360 with IFTTT, which I have also done for a long time. I don’t want to use IFTTT anymore, because it is just too cumbersome, and also somewhat unreliable.

#19

Slightly off topic, but does anyone know why Reactor sees my wife as a number and myself as a name in reactor geofence user selection criteria. Just set it up if that makes any difference and her phone has not left the geofence yet.

#20

If it’s still an issue, PM me just the “Geofences” section of your Logic Summary.