Problem with reactor sensor detecting geofence and home mode

Hi, Patrick!

I’ve been trying to fix automatic home mode detection for a while. Yesterday I thought I had everything covered and working, with both geofencing and pingsensor detecting our phones connected to the home network. However, when I go into the reactorsensor to look today, the geofencing is false when at home. I’ve been trying to go into the Vera Mobile app to see if the geofence is right, which it is, and postioning on my phone is turned on, but still the geofence won’t update.

I hope you can help me trying to understand why the geofence won’t update (I’ve read the latest geofence post, but still need some explanation).

Some of the words in the logic summary are in Norwegian, and hope that’s OK.

EDIT: Here I am sitting at home, and suddenly it just changes house mode from home to away, even when the reactor is true on “Kenneth hjemme”. I really don’t understand this…

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.3 config 19178 cdata 19082 ui 19195 pluginDevice 92
    System: Vera version 1.7.4453 on Sercomm G450; loadtime 1564462002; systemReady 1564462018; Lua 5.1
Local time: 2019-07-30T14:08:18+0000; DST=0; ### Norway
House mode: plugin 2; system 2; tracking on
  Sun data: { "stamp": 2019211, "civdawn": 1564451202, "nautdawn": null, "sunset": 1564516348, "nautdusk": null, "latitude": 60, "astrodusk": null, "longitude": 11, "civdusk": 1564520107, "astrodawn": null, "sunrise": 1564454960 }
  Geofence: running in long mode, last update 13:59:00, data version 2
            User 2326741 ishome=0 inlist= since=13:59:00
            |    1 "Hjemme" type="home" status="" since=13:59:00
            User 2538182 ishome=0 inlist= since=13:59:00
            |    1 "Home" type="home" status="out" since=07:35:00
            Raw: { "updated": 1564495684, "users_settings": [ { "id": 2326741, "ishome": 0 }, { "id": 2538182, "ishome": 0 } ], "mode": -1, "users": [ { "id": 2326741, "Level": 1, "Name": "kenmyh", "IsGuest": 0 }, { "id": 2538182, "Level": 1, "Name": "marthemyhre", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [ { "radius": 250, "accuracy": 0, "id": 1, "color": "006e45", "ishome": 1, "name": "Hjemme", "address": "###", "longitude": "11", "latitude": "60", "PK_User": 2326741, "notify": 1 } ], "iduser": 2326741 }, { "geotags": [ { "radius": 250, "accuracy": 0, "id": 1, "status": "Exit", "color": "006e45", "ishome": 1, "name": "Home", "address": "###", "longitude": "11", "latitude": "60", "PK_User": 2538182, "notify": 0 } ], "iduser": 2538182 } ] }
