Motion sensor was not active for at least 15 minutes not working as expected

[Cyberfreak]

Hi,

I know that ST motion sensors do not have constant communication with ST. So can someone explain to me how “Motion Sensor was not active for at least 15 minutes” works?

Does ST or webcore keep track of the last time the sensor was active in a variable somewhere?

What I was thinking it did was it would fire if, after some activity, 15 minutes have passed as inactive, it would trigger the piston. Is this correct?

1) Give a description of the problem
Piston doesn’t seem to be firing as expected because lights don’t turn off after the room is empty for 15 minutes.

2) What is the expected behavior?
The lights turn off when the room is empty for 15 minutes.

3) What is happening/not happening?
The piston doesn’t seem to be executing, the lights are not turning off.

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

I suspect that I am using the ‘was not active for at least X minutes…’ incorrectly somehow. Does someone have an example of how this should be properly used in a piston?

[Robin]

WebCoRE schedules a wake up x minutes after motion… schedule is reset on each motion event.

Your piston should be working. Have you got any logs?

Might be that you need to be using the trigger (stays inactive) instead of the condition (was not active)

[Cyberfreak]

I tried changing it to stays inactive and it doesn’t seem to have made a difference.

2/4/2018, 11:26:20 AM +247ms
+1ms ╔Starting piston… (v0.2.102.20180116)
+480ms ║╔Subscribing to devices…
+511ms ║║Subscribing to Master Bed Motion Sensor.motion…
+693ms ║║Subscribing to Bedside Lamp…
+694ms ║║Subscribing to Hue bloom 1…
+695ms ║║Subscribing to Hue bulb 1…
+696ms ║║Subscribing to Hue bulb 2…
+697ms ║║Subscribing to Hue bulb 3…
+697ms ║║Subscribing to Hue lightstrip…
+698ms ║║Subscribing to Hue Lightstrip Plus 2…
+699ms ║║Subscribing to Master Bedroom Light…
+700ms ║╚Finished subscribing (237ms)
+747ms ║Comparison (enum) inactive stays (string) inactive = true (5ms)
+766ms ╚Piston successfully started (766ms)

I changed it to stays inactive for 5 minutes - how does it know how long the sensor has been inactive? Does the sensor report that information to the webcore piston?

[Robin]

It knows the last active time from ST logs.

You just posted logs from initial activation of the piston. I need to see logs from a motion event followed by whatever happens 5 minutes later.

[Robin]

Personally I prefer to use ‘waits’ for things like this:

IF
motion is inactive
THEN
With bulb x and y
wait 5 minutes
turn off

[Cyberfreak]

If I use the ‘wait’ and motion becomes active during the wait, will it reset the timer?

The idea is that the lights will stay on if someone is going in an out of the room (like walking into the bathroom or closet to put clothes away) but if they leave the room for more than 15 minutes it can be assumed that they aren’t coming back.

Maybe I am just going about this the wrong way I am open to doing it a different way as long as the desired result is achieved.

[Robin]

Yes, each motion event will reset the wait back to the top.

[Yelnoc4]

Wow… Never would have guessed that the WAIT gets reset.

Similarly, I’ve tried a WAIT and a STAYS INACTIVE for 6 minutes, and neither is turning off my lights.

The piston worked before I thought it would be better to use the STAYS INACTIVE. I rearranged some logic, now it doesn’t work.

I do set my piston state to text values to help debug. Is that killing my events (by setting the state to something other than true)?

[Mike1616]

I do set my piston state to text values to help debug. Is that killing my events (by setting the state to something other than true)?

Nope. Unrelated. You can make the piston state whatever you want. It does not affect piston execution.

[Robin]

Piston snapshot please…

[Yelnoc4]

