Conditions not met, piston firing anyway - worked correctly for many months but no longer

#1

1) Give a description of the problem
Piston design locks front door lock after 180 seconds if the door sensor is closed and the lock open (or unknown status). Piston worked correctly for the past many months; suddenly in the past week or so, it is locking the door even if the contact sensor is open.
I will attach logs later.

2) What is the expected behavior?
Door lock should remain unlocked if the door sensor is open.

3) What is happening/not happening?
The lock is occasionally locking, even when the sensor is open.
Sensor record shows no sign that it ever appeared closed while these errors occurred.

4) Post a Green Snapshot of the piston![image|45x37])
(UPLOAD YOUR IMAGE HERE)

image
D4648C6A-5697-4CDB-A7AA-BD4A8D7ED10A.jpg2732×2048 270 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
(PASTE YOUR LOGS HERE BETWEEN THE MARKS THEN HIGHLIGHT ALL OF THE LOGS SND CLICK ON THE </> ICON TO FORMAT THEM)

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

Lock No Long Auto-locking
#2

Doubtful anyone will be able to help you without logs posted.

#3

May try changing the IF statements to a trigger rather than a condition.

So … If Front Door Iris Sensor’s contact changes to closed …

#4

I already have a routine that accomplishes that.

The piston you see here is for the following scenario: what happens if, by some chance, someone unlocks the door… but does not open the door? In that situation, absent such a piston the door could easily remain unlocked all night long. Or perhaps I’m on my way out to work, unlock the front door… but at that moment remember I have to take out the garbage. So I go get it, and exit via the back door to my garbage pail and head straight to the car and to work - the front door would sit, unlocked, all day long.

The other thing it does is this: when the door is unlocked by the return of a presence sensor, it gives a three minute “grace period” for that person to go in the front door before it re-locks.

Thus this piston, which says ‘if door is closed and lock is not known to be locked, then wait three minutes and then lock the lock”.

Except recently it locked the lock even though the door was open.
I will post a log the next time it occurs. Too many personal things occurring in the family this past weekend for me to track down the moment it occurred.

#5

Then how about … “If Front Door Lock’s lock changes to unknown, unlocked or unlocked with timeout” and “Front Door Iris Sensor’s contact is closed.”

Either way, I think you need a trigger as a listener.

I would have a trigger that’s simply “If Front Door Lock’s lock changes” then "If Front Door Iris Sensor’s contact is closed and “Front Door Lock’s lock is any of unknown, unlocked, or unlocked with timeout” then “Wait 180 second …”

#6

J, thanks. But it worked this way for months, so I think I have a rational position to imagine that it would continue to work based simply on conditions.

Here is the log. Notice that at 7:07:43 +800 the front door sensor opens.
It has not closed when, at 7:10:42 +279, we get Executed Front Door Lock.

