Motion Light Control Help

fstbusa · 2017-11-30 19:03:04 UTC

Assuming this is what you meant.

bobbles · 2017-11-30 19:23:36 UTC

I’ve just compared your parameters with mine and there are some that are different but I don’t think that should matter.
Perhaps you could put your sensor into config mode, press button b 3 times and the led will go blue, and then push the config button in the device in the ST app.
Just to give it another boot up the backside.

I really don’t understand why it’s not working. Do you have another sensor you could try with to prove it?

bobbles · 2017-11-30 19:37:05 UTC

You could try doing it this way.
Completely different way but works just as well.

Or perhaps set it up using Smart Lighting. This will also prove if it is working as it should.

fstbusa · 2017-11-30 19:42:43 UTC

I’ll give it a shot… based on what I’m seeing in the logs and what I see in the app… I don’t think its the piston causing the issue. The sensor is not reporting motion consistently even though it says its detected motion.

fstbusa · 2017-11-30 19:44:08 UTC

I do not have another motion sensor currently. I’ll be purchasing a few more in the near future. Still trying to decide which one to get. All I know is I’m not getting another one of the Fibaro ones!

talz13 · 2017-12-01 15:40:44 UTC

I’ve been using the “stays” trigger instead of having a wait timer inside the execution. So, for example, I’d have one section of the piston turn the light on when motion sensor’s motion changes to true. And then a separate section of the piston that would wait for the motion sensor’s motion to stay false for… ~3 minutes or so, and turn off then.

It’s really the same thing you’re trying to do, but it won’t schedule the turn off section each and every time the motion sensor goes false. Only when it stays false for the specified amount of time.

fstbusa · 2017-12-01 19:08:14 UTC

I’ll try this and see what happens.

michaellubrano · 2020-12-03 18:05:05 UTC

I’m seeing a very similar issue in a very similar piston. Using a zooz ZSE40 2.0 motion sensor, without TCP set to never, the piston re-executes when the sensor changes to inactive, even though the trigger is ‘changes to active’. this breaks it out of the wait, and the light never shuts off. with TCP never, the same reexecution happens, but it does not interrupt the wait and the light will turn off. However, new motion during the wait will not reset the timer. I have another piston that works fine, using a smartthings motion sensor but I didnt need to set TCP to never.
I think it must be something related to the device? any insight would be appreciated.

I’m using this device handler

Zooz 4-in-1 Sensor v2.3
```
 (Model: ZSE40)
```
Author:
Kevin LaFramboise (krlaframboise)

WCmore · 2020-12-03 20:37:32 UTC

I would ignore the “WHEN TRUE” section, and write the code using the standard structure.

IF something happens      <-- Trigger
Then
    IF something is true  <-- Condition
    Then
        Do cool stuff
    END IF
END IF

Notice you did not use the THEN section at all.

michaellubrano · 2020-12-03 21:10:45 UTC

Well thats a good point - honestly I didnt notice - I didnt really intend to use the when true/false blocks. It’s a little embarrassing, I write PERL code regularly for a living, this is pretty basic stuff… Shows the benefits of proofreading Thanks for the catch - I’ve made the change - I hope it works as I expected it would

michaellubrano · 2020-12-03 21:20:28 UTC

Well while that change might be more standard, it behaves no differently, except that it has introduced about a 4 second delay before the light turns on.

E_Sch · 2020-12-03 21:31:51 UTC

can you post your latest piston and full logs?

michaellubrano · 2020-12-03 21:38:26 UTC

