Issues with multiple lock commands


#1

I am running a "good night" type rule that shuts some lights, closes my garage, and locks my locks. I am noticing that the locking is very sporadic, and usually only 1 of 3 locks will actually lock.

I also tried taking the code out of RM and just using button controller directly, but same result. Using 2x Yale T1L and 1x Kwikset 910. All are securejoined and work if toggled manually. I also get proper status updates when actuating the lock manually, so I don't believe it's a mesh issue. House is also not that big and I have z-wave plus outlets near each of the 2 inside locks.

Here's the RM rule, and some logs

Commands issued

Front Door (which worked)

Side Door (which did not)

Outside room did not receive any commands at all, so no logs. The only reason Side Door had a log is because I unlocked it first to test the trigger.

Any ideas on how to resolve this? I can split the RM into 3 separate actions, but that seems clunky. Like I said, using Button Controller didn't help.


#2

I'm not saying you should
have to do this, so perhaps someone else can offer better ideas, but have you considered not just splitting your lock commands into three separate ones (pretty sure that would behave about the same) but maybe inserting a small delay between the three? (I'm not sure if that's what you meant with "split the RM"--no need to make a separate rule, just rethink the actions.)

For the underlying issue, what kind of repeaters are you using? I know you said Z-Wave Plus, which is good, but do they support beaming? This will save the hub some work (beaming hasn't been required for repeaters for quite as long as Plus, if I recall, though it's been around for longer and some classic devices do support it). More than two repeaters also might be good if you have challenging architecture or a lot of space, though these problems are hard to diagnose and it seems unlikely given it seems to otherwise work...


#3

GE dimmers, the newer 14xxx series.

Aside, the locks work fine when toggled from the dashboard, fast. They update status when manually turned, fast.

It's just the RM/Button Controller processing where it gums up.

Also, house is not that big, 1500sq ft. These locks are line of sight and less than 30 feet from the hub and less than a foot from each zw plus dimmer.


#4

My thinking is that three more or less simultaneous commands might be gumming things up, hence my suggestion for a small delay between the three. This (total guess, by the way) is consistent with your observation that everything works if initiated manually one at a time.


#5

I’ll give it a shot when I get back home today. I’ll just do 3 separate lock actions with a 5 second delay rather than one action with all 3 locks.


#6

I can't get the delays to work properly. They seem to all count as one big delay... It seems to just take one 5 second timer from the time of the button press.


#7

Here is what I did:
lockdown


#8

I don’t have sensors on those doors but I’ll try using IF blocks to see if the timers apply. Do you actually see the timer running in the logs?


#9

The timer blocks delay a certain amount before allowing the next action. I wonder if the delay just delays that action but does not block the next.


#10

Yeah I’m not sure. I changed the delays to waits in my testing as well, but no difference.


#11

Try staggering your delays. First one 5 sec. Second 10 sec. Then 15 and so on.


#12

Not sure what you tried after this, but the behavior you're seeing with the rule as specified is correct. All of your "--> after a delay of 0:00:05" actions will run 5 seconds after the previous action (the one before all of these)--they don't "block" each other. You can get around this by using a progressively longer delay on each action, or you can put a dedicated "delay" action between each instead of specifying it on the actions themselves.


#13

You should try Lockdown