====================================================================================================================================
Hjemmedeteksjon (#226)
    Version 19082.14 07/29/19 15:02:41
    Message/status: Not tripped
    Condition group "Reactor Sensor 19" (OR) false as of 14:07:34 <root>
      |-F-group "Kenneth hjemme" (OR) false as of 14:07:34 <grpg1f522n>
      |     |-F-ishome is 2326741,2538182 [2538182 =>  at 07:35:02; F/F as of 07:35:02/07:35:02] <cond0>
      |     |-F-ishome at 2326741,1 [out =>  at 13:59:02; F/F as of 04:04:02/04:04:02] <condfx0pwoy>
      |     |-F-service Kenneth tlf (227) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 [1 => 0 at 14:07:34; F/F as of 14:07:34/14:07:34] <condg37b66e>
      |-F-group "Marthe hjemme" (OR) false as of 07:35:02 <grpg1f59gl>
      |     |-F-ishome is 2326741,2538182 [2538182 =>  at 07:35:02; F/F as of 07:35:02/07:35:02] <condg4qaklx>
      |     |-F-ishome at 2538182,1 [in => out at 07:35:02; F/F as of 07:35:02/07:35:02] <condg3804cv>
      |     |-F-service Marthe tlf (228) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 [1 => 0 at 07:31:49; F/F as of 07:31:49/07:31:49] <condg37sbtp>
    Activity root.false
        Change house mode to 2
    Activity grpg1f59gl.true
        Change house mode to 1
    Activity grpg1f522n.true
        Change house mode to 1
    Events
        07/30/19 13:06:24 runscene: scene=grpg1f522n.true, sceneName=grpg1f522n.true, group=1, notice=Starting scene group 1
        07/30/19 13:06:24 endscene: scene=grpg1f522n.true, sceneName=grpg1f522n.true
        07/30/19 13:06:24 sensorstate: state=true
        07/30/19 13:21:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/30/19 13:21:34 condchange: newState=false, cond=condg37b66e, oldState=true
        07/30/19 13:21:34 evalchange: newState=false, cond=condg37b66e, oldState=true
        07/30/19 13:21:34 condchange: newState=false, cond=grpg1f522n, oldState=true
        07/30/19 13:21:34 evalchange: newState=false, cond=grpg1f522n, oldState=true
        07/30/19 13:21:34 condchange: newState=false, cond=root, oldState=true
        07/30/19 13:21:34 evalchange: newState=false, cond=root, oldState=true
        07/30/19 13:21:34 sensorstate: state=false
        07/30/19 13:21:34 startscene: scene=root.false, sceneName=root.false
        07/30/19 13:21:34 runscene: scene=root.false, sceneName=root.false, group=1, notice=Starting scene group 1
        07/30/19 13:21:34 endscene: scene=root.false, sceneName=root.false
        07/30/19 13:21:54 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/30/19 13:21:54 condchange: newState=true, cond=condg37b66e, oldState=false
        07/30/19 13:21:54 evalchange: newState=true, cond=condg37b66e, oldState=false
        07/30/19 13:21:54 condchange: newState=true, cond=grpg1f522n, oldState=false
        07/30/19 13:21:54 evalchange: newState=true, cond=grpg1f522n, oldState=false
        07/30/19 13:21:54 condchange: newState=true, cond=root, oldState=false
        07/30/19 13:21:54 evalchange: newState=true, cond=root, oldState=false
        07/30/19 13:21:54 startscene: scene=grpg1f522n.true, sceneName=grpg1f522n.true
        07/30/19 13:21:54 runscene: scene=grpg1f522n.true, sceneName=grpg1f522n.true, group=1, notice=Starting scene group 1
        07/30/19 13:21:54 endscene: scene=grpg1f522n.true, sceneName=grpg1f522n.true
        07/30/19 13:21:54 sensorstate: state=true
        07/30/19 13:46:30 action: action=Trip
        07/30/19 13:46:30 sensorstate: state=true
        07/30/19 13:59:02 devicewatch: name=Reactor, var=IsHome, device=92
        07/30/19 13:59:06 action: action=Restart
        07/30/19 13:59:06 start: 
        07/30/19 13:59:13 action: action=Restart
        07/30/19 13:59:13 start: 
        07/30/19 13:59:21 action: action=Reset
        07/30/19 13:59:21 sensorstate: state=false
        07/30/19 13:59:21 startscene: scene=root.false, sceneName=root.false
        07/30/19 13:59:21 runscene: scene=root.false, sceneName=root.false, group=1, notice=Starting scene group 1
        07/30/19 13:59:21 endscene: scene=root.false, sceneName=root.false
        07/30/19 13:59:27 action: action=Trip
        07/30/19 13:59:27 sensorstate: state=true
        07/30/19 14:07:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/30/19 14:07:34 condchange: newState=false, cond=condg37b66e, oldState=true
        07/30/19 14:07:34 evalchange: newState=false, cond=condg37b66e, oldState=true
        07/30/19 14:07:34 condchange: newState=false, cond=grpg1f522n, oldState=true
        07/30/19 14:07:34 evalchange: newState=false, cond=grpg1f522n, oldState=true
        07/30/19 14:07:34 condchange: newState=false, cond=root, oldState=true
        07/30/19 14:07:34 evalchange: newState=false, cond=root, oldState=true
        07/30/19 14:07:34 sensorstate: state=false
        07/30/19 14:07:34 startscene: scene=root.false, sceneName=root.false
        07/30/19 14:07:34 runscene: scene=root.false, sceneName=root.false, group=1, notice=Starting scene group 1
        07/30/19 14:07:34 endscene: scene=root.false, sceneName=root.false
    Devices
        Marthe tlf (228) urn:schemas-demo-ted-striker:device:PingSensor:1 (0/-1); parent 0; plugin 1228
        Kenneth tlf (227) urn:schemas-demo-ted-striker:device:PingSensor:1 (0/-1); parent 0; plugin 1228

OK, so this may be a side effect of you trying several different things, but here are some issues:

  1. You are using both the regular is-home test and the specific location test. If you only need the is-home test, just use that exclusively, as the specific location test requires considerably more processing of data from the Vera. Functionally it won’t matter, but it saves some cycles on your Vera if you really only need the simpler “is home” test. Reason: Vera has a specific flag on the user record for when you are at the location marked as home, so the individual locations do not need to be examined (that latter part requiring additional processing).
  2. If they are new geofences, they don’t work until you first traverse the geofence boundary. This is a bug that has been reported here: https://community.getvera.com/t/geotag-locations-do-not-update-when-created-or-edited/208863
  3. If they are not new, you may have tried to edit your geofences, maybe adjust location, radius or name. ANYTHING you do to the geofence configuration on your phone WIPES the current location status from the Vera servers, and it will not update until you traverse the geofence boundary. It can be something as simple as modifying the name of the location by one character, or even not modifying it and hitting the save button. Whatever you do, it effs everything up until you traverse the geofence. It’s an annoying side-effect that Vera really, really needs to fix. I’ve already reported this as a bug: https://community.getvera.com/t/trivial-editing-of-geofence-location-clears-data-android-poss-ios/208862

The “raw” section of the geofence data in the Logic Summary is the subset taken from user_data for the geofence, without any interpretation or modification by the plugin–it’s shown here so I can see what Reactor thinks it got from Vera in order to determine status. The raw data shows Vera servers have no status data at all for the home location for user 2326741 (Kenneth)–typical of what happens when the geofence location is first created or is edited on the mobile device. The geofence location data for user 2538182’s home location currently shows status “exit”–the user is not inside the boundary according to Vera.

1 Like

Thanks for the amazing reply! I’ve changed my reactor to only use the is-home function. What is the pros n cons on the different options?

I’ll see tomorrow how it reacts to coming home from work again, and enter the geofence.

When the wife got home, I checked if vera and reactor sensed it, but it still says she is away, and condition is false. I have not changed anything on her phone since I added her geofence yesterday.

This is how my reactor currently looks. And we both are home. My geofence is changed today so probably why it’s not updated, but hers is not changed since it was created (and she gas exited and entered the geofence since it was created)

Thanks for the help so far!

Please post the Logic Summary again. I’m pretty sure it’s going to tell me that your Vera’s user_data still shows her out, but let’s have a look anyway. You might also look at what the Vera app on her phone thinks is going on (don’t edit anything, just look).

Also, if she (and you) are on Android, make sure the Vera app is configured so it isn’t put to sleep when it goes into the background, and that power saving mode is off. Basically, in my experience, your phone needs everything Vera to be fully permitted and running 100% of the time, or your geofences aren’t going to work.

Unfortunately, Vera’s geofencing has been hit or miss for most users, and mostly miss at that. It’s just too fragile (still). Reactor can only respond to the data it gets from your Vera. GIGO.

I feel like the problem is the app, even though it has all premissions… I’m using the notify function in the app to tell me if I enter/exit the geofence, and it seems like the apps not updating if I’m not opening it a few times a week.

However, after I changed the geofence yesterday evening, I got at notification about exiting the geofence on my way to work, so that seems to work, at least for now. But I’m still wondering why it’s not updating my wifes status to home…

Here is the latest Logic Summary after I left the geofence this morning.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.3 config 19178 cdata 19082 ui 19195 pluginDevice 92
    System: Vera version 1.7.4453 on Sercomm G450; loadtime 1564496373; systemReady 1564462018; Lua 5.1
Local time: 2019-07-31T05:44:18+0000; DST=0; ### Norway
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019212, "civdawn": 1564537794, "nautdawn": null, "sunset": 1564602604, "nautdusk": null, "latitude": 60, "astrodusk": null, "longitude": 11, "civdusk": 1564606311, "astrodawn": null, "sunrise": 1564541500 }
  Geofence: running in long mode, last update 04:03:00, data version 2
            User 2326741 ishome=0 inlist= since=04:03:00
            |    1 "Hjemme" type="home" status="out" since=04:03:00
            User 2538182 ishome=0 inlist= since=04:03:00
            |    1 "Home" type="home" status="out" since=07:35:00
            Raw: { "updated": 1564551840, "users_settings": [ { "id": 2326741, "ishome": 0 }, { "id": 2538182, "ishome": 0 } ], "mode": -1, "users": [ { "id": 2326741, "Level": 1, "Name": "kenmyh", "IsGuest": 0 }, { "id": 2538182, "Level": 1, "Name": "marthemyhre", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [ { "radius": 250, "accuracy": 0, "id": 1, "status": "Exit", "color": "006e45", "ishome": 1, "name": "Hjemme", "address": "###", "longitude": "11", "latitude": "60", "PK_User": 2326741, "notify": 1 } ], "iduser": 2326741 }, { "geotags": [ { "radius": 250, "accuracy": 0, "id": 1, "status": "Exit", "color": "006e45", "ishome": 1, "name": "Home", "address": "###", "longitude": "11", "latitude": "60", "PK_User": 2538182, "notify": 0 } ], "iduser": 2538182 } ] }
