Half of presence piston stop working

#1

1) Give a description of the problem
I have a piston that I’ve been using for quite some time that kicks off based on presence. Lately, the second half of the piston (which should kick in when either of 2 phones arrive, as long as the location mode is either ‘Away’ or ‘Nanny’ and we’ve been gone for at least 5 minutes) has not been kicking in at all. The first half, which kicks off when we leave, is still working just fine. The issue is probably obvious in the logs, but I can’t figure out all the “Comparison group xyz” stuff.

2) What is the expected behaviour?
2nd half of piston should kick off when either of 2 phones arrive, as long as the location mode is either ‘Away’ or ‘Nanny’ and we’ve been gone for at least 5 minutes.

3) What is happening/not happening?
Presence sensor is arriving properly (I can watch the status change in ActionTiles as I pull up to the house). But the piston never kicks in.

**4) Post a Green Snapshot of the piston![image|45x37]

presence-piston2
presence-piston2.png1178×1459 166 KB

5) Attach logs after turning logging level to Full
12/11/2020, 5:54:00 PM +365ms
+1ms ╔Received event [Steven’s Pixel 3 XL].presence = present with a delay of 98ms
+102ms ║RunTime Analysis CS > 23ms > PS > 22ms > PE > 57ms > CE
+105ms ║Runtime (48041 bytes) successfully initialized in 22ms (v0.3.110.20191009) (103ms)
+106ms ║╔Execution stage started
+121ms ║║Comparison (enum) not present is_not (string) present = true (2ms)
+124ms ║║Comparison (enum) present is_not (string) present = false (1ms)
+125ms ║║Cancelling condition #4’s schedules…
+126ms ║║Condition #4 evaluated false (14ms)
+127ms ║║Cancelling condition #3’s schedules…
+128ms ║║Condition group #3 evaluated false (state changed) (16ms)
+138ms ║║Comparison (enum) not present is (string) present = false (2ms)
+141ms ║║Comparison (enum) present is (string) present = true (1ms)
+142ms ║║Condition #36 evaluated true (12ms)
+147ms ║║Comparison (string) :d9dd57670e2045f82e647efa357a2ed8: is_any_of (string) :e58934e6194ea25b11f64fb3339a96b1:,:d9dd57670e2045f82e647efa357a2ed8: = true (2ms)
+149ms ║║Cancelling condition #37’s schedules…
+150ms ║║Condition #37 evaluated true (7ms)
+215ms ║║Duration 2742596ms for was_not >= 300000ms threshold = true
+216ms ║║Comparison (enum) not present was_not (string) present = true (58ms)
+293ms ║║Comparison (enum) present was_not (string) present = false (76ms)
+295ms ║║Condition #38 evaluated false (144ms)
+297ms ║║Condition group #35 evaluated false (state did not change) (167ms)
+299ms ║║Condition group #7 evaluated true (state did not change) (0ms)
+302ms ║╚Execution stage complete. (196ms)
+303ms ╚Event processed successfully (303ms)

#2

It looks like it is returning false where it is checking if the presence sensor that has just arrìved was previously away for more than five minutes. The other one is returning true OK.

There have been a few issues reported with ‘was’ since ST messed around with the device event history a few weeks ago and I can’t put my finger on what is going wrong. I can’t repeat it myself. If I had to plump for something, I’d say the latest event (the one being processed) isn’t in the event history when it is accessed, but that is wild speculation.

#3

If you turn on Trace, then the green snapshot will have extra info that aligns with the Log.
(it makes troubleshooting much easier)

#4

That completely solves my issue of figuring out which thing is what in the logs, thanks!!!

I removed that line from the piston and I’ll monitor to see if that improves the behavior. It won’t be a complete fix as there is an undesired scenario that could occur without that line, but it’s at least progress.

#5

Confirmed that removing the line for “were not present for 5 minutes” has fixed the piston. I’ll need to restructure things a bit to avoid an undesired outcome without that line, but it should be do-able without that line.