6/8/2018, 7:10:46 AM +943ms
+1ms ╔Received event [Front Door Lock].lock = locked with a delay of 161ms
+263ms ║RunTime Analysis CS > 29ms > PS > 113ms > PE > 122ms > CE
+266ms ║Runtime (39952 bytes) successfully initialized in 113ms (v0.3.104.20180323) (263ms)
+267ms ║╔Execution stage started
+281ms ║║Comparison (enum) open is (string) closed = false (2ms)
+283ms ║║Condition #6 evaluated false (11ms)
+284ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+286ms ║╚Execution stage complete. (20ms)
+288ms ╚Event processed successfully (287ms)
6/8/2018, 7:10:42 AM +279ms
+1ms ╔Received event [Myhub].time = 1528456243583 with a delay of -1304ms
+205ms ║RunTime Analysis CS > 22ms > PS > 81ms > PE > 101ms > CE
+207ms ║Runtime (39951 bytes) successfully initialized in 81ms (v0.3.104.20180323) (205ms)
+209ms ║╔Execution stage started
+222ms ║║Cancelling statement #4’s schedules…
+1907ms ║║Executed physical command [Front Door Lock].lock() (1681ms)
+1908ms ║║Executed [Front Door Lock].lock (1683ms)
+1911ms ║╚Execution stage complete. (1703ms)
+1912ms ╚Event processed successfully (1912ms)
6/8/2018, 7:07:43 AM +800ms
+2ms ╔Received event [Front Door Iris Sensor].contact = open with a delay of 700ms
+284ms ║RunTime Analysis CS > 20ms > PS > 124ms > PE > 139ms > CE
+287ms ║Runtime (39960 bytes) successfully initialized in 124ms (v0.3.104.20180323) (283ms)
+288ms ║╔Execution stage started
+300ms ║║Comparison (enum) open is (string) closed = false (2ms)
+302ms ║║Cancelling condition #6’s schedules…
+303ms ║║Condition #6 evaluated false (9ms)
+304ms ║║Cancelling condition #1’s schedules…
+305ms ║║Condition group #1 evaluated false (state changed) (11ms)
+308ms ║╚Execution stage complete. (21ms)
+309ms ╚Event processed successfully (309ms)
6/8/2018, 7:07:43 AM +294ms
+1ms ╔Received event [Front Door Lock].lock = unlocked with a delay of 191ms
+252ms ║RunTime Analysis CS > 27ms > PS > 122ms > PE > 103ms > CE
+254ms ║Runtime (39957 bytes) successfully initialized in 122ms (v0.3.104.20180323) (252ms)
+255ms ║╔Execution stage started
+270ms ║║Comparison (enum) closed is (string) closed = true (2ms)
+271ms ║║Condition #6 evaluated true (10ms)
+277ms ║║Comparison (enum) unlocked is_any_of (string) unknown,unlocked,unlocked with timeout = true (2ms)
+279ms ║║Cancelling condition #7’s schedules…
+280ms ║║Condition #7 evaluated true (7ms)
+281ms ║║Cancelling condition #1’s schedules…
+281ms ║║Condition group #1 evaluated true (state changed) (20ms)
+284ms ║║Cancelling statement #2’s schedules…
+288ms ║║Executed virtual command wait (0ms)
+289ms ║║Requesting a wake up for Fri, Jun 8 2018 @ 7:10:43 AM EDT (in 180.0s)
+294ms ║╚Execution stage complete. (38ms)
+295ms ║Setting up scheduled job for Fri, Jun 8 2018 @ 7:10:43 AM EDT (in 179.995s)
+304ms ╚Event processed successfully (304ms)

Here’s the IDE log for the contact sensor:

2018-06-08 7:15:10.893 AM EDT
1 hour ago DEVICE contact closed Front Door Iris Sensor was closed true
2018-06-08 7:07:43.100 AM EDT
1 hour ago DEVICE contact open Front Door Iris Sensor was opened true

#7

I deleted the contact sensor condition and saved - then re-added the contact sensor condition and saved. Then I resumed the piston.
Let’s see if anything changes.

#8

Followup: it didn’t work.

Also, it does not look like the lock, or sensor, or their DTHs.
It seems to be simply saying “lock is unlocked or unknown, count 180 seconds and lock the door” with no regard for the status of the sensor.

#9

Here are my door scenarios:

  1. If contact changes to closed, count two seconds and lock the lock. (this works all the time.)

  2. If contact is open, lock remains unlocked. (this worked until this recent issue.)

  3. If lock is found to be unlocked** and contact is closed, count 180 seconds - if contact remains closed during that time, lock the lock.

**note that this needs to be a state and not a trigger, as the state encompasses all kinds of possibilities:

  • presence arrives and unlocks the lock, but door does not get opened
  • person inside unlocks the lock, but does not open the door
  • lock battery replacement with sensor closed but lock unlocked

If anyone here has a better way of writing a piston to accommodate the third item, I’m all ears.

Edit: I changed it to say “if after the 180 seconds are complete the sensor is closed, then lock the lock.”
Will see how it goes over the next few days.

New Edit: final thoughts on what occurred here, and on my solution.
In looking again at the log, webcore got the update for lock=unlocked a few milliseconds before getting the update for sensor=open. So since it saw the lock open and the sensor closed in that moment, it started the 180 second countdown. And without a new update on the sensor within that 180, it locked.

Don’t know why that changed from the previous many months, but it did.
So by re-introducing the check to see whether the sensor is closed after the 180 seconds have passed, it now will not lock the lock unless the sensor is indeed closed.

I guess the lesson is that, for any piston with a timer, re-check conditions after the timer has finished its countdown.