Can't get motion lights to work right

#1

So i have tried this a few times in my garage and kitchen and keep getting inconsistent results. I’ll be working in my garage and bam, no lights. I start to dance to get the lights to come on tripping over tools and well you get the idea. Same in the kitchen for my wife’s under the counter lights. It seems like its going to work and them bam lights are out and takes about 15 seconds to get them back on. Both rooms use a Ring camera for motion. The garage also has another Ecolink motion detector. For the garage i have added that both motions detectors need to be inactive for 15 min, but still get inconsistent results. I used a few examples I have found on the forums here, but all seem to do the same.

1) Give a description of the problem
lights not working as expected

2) What is the expected behaviour?
lights come on via smart switch from motion and turn off 3 min of no motion

3) What is happening/not happening?
Lights go out when were still in room and moving. then dont come back on right away, but I see motion on the camera. Using a ring camera’s motion detection.

**4) Post a snapshot, wil

xK8WwMCzoDkDrcB1Jf27yjtZ9bq
xK8WwMCzoDkDrcB1Jf27yjtZ9bq.png1178×644 59.5 KB

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

#3

There are MANY ways to do this. I would try :

IF Motion Sensor 3 motion changes to active
  Then
    With Outlet 2
    Turn On
END IF

IF Motion Sensor 3 motion stays inactive for 3 minutes
  With Outlet 2
    Turn Off
END IF
#4

Remove the Never Cancel for the Task Cancellation Policy on the second IF.

#5

I’m seeing this often and I just want to clarify it in my mind…
Is there any reason to code this as “motion is active” versus “motion changes to active”? Do they both behave the same way? It would seem that both methods will trigger on any motion.

#6

Ok I have removed the never cancel task for the second IF/Block and changed from “when active” to “changed to active”. This seemed to help. Today I was in the garage for 3 hours, but the lights still when out once and it was when I was walking in the middle of the garage to the tool box. Better because they normally never stay on that long. I’m guess I’m confused on why the active would not be a better choice than changed to active. Also I have not changed the wait to a stay yet, but will test that. Again, not sure why it would matter, I would expect the same results either way.

#7

When there is no trigger in a statement, the condition you put in will act like one (trigger).

#8

Right, when used as above, programmatically, motion is active and motion changes to active work the same.

Now, in the second IF above, do the commands WAIT 3 minutes and inactive for 3 minutes work the same? I know that frequently we use TCP with WAITS to make sure that subsequent instructions get executed. But does that reasoning apply to the inactive for 3 minutes?

#9

I prefer ‘is active’ for simple pistons like this as it means you can fire the piston (test / execute / external URL) when the motion is already in a particular state and it will do something sensible.

Similarly if you do ‘if time is between sunset and sunrise AND sensor motion is active’ you get the piston firing at sunset and sunrise as well as on motion and that is useful.

I also favour conditions for simple presence based pistons. You can’t toggle presence and motion as easily as toggling a switch so working with the current state can be handy.

#10

Are you saying that the piston will fire when time changes to “sunset” and “sunrise”? I can see where that would be handy :slight_smile:

#11

Yes, that is right. If you do …

if time is between sunset and sunrise
  and
  sensor motion changes to active

… the piston will only fire the piston if the sensor motion changes, which means if motion is already active at sunset the if condition returns false. However if you do …

if time is between sunset and sunrise
  and 
  sensor motion is active

… there aren’t any triggers so webCoRE will fire the piston if the sensor motion changes and also schedule runs for sunset and sunrise as those times are clearly of interest. So if there is already motion at sunset the if returns true.

Sometimes letting webCoRE do its own thing is the better solution.

#12

Do they work the same? No. Might they achieve the same result in some cases? Yes.

Consider:

if sensor motion changes to inactive
then
  wait 3 minutes
  turn off light
endif
other stuff

With that piston, when the sensor stops detecting motion it will execute the piston and when it gets to the ‘if’ the condition will return true. It will go into the ‘then’ and promptly set a timer for three minutes time and exit. If the motion stays inactive it will wake up, turn off the light, and then continue after the endif with the other stuff.

If motion changes to active in the meantime the piston will fire, execute from the top, then decide the ‘then’ isn’t needed any more and cancel the scheduled task (this is the default TCP that cancels scheduled tasks). The piston will still wake up but promptly exit again as there is nothing to do. Until the end of November I was convinced the scheduled wakeup itself would be cancelled but if that was ever true it isn’t now. If you want the light to turn off regardless of whether there is motion you need to change the TCP to never cancel scheduled tasks.

Now for the ‘timed trigger’, as it is referred to in the piston code, if nowhere else.

if sensor motion stays inactive for 3 minutes
then
  turn off light
endif
other stuff

If motion changes to inactive the piston will fire and when it gets to the ‘if’, two things will happen. Firstly a scheduled wake up will be set for three minutes time, rather like doing a ‘wait 3 minutes’. Secondly the condition will immediately return false and the piston will continue on its way, executing an ‘else’ block if there is one and then doing the ‘other stuff’.

The wake up side of things works pretty much as in the previous example. It the motion stays inactive the piston will wake up, turn the light off, and then do the ‘other stuff’. If the motion changes to active the piston runs again and the scheduled task associated with the ‘stays’ is cancelled. The piston still wakes up but there is nothing for it to do.

#13

Fantastic explanation!! I have never really understood this until now. Thank you.

#14

Will it do the “other stuff” twice?

#15

Yes. I find it a little counter intuitive but that is how it works.

#16

@orangebucket, How are WAITS handled in a WHILE block?
Consider the following…

    IF Garage_Door_Sensor changes to OPEN
      Then
        While Garage_Door_Sensor is OPEN
          Do
            WAIT 15 minutes
            IF Garage_Door_Sensor is Open
              Then SMS "The garage door is still open"  
        END While
    END IF
    Other stuff...
#17

I just realised I was tagged on that. I’d probably need to test it to see what happens in various circumstances and then think about why it works as it does.

As far as I know, when it comes to things like the WAIT and the Task Cancellation Policy, you can just read the WHILE as an IF (indeed they share the same ‘case’ statement in the code).

It is, of course, the looping that makes things interesting. With a condition like ‘is open’, and a long wait (roughly 5 seconds or more), I think things are straight forward. I think the piston will do a lot of scheduling of a new instance, exiting and waking up.
With a short WAIT (< 5 seconds) you would see the piston do a busy wait (running a tight loop of code) for perhaps two iterations before it implements a WAIT by scheduling a new instance (to save running out of execution time), and repeating that sequence.

If the WHILE used a trigger condition like ‘changes to open’, I would guess that if the WAIT caused a new task to be scheduled the loop would terminate next time around as the trigger would now be false.

In the case of the example piston, the piston will need to be triggered from the top to terminate. Unless the piston receives a garage door open event when it is already open, I think any trigger will cause any tasks scheduled due to the IF to be cancelled, and that will include the WAIT inside the WHILE.

So in your example I think that if the garage door sensor changes from closed to open you will get an SMS after every 15 minutes, until the door sensor changes back to closed or you press the ‘test’ button or something, in which case some ‘Other stuff …’ will be done.

Now I guess I’ll have to test to see how close my predictions are to reality.

#18

Just wanted to let everyone know that it seems to be working great now. I think I might have had a couple issues. First changing from “is active” to “changed to active” really helped. I also found that Ring camera motion sensor is kind of junk. I replaced it with the new Smartthings motion sensor that is about 20.00 and it works so much better. Way more consistent and the range is so much better.