The light won't turn back off at the end.
There are many different ways to accomplish your task. I have two observations. First, you have nested triggers (the orange lightning bolts in the left margin) at lines 21 and 38. A trigger inside of a trigger is asking for trouble. Second, I would ask you to re-think your turn off logic. What is/are the conditions needed to turn OFF your Front Door Lights? After 5 minutes? After all motion is inactive for 5 minutes? One suggestion would be to remove your WAIT 5 minutes and pull your "OFF" IF statement out from under the first IF and make it a trigger of it's own...
If all of Camera Driveway and Camera Walkway motion are not and stay not active for 5 minutes
AND
FNL is true
Then
with Front Door Lights
Do
Turn Off
Set FNL to false
END IF
This way, your lights won't be turned off after 5 minutes even if motion is still present, leaving someone standing in the dark.
Thanks for replying.
I get there are other ways to accomplish this, I figured those before posting. But I want to underatand why THIS isnt working, especially for future scripting with webcore in HE. The logic makes complete sense to me and it would....in my experience....work in any other programming language. Stop the script for 5 minutes, proceed, if the variable is true turn off the lights. Nested triggers should never be a problem in any programming language as long as there are adequate sleep/pause/wait times. So why isn't it working? I don't believe that this script is asking for trouble, it's far too ssimple. I've been having trouble with webcore in HE ever since I migrated that I never had with ST and am trying to track down all "limitations" and "quirks" before I dive too much deeper with the scripting...even if it's my error. So why? What am I not seeing? Is the variable incorrectly set up?
Thanks.
P.s. you're right about leaving them in the dark...I'm more concerned about people who shouldn't be there, so I'm going to leave a timing element, but also add a no motion portion.
Posting webcore logs medium or full and watching traces would help.
I have notoriously struggled with WAITS. Search the webcore forum and you will see my posts. But I am going to take a shot at this one and I understand that I may be opening myself up for correction...
After the WAIT, the piston re-evaluates the triggers (either of the motion sensors) and if they are now inactive, the statements after the WAIT are cancelled because the trigger has changed state. You do not have any statements after your WAIT. So setting the TCP to "Never Cancel" does not apply there. But, the following IF statement that turns off the light will be cancelled because it is not covered by the TCP set to "Never Cancel." However, if you put the last IF statement within the WITH statement that has "Never cancel", I suspect turning off the light will not be cancelled.
1 Like
The problem with using WAIT is that the trigger state may no longer be true at the end of the wait period. That is, are both camera's motion still true after 5 minutes? If not, the script will bail when one of the cameras' motion goes inactive.
I would group the first two IFs using AND, and also separate the "turn off" IF into it's own triggered event.
If all camera motion is active
AND
If Time IS NOT BETWEEN $sunrise and $sunset (this way sometimes helps when spanning midnight)
THEN
Turn on light, set FNL to true, and announce.
If FNL is and stays True for 5 minutes
THEN
Turn off the light, set FNL to false.
Ahhhhhhhhhh. I don't think I've come across a WAIT like this before. To me it doesn't make sense. If I enter a function based on a trigger I'm looking for that function to complete no matter what I don't need anything reevaluated,
my conditions are set . And if a condition happens that changes my needs, I put a condition to EXIT that function/trigger condition. My WAIT has absolutely nothing to do with the initial trigger. This is stuuuuuupid to me, and hijacking my needs. I'll make the changes needed thanks.
Is there a reason the logic was designed like this that I'm not seeing?
I'm not a programmer by any means, but I've been around webCoRE for a few years. There is a task cancellation policy (TCP) that in theory would do what you'd like... run the whole deal without being cancelled. I don't know if it was specifically designed to cancel when the trigger changes, but I think it only runs one instance of a piston at time. That means if the trigger device changes in any way, the previous instance gets cancelled and the piston runs from the top again.
You can see this in action by watching your webCoRE dashboard when trigger devices change state. Pistons will run, even though they don't get past the IF to do whatever it is they do. I've noticed my pistons to turn lights on when there's motion run when motion becomes inactive as well. Is there motion? No? Ok, done.
That's my understanding of it all, anyway.
