My rule is triggering twice on the same lock event

📐 Rule Machine®
1

I am updating my rules from Rule 2.5 to the new 4.0 rules.

I have the following rule to autolock my doors. This one is for my back door.

image
image.png2001×638 53.2 KB

Have I understood it right that I need the trigger events to be *changed* rather than unlock and closed, so that the "Cancel Delayed Actions" will cancel the delayed events if the door is opened or locked in the meantime?

This seems to work, but upon the lock being auto-locked, I get the rule triggering twice, and I don't understand why. The log is as follows, with the initial state being my door being closed and locked, and then me unlocking the door.

app:6672019-10-23 11:49:17.018 am infoAction: Cancel Delayed Actions

app:6672019-10-23 11:49:17.016 am infoAction: ELSE (do actions)

app:6672019-10-23 11:49:17.014 am infoAction: Run Actions: Door left unlocked notification (skipped)

app:6672019-10-23 11:49:16.980 am infoAction: Lock: Back door lock (skipped)

app:6672019-10-23 11:49:16.976 am infoAction: Delay 0:02:00 (cancelable) (skipped)

app:6672019-10-23 11:49:16.974 am infoAction: IF (Back door lock unlocked(F) AND Back door contact sensor closed(T) [FALSE]) THEN (skipping)

app:6672019-10-23 11:49:16.911 am infoDoor left unlocked - backdoor Triggered

app:6672019-10-23 11:49:16.903 am infoDoor left unlocked - backdoor: Back door lock lock locked

app:6672019-10-23 11:49:14.133 am infoAction: Cancel Delayed Actions

app:6672019-10-23 11:49:14.130 am infoAction: ELSE (do actions)

app:6672019-10-23 11:49:14.128 am infoAction: Run Actions: Door left unlocked notification (skipped)

app:6672019-10-23 11:49:14.105 am infoAction: Lock: Back door lock (skipped)

app:6672019-10-23 11:49:14.101 am infoAction: Delay 0:02:00 (cancelable) (skipped)

app:6672019-10-23 11:49:14.097 am infoAction: IF (Back door lock unlocked(F) AND Back door contact sensor closed(T) [FALSE]) THEN (skipping)

app:6672019-10-23 11:49:14.032 am infoDoor left unlocked - backdoor Triggered

app:6672019-10-23 11:49:14.023 am infoDoor left unlocked - backdoor: Back door lock lock locked

app:6672019-10-23 11:49:10.829 am infoAction: Cancel Delayed Actions (skipped)

app:6672019-10-23 11:49:10.826 am infoAction: ELSE (skipping)

app:6672019-10-23 11:49:10.714 am infoAction: Run Actions: Door left unlocked notification

app:6672019-10-23 11:49:10.653 am infoAction: Lock: Back door lock

app:6672019-10-23 11:49:10.628 am infoDelay Over: Delay 0:02:00 (cancelable)

app:6672019-10-23 11:47:02.078 am infoAction: Delay 0:02:00 (cancelable)

app:6672019-10-23 11:47:02.074 am infoAction: IF (Back door lock unlocked(T) AND Back door contact sensor closed(T) [TRUE]) THEN

app:6672019-10-23 11:47:01.948 am infoDoor left unlocked - backdoor Triggered

app:6672019-10-23 11:47:01.931 am infoDoor left unlocked - backdoor: Back door lock lock unlocked

As can be seen from the log, it triggers on the Backdoor lock being locked at 11:49:14.023 and 11:49:16.903 but the rule only executes one lock action.

The back door lock event also shows two lock events though:

Name Value Unit Description Text Source Type Date
lock locked Back door lock was locked by digital command DEVICE digital 2019-10-23 11:49:16.841 AM BST
lock locked Back door lock was locked DEVICE 2019-10-23 11:49:13.933 AM BST

Any ideas why I end up with two events? Note that one was by digital command and one wasn't, which seems odd.

2

I would say it runs double because your rule, trigered by lock change, changes the lock, witch triggers the rule.
Try it by set it on opened as trigger.
The timer shoud be in any case cancable.