12/3/2020, 4:34:37 PM +75ms
+0ms ╔Received event [My home].time = 1607031277447 with a delay of -373ms
+90ms ║RunTime Analysis CS > 35ms > PS > 6ms > PE > 50ms > CE
+93ms ║Runtime (39224 bytes) successfully initialized in 6ms (v0.3.110.20191009) (91ms)
+94ms ║╔Execution stage started
+125ms ║║Executed physical command [Garage Steps Light].off() (16ms)
+126ms ║║Executed [Garage Steps Light].off (18ms)
+132ms ║║Calculating (string) Off + (string) Thu, Dec 3 2020 @ 4:34:37 PM EST >> (string) Off Thu, Dec 3 2020 @ 4:34:37 PM EST
+135ms ║║Executed virtual command [Garage Steps Light].setState (1ms)
+153ms ║╚Execution stage complete. (60ms)
+155ms ╚Event processed successfully (154ms)
12/3/2020, 4:34:34 PM +322ms
+1ms ╔Received event [Garage Steps].motion = inactive with a delay of 53ms
+68ms ║RunTime Analysis CS > 17ms > PS > 5ms > PE > 46ms > CE
+70ms ║Runtime (39222 bytes) successfully initialized in 5ms (v0.3.110.20191009) (68ms)
+71ms ║╔Execution stage started
+78ms ║║Comparison (enum) inactive changes_to (string) active = false (1ms)
+79ms ║║Condition #2 evaluated false (4ms)
+80ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+82ms ║╚Execution stage complete. (11ms)
+83ms ║Setting up scheduled job for Thu, Dec 3 2020 @ 4:34:37 PM EST (in 3.042s)
+94ms ╚Event processed successfully (94ms)
12/3/2020, 4:34:22 PM +707ms
+2ms ╔Received event [Garage Steps].motion = active with a delay of 82ms
+81ms ║RunTime Analysis CS > 22ms > PS > 7ms > PE > 51ms > CE
+83ms ║Runtime (39220 bytes) successfully initialized in 7ms (v0.3.110.20191009) (80ms)
+84ms ║╔Execution stage started
+91ms ║║Comparison (enum) active changes_to (string) active = false (0ms)
+92ms ║║Condition #2 evaluated false (4ms)
+93ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+95ms ║╚Execution stage complete. (11ms)
+96ms ║Setting up scheduled job for Thu, Dec 3 2020 @ 4:34:37 PM EST (in 14.644s)
+106ms ╚Event processed successfully (106ms)
12/3/2020, 4:34:14 PM +940ms
+1ms ╔Received event [Garage Steps].motion = active with a delay of 44ms
+60ms ║RunTime Analysis CS > 13ms > PS > 5ms > PE > 42ms > CE
+62ms ║Runtime (39218 bytes) successfully initialized in 5ms (v0.3.110.20191009) (61ms)
+63ms ║╔Execution stage started
+70ms ║║Comparison (enum) active changes_to (string) active = false (0ms)
+72ms ║║Cancelling condition #2’s schedules…
+73ms ║║Condition #2 evaluated false (5ms)
+74ms ║║Cancelling condition #1’s schedules…
+74ms ║║Condition group #1 evaluated false (state changed) (7ms)
+77ms ║╚Execution stage complete. (14ms)
+78ms ║Setting up scheduled job for Thu, Dec 3 2020 @ 4:34:37 PM EST (in 22.429s)
+121ms ╚Event processed successfully (121ms)
12/3/2020, 4:34:07 PM +298ms
+1ms ╔Received event [Garage Steps].motion = active with a delay of 83ms
+80ms ║RunTime Analysis CS > 23ms > PS > 7ms > PE > 51ms > CE
+83ms ║Runtime (39194 bytes) successfully initialized in 7ms (v0.3.110.20191009) (80ms)
+83ms ║╔Execution stage started
+90ms ║║Comparison (enum) active changes_to (string) active = true (0ms)
+92ms ║║Cancelling condition #2’s schedules…
+93ms ║║Condition #2 evaluated true (5ms)
+94ms ║║Cancelling condition #1’s schedules…
+94ms ║║Condition group #1 evaluated true (state changed) (7ms)
+105ms ║║Comparison (integer) 0 is_less_than (integer) 8 = true (1ms)
+106ms ║║Condition #4 evaluated true (10ms)
+107ms ║║Condition group #3 evaluated true (state did not change) (11ms)
+109ms ║║Cancelling statement #24’s schedules…
+132ms ║║Executed physical command [Garage Steps Light].on() (20ms)
+133ms ║║Executed [Garage Steps Light].on (22ms)
+139ms ║║Calculating (string) On + (string) Thu, Dec 3 2020 @ 4:34:07 PM EST >> (string) On Thu, Dec 3 2020 @ 4:34:07 PM EST
+142ms ║║Calculating (string) On Thu, Dec 3 2020 @ 4:34:07 PM EST + (string) waiting 30 sec >> (string) On Thu, Dec 3 2020 @ 4:34:07 PM EST waiting 30 sec
+144ms ║║Executed virtual command [Garage Steps Light].setState (1ms)
+147ms ║║Executed virtual command [Garage Steps Light].wait (0ms)
+149ms ║║Requesting a wake up for Thu, Dec 3 2020 @ 4:34:37 PM EST (in 30.0s)
+155ms ║╚Execution stage complete. (72ms)
+160ms ║Setting up scheduled job for Thu, Dec 3 2020 @ 4:34:37 PM EST (in 29.99s)
+167ms ╚Event processed successfully (167ms)

