Arrival/departure if/then or case statement?

#80

So seeing the delays are working, how would I adapt to achieve the following status updates?

@bangali helped on this before, but the delays would not work. Maybe this can be the base since the delays are working now?

If we are both change currentPlace changes away from “House” --> Location Mode = Both Away
If I am home and GF is not Location Mode = I am home
If GF is home and I am not Location Mode = She is home

If we are both change currentPlace changes to “House” --> Location Mode = Both Home
If I am home and GF is not Location Mode = I am home
If GF is home and I am not Location Mode = She is home

image
image.png1178×1994 264 KB

#81

Could I ask what the final piston looked like?

#82

have you tried this? does that not work?

#83

Are you saying instead of currentPlace changes to --> current Place?

Not sure of you have seen some of my other posts, but the presence app is triggering, ‘false’, arrival/departure events on the edges of the geo fences. So what happens based on my logs is the piston will trigger for arrival, then before the piston can complete, it is triggered again, cancelling everything. What I need to do is ignore these split second triggers and only truly trigger the piston if our current location stays house, cabin, gym, for a set period of time. I could then adjust that time as needed.

There truly is a problem with the core presence app, but no one will believe me about these false triggers. I have captured them in my log files.

#84

share the logs please.

#85
#86

thanks. that looks like the wC presence app is doing what it should. but the phone geo-location updates when using gps only has its own shortcomings and sends incorrect geo-location updates when in certain locations.

is that what you meant?

#87

To a certain point, yes.

What I was told by ady was that the DH for the presence sensor could filter out the GPS updates from the phone:

image

So what I tried was to copy the DH and I changed the horizontalAccuracy to something super low like 10M. Hoping that all the GPS updates lower than that would be filtered out and ignored (not triggering arrivingAt/DepartingFrom). This was not the case. Nothing really changed other than I see in the logs that, “Low accuracy of XXm prevented updates to presence.” The prescens events mentioned above were still happening. If you look at my map, I cannot make the geo fences smaller so I tried what I thought was the next best thing, filter out low accuracy.

If you do the math on this, the limitations are 50M arrival and a maximum smallest departure of 250M. In all reality, I am getting updates on the geo fence side 350M + from when I need them (250M+ 100M horizontal accuracy since the code above really is not limiting or filtering anything from what I have seen).

A typical city block is 80M × 274M. So even if everything worked perfect. On the short side of a block you would be triggering events up to 4 blocks away.

Through the logs, I can consistently get under 20M GPS accuracy. In fact, I typically can get 10M. So why can’t the geo fences be smaller? The only real response I get is that, “this has been tested and anything smaller is giving false alarms.” My Arlo geo fences are a single geo fence and they work just fine. The standard ST geo fence is a single geo fence and it is a lot more accurate than the precense senor.

So here I am masking the issue by making a piston disregard false triggers rather than addressing the root cause :smile:

Sorry this is wordy, but no one seems to be listening to me on this. I love the idea of these multiple locations, but how can anyone use them reliably? I live in a pretty spread out area. I can’t imagine the difficulties someone in a condensed city would have with this.

#90

in the device settings for the presence sensor can you please turn on debugging then open live logging and drive around in the area where these false updates happen and post the logs for the presence device.

#91

That’s in the link that I sent you :smile:

Those were live logs via debug.

image
image.png1841×660 60.4 KB

How much time would you like?

#92

Here is what I have. I am still using my custom DH set to filter out both processPlace and processLocation if the accuracy is less than 15M

image
image.png1216×1573 144 KB

image
image.png1476×359 49.1 KB

I drove completely around the block and here is what I found in the events for the device.

  1. Since the geo fence was broken, see measurements in the map, my location was updated briefly and then changed back. You can see that on the first update, the logs state that low accuracy of 24M was recorded and filtered, but still it updated my location. I think that shows that the DH is not truly filtering out low accuracy GPS readings. Also my arrival radius is set to 50M. The location marked as #1 is 97.7M (50M + 46.7M) away.

image
image.png3741×1936 682 KB

  1. In this case, the same basically happened. I arrived at house when the accuracy was 24M (greater than 15M and logs state they were filtered out). At this point I am actually 114.89M away (64.89M + 50M). Same arrival geo fence (50M). This is marked on the map with #2.

image
image.png3761×1173 332 KB

Map

image
image.jpg709×574 70.4 KB

What happens as I was trying to explain is 2 things.

  1. Pistons for arrivingAt/departingFrom get triggers before they finish and cancel.
  2. The app actually gets, ‘stuck’, for a while typically in arrivingAt and doesn’t update the location. It does on the first trigger (which is truly false). If that first false trigger and update never happened, life would be good :smile:
#93

thanks for all the great data. let me look thru and get back to you.

#94

so from looking at the data the location updates with low horizontal accuracy are getting filtered out as they should. however that does not control presence it only affects the location updates and distance calculation.

presence seems to be controlled by the geofence updates. so when the outer geofence is entered the presence changes to present/arrived and when the inner geofence is exited the presence changes to not present/left.

unfortunately there is no way to assess the accuracy of the geofence update and filtering the low accuracy horizontal updates do not help with presence fluttering.

updating the piston to filter out these momentary presence changes might be the way to go.

EDIT: just thinking aloud wondering if it would have worked better if the geo-fence circles were reversed. the inner circle entry would be for present/arrival and the outer circle exit would be not present/left. that might reduce the probability of this kind of fluttering.

#96

From my logs, you can see that I get consistant accuracy under 25M for sure.

This is exactly why I have been asking on the ST forum if we can make the geo fences configurable. Someone sent me the code (js in the dashboard).

The issue is getting someone on board to change it. I just am asking that it be configurable at your own risk.

#97

Did you try the possible solution I posted on your other thread?

#98

ahh it was biting man himself. :slight_smile: hadnt seen that thread before. you are in good hands with @Robin so i am just going to turn it over back to him from here.

#99

I did and it did not work.

Can you look at the logs I have above? I don’t see how this will fix the pistons cancelling.

Also, all the other users that are having these issues.

#100

If you tried my reccomendation, please post your piston.

Elements cancelling can usually be fixed with TCP and TEP.

#101

So @bangali agrees there is something wrong with the app. Can we please try to address that rather than compensate for it in a piston?

My logs show that there’s an actual issue. If we can’t fix the root cause, every one else will have issues too.

#105

I honestly give up on any hope of fixing the problem…

Here is my piston that cancels because of the false triggers. How would I modify it?

image
image.png1178×1994 236 KB