Auto Door Lock automation issue


#1

1) Give a description of the problem
Right now, with the current piston, there are times when my door will lock even though it is opened. I believe the issue has to do with a condition change and Task Execution Policy or Cancelation. I believe what happens is, I open the door then close it at some point and the timer begins (5 minutes). Within those 5 minutes, I open the door again because, for example, I forgot to get the mail. During the time when the door is open, the timer is never cancelled, it will then execute the lock command even though the door is open.

2) What is the expected behavior?
I want the door to only lock if it is closed. If at some point during this 5 minute wait the door opens again, I want the time to be cancelled. I just can’t figure out at which step I input the TCP or TEP. I also don’t understand if I need to configure the Cancellation or Execution policy.

3) Post a Green Snapshot of the pistonimage

Any help is appreciated!


#2

The general rule of thumb is:

If Sensor's contact stays closed for 5 minutes
Then Lock the door

This way, it will never lock when the door is open, and the 5 minute timer will reset each time the door is closed.


#3

…and this is why I asked! Nice idea. I’ll see if I can make that work. One thing I had built in was the while loop, this way if the piston failed to execute due to latency of some kind, it would continue to evaluate until it was locked. I’d have to see if I can somehow build that in to this way as well.


#4

So, I’ve been working at this and it appears that the piston will cancel the job if the door is opened during the timer. I verified this by duplicating the piston and using simulated devices while monitoring. Therefore, there is something else going on regarding this piston that is allowing the door to lock when it’s in the open position.

One thing I noticed is the ā€˜load time’ is pretty high at times. See the image below:

Could this have anything to do with my issue?

Thanks!


#5

If you followed my advice above (stays closed for 5 min etc) then, yes, you are correct. The 5 minute timer resets if the door is opened. A new 5 minute timer starts when the door is closed. If it remains closed for the entire 5 minutes, then it locks the door.

My first thought might be one of your other pistons or Routines triggered that lock. I guess to keep it simple though, I should ask to see your latest green snapshot of the piston in question.


#6

@WCmore, from my understanding, if I ran the piston the way you’ve designed it and the door meets the condition, but fails to lock (re: latency, or some other issue) then the door will stay opened; meaning it will not be evaluated again until one of the devices involved (contact sensor or lock) changes state, causing the piston to re-evaluate, correct?

My goal is to have a rule that will always lock the door when in a closed/unlocked state, even should the initial action fail for whatever reason - which is why I went with the do-while loop.

With that said, during my testing using the simulated contact/lock, I did all of the testing using the do-while loop. My revelation was that the do-while loop performs exactly as I want it to, including canceling the scheduled job if the state changes make the evaluation true. So the problem of the door locking while open is not because of the scheduled job not canceling. Then I noticed the high semaphore times and the load times, which spawned my latest question.

I hope that clears up my current state and troubleshooting path.

Thank you!
John


#7

There is definitely truth to what you are saying. Perhaps the red flag is that the do-while loop you are creating is likely a factor in your latency. (as seen in your semaphore delays)

This is why I try to simplify the code as much as possible.
You could modify my earlier suggestion a tiny bit:

If Sensor's contact stays closed for 5 minutes 
Then Lock the door
Wait 2 seconds
Lock the door
End if

This double lock command should resolve any latency issues that may arise… For extra peace of mind (with something as important as a door lock), I would also have a few other pistons lock the door at a few other events. (such as in your good night routine, etc) This would effectively be a double safety net to catch the rare ā€œlatency, or other issuesā€ to make sure that your door was locked.

I am not trying to discourage your path, but I personally try to avoid do-while loops whenever possible.


#8

See if you can use this in your simulator… you can trim out the last IF at the bottom, I use it when the door gets jammed. I haven’t touched this one in a while, it could probably use an upgrade lol.


#9

Interesting code - Thank you! I’ll definitely play around with that.