I have had WebCore presence sensors working for a couple of years now. It is the only thing that I have running on Smartthings now. I have setup a piston to update some virtual switches in homeseer to keep track of presence. However, for about the last 3 or 4 months, the presence flips back and forth making this unreliable. So for instance, I leave the house and it registers that I have left and then it registers that I am home a few seconds later. I setup a “wait” 2 minutes in the piston to try to get it to accurately update but that isn’t working. And I guess that because after two minutes the piston doesn’t update because the presence didn’t just change. So, my question is why it is doing this flipping back and forth on presence and how can I make my piston work when this is happening?
Presence sensors flipping back and forth (not present/present)
WebCoRE is event driven, so whenever there is a lightning bolt in the left margin, there is nothing we can do to prevent the next event from re-triggering the same piston again from the top.
On this note, all of your WAITS are 100% useless, because there is nothing programmed to happen after the WAIT.
You may have to use the events to set a time variable, and compare it to the previous time variable… If the difference is greater than X, then send the GET request.
Note: GPS will jump throughout the day… (even if you are sitting on the couch), so that will also need to be addressed at some point.
If you don’t mind a one minute delay when you change locations, then you can try the above if you like… Just keep in mind that every single lightning bolt event will still start the piston all over at the top.
(You can set your logging level to Full to see what I am talking about)
IE: If Sensor 4 and Sensor 5 arrive home at the same time, then the piston will fire at least twice, with two additional timers in place… (for a total of four triggers) If the GPS bounces, (Home > Away > Home), then those two triggers can increase to six, with just as many timers being created or cancelled.
My understanding of how the piston works is that it looks at the first IF and evaluates it. If it is False then it looks at the next IF and sees if it is TRUE or FALSE. If it is TRUE it executes and if it is FALSE it goes to the next IF and evaluates it, etc. The piston seems to work except my one webcore presence doesn’t seem to be making the piston fire when it should.
This is completely true.
It will continue that logic all the way down the piston… For each and every trigger coming in.
Now I am confused. Your original post said the piston fired even when it shouldn’t…
(more times than you would like)
Now you are saying that it does not fire enough?!?
I said that the webcore presence sensor was flip flopping back and forth which was causing the piston to fire Home, Away, Home when coming home or leaving. But this week I am also noticing that even though the presence sensor came home, it isn’t firing the GET to update the homeseer virtual device.
With today’s technology, this is very common with GPS.
(we cannot blame webCoRE for this)
Are you using a different piston? (perhaps this one)
That particular piston has two triggers tied together with AND… (which normally will not work)
… but since they are based on the same device and attributes, it is worth testing anyways.
Note: If it does work, (big IF), it will likely be a minute after your GPS settles down.
Pro Tip:
For future troubleshooting (especially with something as tricky as location) I highly recommend turning on Trace and setting logs to Full. (more information can be found here)
Afterwards, you can:
- Clear the log (to delete the old data)
- Go for a drive (to create a new log)
- Post the latest green snapshot here (with Trace turned on)
- Post the most recent logs from your last test.
Also note that anytime you edit the piston, you’ll need to start all over with the previous 4 steps.
This is the log for this morning. My hubbie left and came back. It didn’t send the GET request on either.
5/24/2020, 8:45:08 AM +93ms
+1ms ╔Received event [Home].time = 1590324309270 with a delay of -1177ms
+120ms ║RunTime Analysis CS > 28ms > PS > 45ms > PE > 47ms > CE
+123ms ║Runtime (48136 bytes) successfully initialized in 45ms (v0.3.110.20191009) (122ms)
+124ms ║╔Execution stage started
+125ms ║╚Execution stage complete. (1ms)
+126ms ╚Event processed successfully (125ms)
5/24/2020, 8:44:49 AM +432ms
+0ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 0ms
+100ms ║RunTime Analysis CS > 23ms > PS > 35ms > PE > 42ms > CE
+103ms ║Runtime (48140 bytes) successfully initialized in 35ms (v0.3.110.20191009) (101ms)
+103ms ║╔Execution stage started
+121ms ║║Condition #13 evaluated false (6ms)
+121ms ║║Condition group #11 evaluated false (state did not change) (7ms)
+127ms ║║Condition #14 evaluated false (5ms)
+128ms ║║Condition group #12 evaluated false (state did not change) (5ms)
+134ms ║║Condition #23 evaluated false (4ms)
+135ms ║║Condition group #21 evaluated false (state did not change) (6ms)
+141ms ║║Condition #24 evaluated false (4ms)
+141ms ║║Condition group #22 evaluated false (state did not change) (5ms)
+143ms ║╚Execution stage complete. (40ms)
+144ms ╚Event processed successfully (144ms)
5/24/2020, 8:44:49 AM +133ms
+0ms ╔Received event [Home].time = 1590324290393 with a delay of -1261ms
+107ms ║RunTime Analysis CS > 24ms > PS > 36ms > PE > 48ms > CE
+110ms ║Runtime (48138 bytes) successfully initialized in 36ms (v0.3.110.20191009) (109ms)
+111ms ║╔Execution stage started
+119ms ║║Cancelling condition #38’s schedules…
+120ms ║║Condition #38 evaluated true (1ms)
+121ms ║║Cancelling condition #5’s schedules…
+122ms ║║Condition group #5 evaluated true (state changed) (4ms)
+124ms ║║Cancelling statement #7’s schedules…
+131ms ║║Sending internal web request to: 192.168.1.15:8000/JSON?request=setdevicestatus&ref=549&value=100
+135ms ║║Executed virtual command httpRequest (5ms)
+136ms ║║Requesting a wake up for Sun, May 24 2020 @ 8:45:09 AM EDT (in 20.0s)
+141ms ║╚Execution stage complete. (29ms)
+142ms ║Setting up scheduled job for Sun, May 24 2020 @ 8:45:09 AM EDT (in 19.996s)
+150ms ╚Event processed successfully (151ms)
5/24/2020, 8:43:50 AM +253ms
+1ms ╔Received event [Tom-webCoRE].currentPlace = Home with a delay of 80ms
+112ms ║RunTime Analysis CS > 21ms > PS > 42ms > PE > 50ms > CE
+115ms ║Runtime (48137 bytes) successfully initialized in 42ms (v0.3.110.20191009) (113ms)
+116ms ║╔Execution stage started
+124ms ║║Comparison (string) Home changes_to (string) Away = false (0ms)
+125ms ║║Condition #2 evaluated false (5ms)
+126ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+130ms ║║Comparison (string) Home changes_to (string) Home = true (1ms)
+132ms ║║Cancelling condition #6’s schedules…
+132ms ║║Condition #6 evaluated true (5ms)
+138ms ║║Comparison (string) Home stays (string) Home = true (1ms)
+139ms ║║Adding a timed trigger schedule for condition 38
+142ms ║║Cancelling condition #38’s schedules…
+142ms ║║Condition #38 evaluated false (9ms)
+143ms ║║Condition group #5 evaluated false (state did not change) (16ms)
+153ms ║║Condition #13 evaluated false (7ms)
+154ms ║║Condition group #11 evaluated false (state did not change) (9ms)
+160ms ║║Condition #14 evaluated false (5ms)
+161ms ║║Condition group #12 evaluated false (state did not change) (6ms)
+169ms ║║Condition #23 evaluated false (6ms)
+170ms ║║Condition group #21 evaluated false (state did not change) (7ms)
+176ms ║║Condition #24 evaluated false (5ms)
+177ms ║║Condition group #22 evaluated false (state did not change) (6ms)
+179ms ║╚Execution stage complete. (63ms)
+180ms ║Setting up scheduled job for Sun, May 24 2020 @ 8:44:50 AM EDT (in 59.96s)
+190ms ╚Event processed successfully (190ms)
5/24/2020, 8:00:46 AM +936ms
+1ms ╔Received event [Tom-webCoRE].currentPlace = with a delay of 157ms
+107ms ║RunTime Analysis CS > 24ms > PS > 36ms > PE > 46ms > CE
+109ms ║Runtime (48131 bytes) successfully initialized in 36ms (v0.3.110.20191009) (107ms)
+110ms ║╔Execution stage started
+117ms ║║Comparison (string) changes_to (string) Away = false (1ms)
+118ms ║║Condition #2 evaluated false (4ms)
+119ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+123ms ║║Comparison (string) changes_to (string) Home = false (0ms)
+124ms ║║Condition #6 evaluated false (4ms)
+125ms ║║Condition group #5 evaluated false (state did not change) (5ms)
+134ms ║║Condition #13 evaluated false (7ms)
+135ms ║║Condition group #11 evaluated false (state did not change) (8ms)
+142ms ║║Condition #14 evaluated false (6ms)
+143ms ║║Condition group #12 evaluated false (state did not change) (7ms)
+152ms ║║Cancelling condition #23’s schedules…
+153ms ║║Condition #23 evaluated false (7ms)
+154ms ║║Cancelling condition #21’s schedules…
+154ms ║║Condition group #21 evaluated false (state changed) (9ms)
+160ms ║║Cancelling condition #24’s schedules…
+161ms ║║Condition #24 evaluated false (6ms)
+162ms ║║Cancelling condition #22’s schedules…
+163ms ║║Condition group #22 evaluated false (state changed) (7ms)
+164ms ║╚Execution stage complete. (54ms)
+165ms ╚Event processed successfully (165ms)
Blockquote
Sorry, as mentioned earlier, I won’t look at a log unless I know exactly what piston it is referring to. (with trace turned on)