====================================================================================================================================
Hjemmedeteksjon (#226)
    Version 19082.23 07/30/19 21:26:40
    Message/status: Not tripped
    Condition group "Reactor Sensor 19" (OR) false as of 04:01:04 <root>
      |-F-group "Kenneth hjemme" (OR) false as of 04:01:04 <grpg1f522n>
      |     |-F-ishome is 2326741 [2538182 =>  at 07:35:02; F/F as of 07:35:02/07:35:02] <cond0>
      |     |-F-group "grpg65hcdo" (NOT AND) false as of 04:01:04 <grpg65hcdo>
      |     |     &-T-service Kenneth tlf (227) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 0 for ge 120s [1 => 0 at 03:59:04; T/T as of 03:59:04/04:01:04] <condg65hfqu>
      |-F-group "Marthe hjemme" (OR) false as of 21:28:41 <grpg1f59gl>
      |     |-F-ishome is 2538182 [2538182 =>  at 07:35:02; F/F as of 07:35:02/07:35:02] <condg4qaklx>
      |     |-F-group "grpg6jfpzr" (NOT AND) false as of 21:28:41 <grpg6jfpzr>
      |     |     &-T-service Marthe tlf (228) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 0 for ge 120s [1 => 0 at 18:25:19; T/T as of 21:26:41/21:28:41] <condg37sbtp>
    Activity root.false
        Change house mode to 2
    Activity grpg1f59gl.true
        Change house mode to 1
    Activity grpg1f522n.true
        Change house mode to 1
    Events
        07/31/19 01:00:04 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 01:00:04 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 01:00:24 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 01:00:24 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 01:01:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 01:01:34 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 01:01:54 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 01:01:54 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 01:11:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 01:11:34 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 01:12:54 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 01:12:54 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 02:31:04 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 02:31:04 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 02:31:24 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 02:31:24 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 02:42:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 02:42:34 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 02:42:54 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 02:42:54 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 02:58:04 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 02:58:04 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 02:58:24 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 02:58:24 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 03:11:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 03:11:34 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 03:11:55 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 03:11:55 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 03:15:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 03:15:34 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 03:15:54 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 03:15:54 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 03:16:34 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 03:16:34 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 03:16:54 devicewatch: device=227, old="0", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        07/31/19 03:16:54 condchange: newState=false, cond=condg65hfqu, oldState=true
        07/31/19 03:59:04 devicewatch: device=227, old="1", name=Kenneth tlf, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        07/31/19 03:59:04 condchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 04:01:04 evalchange: newState=true, cond=condg65hfqu, oldState=false
        07/31/19 04:01:04 condchange: newState=false, cond=grpg65hcdo, oldState=true
        07/31/19 04:01:04 evalchange: newState=false, cond=grpg65hcdo, oldState=true
        07/31/19 04:01:04 condchange: newState=false, cond=grpg1f522n, oldState=true
        07/31/19 04:01:04 evalchange: newState=false, cond=grpg1f522n, oldState=true
        07/31/19 04:01:04 condchange: newState=false, cond=root, oldState=true
        07/31/19 04:01:04 evalchange: newState=false, cond=root, oldState=true
        07/31/19 04:01:04 sensorstate: state=false
        07/31/19 04:01:04 startscene: scene=root.false, sceneName=root.false
        07/31/19 04:01:04 runscene: scene=root.false, sceneName=root.false, group=1, notice=Starting scene group 1
        07/31/19 04:01:04 endscene: scene=root.false, sceneName=root.false
        07/31/19 04:03:02 devicewatch: name=Reactor, var=IsHome, device=92
    Devices
        Marthe tlf (228) urn:schemas-demo-ted-striker:device:PingSensor:1 (0/-1); parent 0; plugin 1228
        Kenneth tlf (227) urn:schemas-demo-ted-striker:device:PingSensor:1 (0/-1); parent 0; plugin 1228

The raw Vera data in this summary shows the Vera reporting “exit” status on both users’ locations.

I’m not sure what else to suggest, other than carefully checking all the app and phone settings.

Okay, thanks!

I’ve been running some tests and it seems like the geofencing is to unstable to use. It doesn’t recoginice when we exit or enter the geofence. My guess is that the android app is the problem. As soon as it is opened and closed again the geofencing works for 1-3 days, then it f-s up. It also seems that it works better on my phone than my wifes.

I think I need to find a better solution for detecting that we are home, because the geofence is to unstable.

Thanks anyway for the excellent help!

If you have any suggestions for detecting home mode etc, feel free to share them :slight_smile:

I had the same issue with Vera’s geofence being unreliable. It wasn’t everytime I left entered/exited the geofence but it was enough to notice and get aggravated when house modes wouldn’t change. I used iPhone locator for awhile with success, but I didn’t want to purchase and API key so errors were always displayed. I also noticed a significant battery draw on my phone even when changing the polling settings.

What I’ve been doing lately is using geofence but with 3 different radius’ around the house. The one at 500m is the “Home” trigger, but there is another at 1000m and 1500m,

As Patrick explains, the way vera sees the change is when you cross the geofence, so this way you’re waking the controller before you reach your home geofence. I’m not sure if it really helps or not, but I haven’t had any issues in 3 weeks using it this way.

Also know that I’m working in the background with @Sorin trying to get more attention to reliability issues with geofencing. Suffice it to say that Vera/eZLO engineering is pretty busy right now, but I will keep this on this their radar.

2 Likes

I will try the same. Just made 2 new fences, and a test condition in reactor. Thanks for the tips!

I too have seen reliability issues with geofencing. I have two iPhones one is a 6 and the other an SE. The SE seems to work much more reliably than the 6. Background app refresh is not enabled on either phone. I have noticed that if I open the Vera app and let it update before I leave or before I enter the geofence it seems to work more reliably.
Support looked at my logs and if I remember correctly they said the controller was missing the event they could see the event on the server but for some reason the update never made it to the controller.

And were they going to dig in to figure out why that might be?

I have a long chain of e-mails but this was on of the more recent ones. It seems from this response that its the server missing the event or not returning the response to the controller in a timely fashion causing a timeout on the controller.I guess it’s possible by expanding the radius of the geofence it gives more time to establish the handshake much the way opening the application does?

Vera support response:
As described, the user and timings were right and the event did happen, here is the sample from the log:

05/11/19 10:48:25.903 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: SetGeoFence
05/11/19 10:48:25.904 JobHandler_LuaUPnP::HandleActionRequest argument action=SetGeoFence
05/11/19 10:48:25.905 JobHandler_LuaUPnP::SetGeofence user: 1234567 isenter 0 id 1234567890 device 00000000 ishome 1

Now, regarding the other user, do you login with any of your users of any of your mobile devices?

This could cause other users to glitch our and stopped responding to server calls, but to be honest this is extremely hard to test and it’s not documented in our bug tracker as something major, it’s rather trivial, this means that occurrence and impact is low.

Controller side, events seem to be generated, but Server Side sometimes they are skipped or the controller does not get feedback in time so those requests timeout.

This issue was reported, our team is working into fixing this accuracy issue, meanwhile you should try to clean your device, remove the app from your device, unassign your account from the controller and then re-add it (use the WEB UI for this operation), this should refresh the user information and all the tokens generated upon assignation.

Thank you. Have a good day!


They also mentioned that they’ve had something similar to what I mentioned about having the app open on an iPhone happen with the Android version but that was apparently resolved with the Android version.

Vera support response:
Thank you for the feedback. We’ve been aware of this for a while on the Android and since the Android update, the Geofence seems to be more reliable for Android users.

I’m pretty sure that the iOS update will bring updates for Geofenceing and also improvements.

Thank you. Have a good day!