Trying to make simple announcement on echo based on distance from Home


#1

1) Give a description of the problem
My Echo is making no announcements
2) What is the expected behaviour?
Trying to have it so that when Im driving home and Im within half a mile of the house, my kitchen echo announces that am I am arriving
3) What is happening/not happening?
No announcement. Please bear with me Im knew to ST, webcore and Echo Speaks. If there is a better way to design this piston, please let me know, what Im doing wrong. Thanks!

4) Post a Green Snapshot of the pistonimage


#2

What method/service of presence are you using that it would know you are x amount of distance from the house?

Unrelated to your issue but just in my own experience I would swap your two lines in your IF. The action that actually triggers a piston should be listed first and in this case it would be your location as opposed to time. Again, this is not going to fix it, merely housekeeping from my experience.


#3

I downloaded the Webcore app and using my phone as the presence sensor


#4

I think the error may be that the Piston command is “speak text” rather than simply “speak.”. Can anyone explain to me the difference?


#5

The ‘Speech Synthesis’ capability is documented for the ‘classic’ environment, but not the ‘new’ environment, and has the command ‘speak’.

The ‘speak text’ command is not documented for any capability in either the ‘classic’ or ‘new’ environments. However SmartThings have a habit of ignoring their own guidelines and not only creating custom commands in ‘official’ device handlers, but supporting them in ‘official’ SmartApps. So it may have become something of a ‘de facto’ standard command. It probably originates with something like a Sonos.

You logs may enlighten you as to what is going on.

Oh and your piston, as presented earlier, is going to execute at 5pm and 7pm as well as when your presence sensor comes into range.


#6

In your piston - when works - your family would get several re-plays of your message because you are using a condition. You car will be IN LESS THEN 0.5 miles for several minutes. Or atleast 2 minutes.
Meanwhile your piston will keep executing over and over…

As others suggested,
Change that condition (line 20) to a trigger,
Something like
IF Presence sensors distance changes to less then 0.5 miles (something like this)
AND
Time is between 5pm and 7pm only on these days (Condition)


#7

Can anyone confirm the proximity calculation function? Does the ST app actively compare your distance to home location from which you can trigger actions as I am reading how this piston would work? If so I am assuming its using GPS?

I have not found the webcore presence app to be very useful/functional for me. Instead I am using the Improved Presence method that works off of known WiFi connectivity.


#8

I use the webcore presence sensor on IOS. I’ve not tried using the proximity feature in webcore, however it does seem to work correctly in the ST app.

I have found that every day or so, I have to open the webcore app on the phone to reconfirm that it can use the phones gps. Even though I specify it can always use it, it still seems confirming. I’m not sure that it stops working if you don’t do this. It can also be slow to update, but I think this is caused by poor gps reception, e.g on the train


#9

I don’t see distance as an option for my phone. Is there something I am missing?


#10

If you look at the device on the ST app, when the status is away, it shows the distance from two locations, I suspect the 2 closest to the current position. At the bottom of the screen if you scroll down, it gives the distance from all registered locations. I’m not sure if this info is available to webcore.


#11

OK, I cant seem to find the trigger “changes to less than” so I modified it to “less than.” Let me know if you think this will work
Is there a way to test this as if the condition has been met? I.E. without having to drive home and have my kids listen to the echo and see if this works?


#12

Great idea… test it first…
One other option, if you get repeating announcements is, use WAIT 20 minutes after line 25 (TCP set to NEVER) and add another IF block
IF presence sensor changes to PRESENT
Then
Cancel all pending tasks

in this case they will get one announcement and that’s it… Because;
1 - You’ll get home in 20 minutes (0.2 miles)
2 - Your sensor for sure - 99% - will register present in 20 minutes.


#13

OK Hopefully this will work, thank you for the help, let me know if I did anything wrong.


#14

So nothing happened. This is what I see on the logs:

Logs

