Presence sensor did not flag itself as changed

#1

1) Give a description of the problem
Previously working piston did not execute due to presence sensor changing to present, then evaluating as false when testing for “changed to present” state.

2) What is the expected behavior?
Upon presence arrival, SmartThings routine should be executed.

3) What is happening/not happening?
Last night my one of my presence pistons (activates when I arrive home from work) didn’t fire. According to the logs, the presence sensor was already present, which evaluated as false (even though the presence sensor did change to present).

4) Post a Green Snapshot of the pistonimage

image
image.png1178×520 21.8 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)

Logs

12/4/2018, 12:51:25 AM +477ms
+1ms ╔Received event [Adam].presence = present with a delay of 69ms
+98ms ║RunTime Analysis CS > 13ms > PS > 51ms > PE > 33ms > CE
+101ms ║Runtime (38628 bytes) successfully initialized in 51ms (v0.3.108.20180906) (98ms)
+102ms ║╔Execution stage started
+113ms ║║Comparison (enum) present changes_to (string) present = false (0ms)
+115ms ║║Cancelling condition #4’s schedules…
+116ms ║║Condition #4 evaluated false (7ms)
+117ms ║║Cancelling condition #1’s schedules…
+118ms ║║Condition group #1 evaluated false (state changed) (10ms)
+121ms ║╚Execution stage complete. (20ms)
+122ms ╚Event processed successfully (122ms)

#2

I’ve seen that a few times with mine, too. Usually because my sensor never set itself to “not present” - so when it reports “present” again upon returning home, it didn’t change to present because it already was present.

Can you tell what your presence sensor status was before this event in the logs?

#3

In SmartThings, it arrived at 12:51 a.m. It shows it left when I went to work at 1:44 p.m. the previous day. I am using Life360. I would think as long as it reported correctly in SmartThings, it should trigger the piston to run. Technically, it did, but for some reason webCoRE evaluated the trigger as false.

Life360 has been mostly solid so far. Much better than the stock ST presence for sure.

#4

Is it possible for ST presence to change states and maybe webCoRE didn’t register the change?

#5

I use Life360 too, and have had this issue a few times… usually when my phone battery dies when I’m away and put in on the charger when I get home.

If Life360 misses an event, it takes a bit to sync it back up. For example, if I leave the house and it misses it, it will not recognize that I’ve returned home either. The next time I leave, it will pick it up though.

That bit aside, it seems like your Life360 updated when you left for work and when you arrived back home - only webCoRE didn’t trigger the piston associated with your presence status?

#6

Yes. It does appear that’s what happened. Well, it tried to trigger the piston, but since it saw the phone as already present, it didn’t perform the if statement. Have you ever seen anything like it? It might just be a one-off occurrence.

I’ve had other small issues like that happen with webCoRE. I love the flexibility it affords, but sometimes it just doesn’t work. I’ve had issues where commands are sent to ST, but the devices don’t always respond (which is why you see the async while loop in my code, to try to mitigate those occurrences).

#7

Yeah, that’s because your conditional statement is “if presence changes”… so it will only evaluate true immediately upon changing. If you click ‘test’ at any time, the presence change will not have triggered the piston to run, and so it will evaluate false. One way around that is to set it to “if presence IS present”, just make sure after you save your piston you see the little orange lightning bolt next to any conditions you want to force the piston to run when they change.

Make sense? If not I can explain further.

Agreed - the levels of automation it provides really are unrivaled. But sometimes it hiccups - sometimes this can be programmed around but there are the occasional spots where it’s just a miss and you have to appreciate the times it works correctly, lol.

#8

OK, so I checked further down in the webCoRE logs and sure enough, I’m missing the leave event that is shown in ST.

Is there any way to make sure webCoRE is reliably tracking ST?

#9

I find it works reliably more than 95% of the time just using the “if presence changes” trigger. But if you want to make something more foolproof, you could use a timer to force the piston to run every so often to check presence status (with a timer, you’d have to use IF presence IS present, not ‘changes to’ for the conditions to evaluate correctly).

#10

Thanks. I’ll look into this some more to see if there’s a more reliable way to do this. I’ve marked your answer above as the solution.