Why is this piston not setting location mode to Home anymore?

[freddyq]

1) Give a description of the problem
I have a piston which automatically sets location mode to Home if we come home from being away or every morning at 7am to switch out of Night mode. It was working fine until recently but now it is not triggering at 7am so the location mode gets left to Night.

2) What is the expected behaviour?
Location mode should be changed to Home every morning at 7am if one or both of us are at home (based on simulated mobile presence sensors)

3) What is happening/not happening?
Piston has stopped triggering so the location mode isn’t changed.

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

5) Attach logs after turning logging level to Full
Logs from the last time the piston was triggered:
1/2/2021, 6:59:59 AM +90ms
+1ms ╔Received event [Home].time = 1609570800000 with a delay of -910ms
+283ms ║RunTime Analysis CS > 31ms > PS > 7ms > PE > 245ms > CE
+286ms ║Runtime (41880 bytes) successfully initialized in 7ms (v0.3.110.20191009) (284ms)
+287ms ║╔Execution stage started
+330ms ║║Condition #6 evaluated false (36ms)
+332ms ║║Condition group #1 evaluated false (state did not change) (38ms)
+340ms ║║Comparison (string) :d3dc195c6ea99304d142f80151ca8da2: is (string) :c465aace1b0b65e0843af2bee0c2ad3e: = false (2ms)
+342ms ║║Cancelling condition #16’s schedules…
+344ms ║║Condition #16 evaluated false (8ms)
+346ms ║║Cancelling condition #15’s schedules…
+347ms ║║Condition group #15 evaluated false (state changed) (12ms)
+357ms ║╚Execution stage complete. (69ms)
+359ms ╚Event processed successfully (358ms)
1/1/2021, 6:59:59 AM +84ms
+0ms ╔Received event [Home].time = 1609484400000 with a delay of -917ms
+392ms ║RunTime Analysis CS > 37ms > PS > 16ms > PE > 340ms > CE
+395ms ║Runtime (41883 bytes) successfully initialized in 16ms (v0.3.110.20191009) (394ms)
+397ms ║╔Execution stage started
+448ms ║║Condition #6 evaluated false (42ms)
+450ms ║║Condition group #1 evaluated false (state did not change) (45ms)
+459ms ║║Comparison (string) :c465aace1b0b65e0843af2bee0c2ad3e: is (string) :c465aace1b0b65e0843af2bee0c2ad3e: = true (2ms)
+462ms ║║Condition #16 evaluated true (7ms)
+502ms ║║Comparison (enum) present is (string) present = true (3ms)
+505ms ║║Condition #17 evaluated true (41ms)
+510ms ║║Comparison (time) 25199591 happens_daily_at (time) 25200000 = true (1ms)
+512ms ║║Time restriction check passed
+514ms ║║Condition #18 evaluated true (7ms)
+515ms ║║Cancelling statement #18’s schedules…
+520ms ║║Requesting time schedule wake up at Sat, Jan 2 2021 @ 7:00:00 AM GMT
+524ms ║║Condition group #15 evaluated true (state did not change) (70ms)
+528ms ║║Cancelling statement #19’s schedules…
+913ms ║║Executed virtual command setLocationMode (380ms)
+950ms ║║Executed virtual command setAlarmSystemStatus (34ms)
+972ms ║║Executed virtual command sendPushNotification (16ms)
+975ms ║╚Execution stage complete. (579ms)
+977ms ║Setting up scheduled job for Sat, Jan 2 2021 @ 7:00:00 AM GMT (in 86399.939s)
+1020ms ╚Event processed successfully (1020ms)

[orangebucket]

It looks like when it triggered on the 2nd the location mode wasn’t Night so it never reached the Time happens daily trigger and so never scheduled the next run (the piston schedules itself based on the code it executes).

I would recommend rearranging the if on lines 31-36 so that Time happens daily is the first condition. That makes sure it gets scheduled to tun the next day.

As a general rule, if you have included a trigger condition in your piston and that causes your piston to fire, you should make sure the piston evaluates the trigger when it does.

[freddyq]

Thanks I’ve re-arranged the if conditions so that the time one is first.

I’ve been manually setting location mode to home via the ST app when I’ve noticed it hasn’t happened automatically so that might have messed up the scheduling.

Could you explain this a bit more please? Not sure I understand:

As a general rule, if you have included a trigger condition in your piston and that causes your piston to fire, you should make sure the piston evaluates the trigger when it does.

[jkp]

you can also remove the two “set smart home monitor status” commands as they no longer work

[orangebucket]

Could you explain this a bit more please? Not sure I understand:

Consider a timed execution like time happens daily at 7am. When the piston first starts up it will scan through the piston code and sees that it will need to run at 7am (whenever the next 7am is). After that, every time the piston evaluates that line it will add the next 7am to its list of times it needs to run. As long as the piston does evaluate that line some time between 7am today and 7am tomorrow, it will run at 7am tomorrow. Your original piston actually only evaluated the line at 7am if the location mode was Night and at least one of the two presence sensors was present. If that wasn’t the case it prevented it running at 7am the next day unless circumstances caused the piston to run some other time when the conditions were met. The best way of ensuring that happens is to make sure that when the piston runs at 7am it does actually evaluate the time happens daily at 7am line.

There is a similar concept with triggers based on attributes like presence sensor presence changes to present. The piston is run whenever there is a presence event, regardless of what the new state is and whether the events have been delivered in the right order. In order to return true a presence sensor presence changes to present comparison requires the piston to be running in response to a presence sensor presence event, the value in the event to be present, and the value that was in the event last time it was processed to be not present. So if the piston runs when the presence sensor is not present but doesn’t actually evaluate the presence sensor presence changes to present trigger, it will not know about the not present and that can cause changes to return the “wrong” result when it is next evaluated. So again, the best way of keeping things working correctly is to actually make sure the pistons can reach the triggers that cause them to run in the first place.