Latitude and longitude in piston

#1

1) Give a description of the problem
Piston is not working…

2) What is the expected behaviour?
When latitude and longitude enters range then…

3) What is happening/not happening?
Not firing…

4) Image

image
image.png930×513 16.8 KB

5) Attach logs after turning logging level to Full

13.10.2020 klo 6.29.54 +858ms
+1ms ╔Received event [XXXXXXXXXXX].longitude = 25.103691 with a delay of 51ms
+58ms ║RunTime Analysis CS > 21ms > PS > 20ms > PE > 17ms > CE
+61ms ║Runtime (42361 bytes) successfully initialized in 20ms (v0.3.110.20191009) (58ms)
+62ms ║╔Execution stage started
+70ms ║║Comparison (decimal) 25.103691 enters_range (decimal) 25.099 … (decimal) 25.107 = false (1ms)
+72ms ║║Condition #38 evaluated false (6ms)
+73ms ║║Condition group #37 evaluated false (state did not change) (7ms)
+82ms ║║Comparison (decimal) 25.103691 stays_outside_of_range (decimal) 25.099 … (decimal) 25.107 = false (2ms)
+84ms ║║Cancelling any timed trigger schedules for condition 27
+85ms ║║Cancelling statement #27’s schedules…
+86ms ║║Condition #27 evaluated false (9ms)
+87ms ║║Condition group #26 evaluated false (state did not change) (11ms)
+89ms ║╚Execution stage complete. (27ms)
+90ms ╚Event processed successfully (90ms)

Any idea why 25.103691 is not in range?
+70ms ║║Comparison (decimal) 25.103691 enters_range (decimal) 25.099 .. (decimal) 25.107 = false (1ms)

This is weird though. It says 25.103691 is not outside…
+82ms ║║Comparison (decimal) 25.103691 stays_outside_of_range (decimal) 25.099 .. (decimal) 25.107 = false (2ms)

#2

Interesting… I’ve never seen longitude used as a trigger before…

Normally, the trigger “ENTERS RANGE OF” has to trigger twice… Once outside the range (where nothing happens), and then once inside… (essentially “entering” the range, and taking action)

I am curious… What are you monitoring?
(what device is changing latitudes?)

#3

As far as the “STAY” trigger… I would place this one in a piston that is only triggering off of the same attribute. (IE: longitude) Otherwise, the latitude changing can break that timer

#4

I’m having issues with multiple location tracking. I’m using life360 and it reports users latitude and longitude. I’m adding area with latitude and longitude. When user arrives to location it should notify.

I’m not sure what is causing this. I had another piston that I tested yesterday and it worked. Location was not same and I’m wondering if there is something with decimals in lat and long that webcore can’t understand.

#5

I’m trying to handle that problem by using variable. First part fires only when variable is “true”. Second part fires when variable is “false”.

#6

I have done math in webCoRE (daily) using 21 decimals… but I have seen it go as far as 24.

The log shows them all as decimals… So that’s good.

I honestly think the answers are in my last two posts.
(IE: Don’t use “STAY” with two different triggers in the same piston)

#7

Ok. I’m going to test it. Let’s see what happens. :slight_smile:

#8

Honestly, this is a common misconception in webCoRE…

Whether or not the variable is true",

  • Every change to longitude… and
  • Every change to latitude

will start the piston all over at the top, and run thru the entire code, top to bottom… Executing anything not blocked by conditions… and possibly resetting any timers that “no longer apply”.

#9

Well I have made a LOT of misconceptions… :smiley: but I’m learning…slowly…

Even though it starts piston again every time when lat or long changes does it matter? I mean I do not have timers in my piston so it basically checks in condition matches including variable and if not it checks another condition. So is it a problem only when using timers in pistons or is there other things I should be aware of?

#10

Don’t feel bad. It is the “STAY” that is peculiar… It can be powerful, but definitely peculiar.

I have learned to keep only single triggers in pistons with “STAY” timers.
(or double triggers IF they are both using the same attribute)

In a nutshell… If anything else triggers a piston during the countdown of the STAY, the end results are reliably unreliable… :grin:

Edit:

I guess the way I look at “STAY” internally is,
IF X (stays static and untouched) Y for Z minutes

I am wondering if multiple triggers, all within range, may break the “STAY” timer.
(normally, nothing should trigger during the timer)

#11

Thanks. I found that problem was those two “enters range” conditions. :face_with_raised_eyebrow: I changed them “is inside of range” and piston started to work. I need to think this again based on what you wrote. It could be better to separate my need to few more pistons.

#12