2/10/2018, 6:22:26 AM +248ms
+1ms ╔Received event [Home].time = 1518261747138 with a delay of -890ms
+145ms ║RunTime Analysis CS > 27ms > PS > 53ms > PE > 65ms > CE
+148ms ║Runtime (40813 bytes) successfully initialized in 53ms (v0.2.102.20180116) (146ms)
+149ms ║╔Execution stage started
+150ms ║╚Execution stage complete. (1ms)
+151ms ╚Event processed successfully (151ms)
2/10/2018, 6:16:57 AM +216ms
+2ms ╔Received event [Backyard Aeotec].motion = inactive with a delay of 309ms
+135ms ║RunTime Analysis CS > 21ms > PS > 46ms > PE > 68ms > CE
+138ms ║Runtime (40816 bytes) successfully initialized in 46ms (v0.2.102.20180116) (136ms)
+139ms ║╔Execution stage started
+146ms ║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+148ms ║║Cancelling condition #2’s schedules…
+148ms ║║Condition #2 evaluated false (4ms)
+149ms ║║Cancelling condition #1’s schedules…
+150ms ║║Condition group #1 evaluated false (state changed) (7ms)
+152ms ║╚Execution stage complete. (14ms)
+153ms ╚Event processed successfully (153ms)
2/10/2018, 6:16:26 AM +94ms
+1ms ╔Received event [Backyard Aeotec].motion = active with a delay of 304ms
+110ms ║RunTime Analysis CS > 18ms > PS > 35ms > PE > 56ms > CE
+112ms ║Runtime (40818 bytes) successfully initialized in 35ms (v0.2.102.20180116) (111ms)
+113ms ║╔Execution stage started
+120ms ║║Comparison (enum) active changes_to (string) active = true (1ms)
+121ms ║║Cancelling condition #2’s schedules…
+122ms ║║Condition #2 evaluated true (5ms)
+123ms ║║Cancelling condition #1’s schedules…
+123ms ║║Condition group #1 evaluated true (state changed) (6ms)
+128ms ║║Comparison (integer) 0 is_equal_to (integer) 0 = true (1ms)
+129ms ║║Condition #48 evaluated true (4ms)
+130ms ║║Condition group #37 evaluated true (state did not change) (5ms)
+132ms ║║Cancelling statement #44’s schedules…
+818ms ║║Executed physical command [Back Nano (Q2)].on() (684ms)
+819ms ║║Executed [Back Nano (Q2)].on (685ms)
+826ms ║║Calculating (string) At + (string) 6:16 >> (string) At 6:16
+828ms ║║Calculating (string) At 6:16 + (string) … sunlightScale0to4: >> (string) At 6:16… sunlightScale0to4:
+830ms ║║Calculating (string) At 6:16… sunlightScale0to4: + (string) 0 >> (string) At 6:16… sunlightScale0to4: 0
+832ms ║║Calculating (string) At 6:16… sunlightScale0to4: 0 + (string) … Turned Floods ON >> (string) At 6:16… sunlightScale0to4: 0… Turned Floods ON
+834ms ║║Executed virtual command [Back Nano (Q2)].setState (0ms)
+837ms ║║Cancelling statement #55’s schedules…
+1037ms ║║Executed physical command [Dome Siren].chime2() (197ms)
+1038ms ║║Executed [Dome Siren].chime2 (198ms)
+1040ms ║║Cancelling statement #65’s schedules…
+1042ms ║║Executed virtual command wait (0ms)
+1043ms ║║Requesting a wake up for Sat, Feb 10 2018 @ 6:22:27 AM EST (in 360.0s)
+1048ms ║╚Execution stage complete. (934ms)
+1049ms ║Setting up scheduled job for Sat, Feb 10 2018 @ 6:22:27 AM EST (in 359.996s)
+1060ms ╚Event processed successfully (1060ms)
2/10/2018, 6:15:00 AM +85ms
+1ms ╔Received event [Backyard Aeotec].motion = inactive with a delay of 266ms
+114ms ║RunTime Analysis CS > 19ms > PS > 36ms > PE > 59ms > CE
+117ms ║Runtime (40816 bytes) successfully initialized in 36ms (v0.2.102.20180116) (114ms)
+117ms ║╔Execution stage started
+125ms ║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+127ms ║║Cancelling condition #2’s schedules…
+127ms ║║Condition #2 evaluated false (5ms)
+128ms ║║Cancelling condition #1’s schedules…
+129ms ║║Condition group #1 evaluated false (state changed) (7ms)
+131ms ║╚Execution stage complete. (14ms)
+132ms ╚Event processed successfully (132ms)
2/10/2018, 6:14:31 AM +284ms
+2ms ╔Received event [Backyard Aeotec].motion = active with a delay of 290ms
+143ms ║RunTime Analysis CS > 25ms > PS > 59ms > PE > 58ms > CE
+145ms ║Runtime (40820 bytes) successfully initialized in 59ms (v0.2.102.20180116) (142ms)
+146ms ║╔Execution stage started
+154ms ║║Comparison (enum) active changes_to (string) active = true (1ms)
+156ms ║║Cancelling condition #2’s schedules…
+156ms ║║Condition #2 evaluated true (5ms)
+157ms ║║Cancelling condition #1’s schedules…
+158ms ║║Condition group #1 evaluated true (state changed) (7ms)
+164ms ║║Comparison (integer) 0 is_equal_to (integer) 0 = true (1ms)
+165ms ║║Condition #48 evaluated true (5ms)
+166ms ║║Condition group #37 evaluated true (state did not change) (6ms)
+168ms ║║Cancelling statement #44’s schedules…
+380ms ║║Executed physical command [Back Nano (Q2)].on() (209ms)
+381ms ║║Executed [Back Nano (Q2)].on (209ms)
+388ms ║║Calculating (string) At + (string) 6:14 >> (string) At 6:14
+391ms ║║Calculating (string) At 6:14 + (string) … sunlightScale0to4: >> (string) At 6:14… sunlightScale0to4:
+393ms ║║Calculating (string) At 6:14… sunlightScale0to4: + (string) 0 >> (string) At 6:14… sunlightScale0to4: 0
+396ms ║║Calculating (string) At 6:14… sunlightScale0to4: 0 + (string) … Turned Floods ON >> (string) At 6:14… sunlightScale0to4: 0… Turned Floods ON
+398ms ║║Executed virtual command [Back Nano (Q2)].setState (1ms)
+401ms ║║Cancelling statement #55’s schedules…
+665ms ║║Executed physical command [Dome Siren].chime2() (260ms)
+666ms ║║Executed [Dome Siren].chime2 (260ms)
+668ms ║║Cancelling statement #65’s schedules…
+671ms ║║Executed virtual command wait (1ms)
+672ms ║║Requesting a wake up for Sat, Feb 10 2018 @ 6:20:31 AM EST (in 360.0s)
+677ms ║╚Execution stage complete. (531ms)
+678ms ║Setting up scheduled job for Sat, Feb 10 2018 @ 6:20:31 AM EST (in 359.995s)
+753ms ╚Event processed successfully (753ms)

[Yelnoc4]

I had the off logic out from underneath the “changes to active” IF, with a “stay inactive for” event, but that wasn’t working either. So then I moved it under the ON logic, with a WAIT, but I’m thinking having it nested like that won’t work.

[Robin]

Waits don’t like "changes to active’…

‘Changes to active’ reverts to ‘false’ about 10 seconds after being triggered, which cancells the ‘wait’

Use ‘IS active’

[Yelnoc4]

I had been catching on to Triggers and Conditions and thought that a Trigger was the way to go there. Back to the drawing board

[Yelnoc4]

So, in this one, am I handling “stays inactive for” correctly (with the changes to)?

[Robin]

Test and you will see… looks ok.

Personally I would do:

IF motion is active
Then
do stuff
Else
Wait 3 minutes
do other stuff.

[Yelnoc4]

Similar logic failed to turn off the light in my previous example. This one appears to be working correctly, but since it’s supposed to stay on until there’s plenty of daylight I’ll need to watch it for a while.

Back to the “if motion is active”, it’s fine then to use conditions as long as one understands what happens when mixing trigger and condition drinks?