WCmore · 2020-12-03 23:37:52 UTC

As you discovered, setting line 32 to (TCP=Never) will cause the lights to go off 30 seconds after you enter the room. (even if it is still occupied)

Alternatively, setting that (TCP=Default) will cause each inactive/active sequence to start the piston at the top. (thereby resetting the 30 sec timer)

So which do you want?

The light to go off 30 sec after entering the room, regardless?
or
The light to go off 30 seconds after the room has been cleared?

If your answer is the latter, try this structure:

IF Sensor's motion changes to active
Then
    IF condition is X
    Then
        Turn on light
    END IF
END IF

IF Sensor's motion stays inactive for 30 seconds
Then
    Turn off light
END IF

Note: You will likely want to increase the 30 sec to something more reasonable, like 5 minutes. Otherwise, you will be forced to keep moving to keep the light on.

michaellubrano · 2020-12-04 02:23:27 UTC

I want it to reset the counter, that was my point - without TCP = never, when the sensor changes back to inactive, it breaks out of the wait - leaving the light on and the piston in the …waiting state indefinitely, I only set TCP = never to get it to wait the 30 seconds, but with that, new motion doesnt extend the counter, nor does it without. I have another piston that works fine - without TCP never, but it is a different motion sensor. I’m trying to figure out why this one re-executes the piston on change to inactive (within the 30 seconds), and leaves it in limbo - it never resets the wait. also I dont want the light to stay on for 5 minutes, its a short stairwell, there is never much more motion than that, but I want it to extend if I have to backtrack (say I forgot my keys…) but again if I set it for 5 minutes, the same happens when it goes inactive - it abandons the wait and leaves the light on.

WCmore · 2020-12-04 03:15:52 UTC

Excellent. My last post has the perfect structure for you.

michaellubrano · 2020-12-04 03:19:17 UTC

It makes sense on paper ;), I will try that. thanks for your input!

michaellubrano · 2020-12-04 03:40:25 UTC

@WCmore this does work adequately. One note: it does wait 45 seconds to turn off the light, as the sensor changes to inactive at 15 sec. apparently the change re-executes the piston regardless of the state to which it changed. this is what I don’t expect… I can live with this though - or adjust the wait, but 15 seconds is not a long time (even though my travel in that area is normally less than that)
Thanks once again! sometimes it just takes a different perspective

WCmore · 2020-12-04 04:10:26 UTC

Yes… The timer begins when the device reports that it is inactive. Just subtract the 15 second timeout on your device from the desired delay, and you will be golden.

IE: If you want a 45 sec delay with lights on, then use:
STAYS inactive for 30 sec

Pro Tip:

Every manufacturer’s devices will have a different time-out on active/inactive.
(oftentimes, different versions of the same device will be different)

30 sec - 3 min seems to be the norm, but I have seen some timeout as quickly as 6sec and as slowly as 5 min. (This is often part of the calibration process when working on an unfamiliar house)