This makes for a great condition… You could even structure something like this:

If latitude changes         <-- Trigger
   or
   longitude changes        <-- Trigger
Then
   IF lat is between W & X  <-- Condition
      and
      lon is between Y & Z  <-- Condition
   Then
      Do cool stuff
   END IF
END IF

Pro Tip:

If this piston is tied to GPS, you can expect it to run thousands of times a day. I would take great care to make the code as streamlined as possible… (IE: it will fire a hundred times while you are asleep, and much more frequently when awake)

#13

One more food for thought…

If life360 allows for geo-fences,

  • it would be more accurate (circles vs squares)
  • with less code (one data point coming into webCoRE vs two)
#14

Well that is the problem. Life360 has gone really bad in last two months. It changes location even though device is not moving. It happens many times per hour. In last two hours it seems that my device left home circle for 9 times. User leaves so called circle and arrives back to it in couple of minutes. When using life360 geo-fences in pistons it fires them many times per day and can’t be used.

At the same time latitude and longitude information stays accurate (same…even though location circle changes). There is some big technical issues in life360 at the moment which makes circles impossible to use. That’s why I’m rebuilding my pistons by using latitude and longitude. I know…circle would be so much better and easier but what can you do… I’m so happy that we have webcore. Life would ■■■■ without it.

#15

The true irony is… with today’s current technology, we can practically guarantee that GPS will bounce all day… every day… (even if the device hasn’t moved an inch)

This is true for all consumer devices, regardless of manufacturer.

So, if the latitude/longitude square in Life360 “stays accurate … even though location circle changes”, then that means either
(A) It is not timely reporting what GPS coords are actually seen… or
(B) It has additional software/programming in place to try to reduce the false positives
(IE: the change has to happen for awhile before assuming it is accurate)

In my opinion, neither of these are optimal, and both rely on something outside of our influence to determine your location.

The standard way of dealing with the constant GPS shifting is to increase the size of the circles.

More advanced techniques use other elements to pinpoint location. (WiFi nearby etc)

For example, when I am at Walmart, my phone detects the free wifi… and alerts webCoRE to my location. (note, I am not using GPS for this, so it does not bounce)

When I am at work, my phone sits on a charger near a NFC sticker… Again, this sends a command to webCoRE, alerting it to my location… and avoiding the GPS bounce all day.

#16

“we can practically guarantee that GPS will bounce all day… every day… (even if the device hasn’t moved an inch)”

This is true but this started just a couple of months ago. It has never happened before and I have been using it two years. So I believe it is a problem that should not happen.

Life360 reports for example latitude, longitude and address1 fields to Smartthings (to webcore). Address1 can be life360 circle name or real street name. When user enters circle called “work”, address1 field is “work” and webcore piston fires up. Address1 field is the one that is constantly changing. Webcore sees that “work” changed to somethingroad 2 and reports that user left “work”. Meanwhile user is still at work and latitude and longitude information shows that user really is located in that same building. Even life360 map shows that user’s location is right where it should be but address1 just changed to for example 1km away from that building.

That is why there is no possibility to create piston which uses circle/address information. Of course I tried to maximize circles but that doesn’t help in such cases where school is 5km from home and I’m getting “xxxx arrived to school” messages when kid still has 3km to school :smiley:
Now that I’m using latitude and longitude I’m getting real data about the location and pistons seems to work great. No false alarms and piston fires as soon as conditions changes.

#17

I agree, it’s frustrating, but here is a way to look at it:

  • A sensitive GPS antenna equates to more bouncing around all day
  • A GPS device with fast updates also equates to more bouncing around

In a nutshell, if your GPS does not bounce around, then you can be assured that it is crippled.
(likely software trying to remove false positives)

So the fact that it just started bouncing around for you (assuming it is the same device), means that a recent update is trying to become more accurate. (and unfortunately, accurate equals bouncing around)

Each device has different antennas, but it is not abnormal for even a 2 or 3 km shift through the day… (even if the device has not moved an inch) Remember, the satellites are at least 20,200 km away from us. (so 3 km is over 99.985% accurate)

Often, the bounce only lasts for a few seconds, so by the time you try to verify it in another app etc, it will likely show your correct location.

This scenario is tough to combat… with perhaps the best being circles 2km in diameter.
(IE: close, but not overlapping)

#18

May I ask what you are measuring daily to 21 decimal places??? (Just curious)

#19

When it comes to astronomical math, (moon, sun, altitude, dayLightPercent, etc) I calculate it all with as many decimals as possible, for accuracy. (although I usually round the final number to a single decimal for display purposes)