Those are your triggers in your current rule. First it states unlocked, second it states locked...

First:
app:6672019-10-23 11:47:01.948 am infoDoor left unlocked - backdoor Triggered

app:6672019-10-23 11:47:01.931 am infoDoor left unlocked - backdoor: Back door lock lock unlocked

Second:
app:6672019-10-23 11:49:14.032 am infoDoor left unlocked - backdoor Triggered

app:6672019-10-23 11:49:14.023 am infoDoor left unlocked - backdoor: Back door lock lock locked

I guess the hubitat team has a system to prevent such things, otherwise it coud generate an infinit loop.

1 Like
3

I cannot use "opened" as the trigger, because then if the door is closed the rule won't trigger, and it needs to trigger on closing the door so that the delayed actions can be started.

Those two triggers you mention are the ones I expected. The rule locks the door and triggers itself, at 11:49:14.023. But it it the final trigger below, at 11:49:16.903 that I was not expecting.

4

Yeah, I meant unlocked or contact changed as trigger.

5

After some more testing I think the rule is not the problem.

I think it is triggering twice due to another issue in Hubitat. Programmatically locking my locks seems to trigger two events. It's even occurring if I do it via the device web page. And the same with unlocking programmatically. Manually locking/unlocking the lock by hand does not trigger two events.

I've tested this with my other locks as well, and the same thing happens, even when there are no rules for the lock.

This didn't used to happen, so maybe it's something in the recent update.

I'll start a new thread: Getting multiple lock events when programmatically locking/unlocking locks

6

When you say "two events" do you mean two entries in the events list or two individual event? I would try this....put a rule in place to count the events.

Trigger: Lock unlocking

Action +1 to a local variable with the starting state of 0.

Then unlock the lock. If the variable is 2, you have double events. If it's 1, then it's just a logging thing.

7

Two individual events. It's why I noticed it, as some of my rules were being affected and running twice.

But good idea, To confirm, I created a rule like you described to count the events and it's 2, so double events.

8

And the lock has no apps at all assigned to it?

9

The only app is Lock Code Manager. And I tested with my newest lock, which has no other rules associated with it yet.

If you look at the log in my new thread Getting multiple lock events when programmatically locking/unlocking locks then you'll see it's odd that one event is sometimes digital type and the other not.

10

Well, the lock is reporting back that it actually locked but that shouldn't be interpreted by the driver as a second event. What driver are you using?

11

The generic zigbee lock driver

12

You never mention what lock it is.

13

Sorry, I listed it in the other thread, Yale "YRD256 TSDB".

But I see there was a new Yale driver introduced at 2.1.4, Yale Zigbee Lock (YRD210, YRD216 and YRL236, YRL256). My lock isn't in that list, but if I switch to that driver, the double events go away.

So looks like something changed in the Generic Zigbee Lock driver that is causing these double events with my lock, and the other driver doesn't have the issue.

Not sure how compatible that Yale driver is with my model, as it's reporting the battery level as an impressive 126% :smiley:

15

I'm 99% sure you should use the yale zigbee lock driver. The only difference between the L and the D is that the L is the lever and D is the deadbolt. The network modules are the same.

1 Like
16

Why did you never mention this before?!?!? You found the bloody solution yourself a long time ago.

17

I only just found out there was a new Yale driver...

Previously Hubitat staff told me to use the Generic Zigbee Lock driver for my model lock, and they associated the lock signature with that driver. That driver was working fine until I updated to 2.1.5 on Monday.

18

There is a battery reporting error in the Yale Lock driver which I tagged @mike.maxwell about. When using the Yale Lock driver, the battery either doesn't report correctly or reports 200%. I'm using the Generic Zigbee Lock driver until the Yale driver gets fixed.

1 Like
19

Which model is listed in the data section of the driver?

20

image

With the Yale Lock driver, I get this for a battery report:

image

With the Generic Zigbee Lock driver:
image

2 Likes
21

Okay....but that driver gives double events. The OP said that switching to the Yale driver removed the double events. So, I guess until the Yale driver is fixed you either have double events or accurate battery readings.

1 Like