11/15/2019, 3:39:37 PM +514ms
+10159ms ║Piston waited at a semaphore for 10048ms
11/15/2019, 3:39:37 PM +542ms
+10121ms ║Piston waited at a semaphore for 10018ms
11/15/2019, 3:02:59 PM +292ms
+10105ms ║Piston waited at a semaphore for 10017ms
11/15/2019, 3:02:59 PM +283ms
+10084ms ║Piston waited at a semaphore for 10017ms


#15

Pistons time out in 10 seconds… Setting Log Level to Full will reveal more…


#16

Is TCP set to NEVER?


#17

Hi. Can you please explain how to do that? Sorry. Still a very fresh noob trying to learn a lot in a short time


#18

Still cant get it to work but here are my full logs:

11/16/2019, 9:45:04 PM +278ms
+1ms ╔Received event [Leon Presence Sensor].distance = 0.0026357010336382275 with a delay of 71ms
+108ms ║RunTime Analysis CS > 18ms > PS > 38ms > PE > 52ms > CE
+111ms ║Runtime (39003 bytes) successfully initialized in 38ms (v0.3.110.20191009) (108ms)
+112ms ║╔Execution stage started
+118ms ║║Comparison (decimal) 0.0026357010336382275 changes_to (decimal) 0.2 = false (0ms)
+120ms ║║Condition #3 evaluated false (4ms)
+121ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+129ms ║║Condition #8 evaluated false (6ms)
+130ms ║║Condition group #7 evaluated false (state did not change) (7ms)
+132ms ║╚Execution stage complete. (21ms)
+133ms ╚Event processed successfully (133ms)
11/16/2019, 9:44:52 PM +121ms
+1ms ╔Received event [Leon Presence Sensor].presence = present with a delay of 54ms
+10125ms ║RunTime Analysis CS > 35ms > PS > 10040ms > PE > 50ms > CE
+10126ms ║Piston waited at a semaphore for 10013ms
+10128ms ║Runtime (39069 bytes) successfully initialized in 10040ms (v0.3.110.20191009) (10126ms)
+10129ms ║╔Execution stage started
+10139ms ║║Condition #3 evaluated false (5ms)
+10140ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+10145ms ║║Comparison (enum) present changes_to (string) present = false (0ms)
+10146ms ║║Condition #8 evaluated false (4ms)
+10147ms ║║Condition group #7 evaluated false (state did not change) (4ms)
+10148ms ║╚Execution stage complete. (19ms)
+10149ms ╚Event processed successfully (10149ms)
11/16/2019, 9:44:53 PM +337ms
+2ms ╔Received event [Leon Presence Sensor].distance = 0.0024218840592257172 with a delay of 83ms
+122ms ║RunTime Analysis CS > 22ms > PS > 46ms > PE > 53ms > CE
+124ms ║Runtime (39003 bytes) successfully initialized in 46ms (v0.3.110.20191009) (121ms)
+125ms ║╔Execution stage started
+132ms ║║Comparison (decimal) 0.0024218840592257172 changes_to (decimal) 0.2 = false (1ms)
+134ms ║║Condition #3 evaluated false (4ms)
+135ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+144ms ║║Condition #8 evaluated false (7ms)
+145ms ║║Condition group #7 evaluated false (state did not change) (8ms)
+147ms ║╚Execution stage complete. (21ms)
+148ms ╚Event processed successfully (147ms)


#19

Lıne 22 WITH - click on it…
Click on settings wheel
You’ll see Task Cancellation Policy - click
Choose NEVER


#20

I note that the distances reported by the Presence Sensor are numbers like 0.0024218840592257172, so I think your comparison with 0.2 is a little optimistic. You really need to look for it falling below 0.2. I think the comparison is ‘drops below’.

Your semaphore wait will be because you received a distance change event near simultaneously with the presence change event. The one that started second is supposed to give the first one up to ten seconds to finish (it goes into a tight loop) but I only ever seem to see circa ten second ones.

As the piston will keep triggering on distance you will need the TCP set to ‘never’, as advised, to avoid the wake-up from the wait being cancelled.