I can’t figure out how to set up rules for locks. Such a basic security thing, I think I must have missed something. I did search these forums and the ADC faqs first though
Relock any door we unlock with lock keypad, after five minutes left unlocked.
Lock all doors when alarm set.
Disarm system on door unlock by lock keypad.
Alert me/prevent locking, if I try and use the app to lock a door that is open (current behavior is to throw the deadbolt into open air, which is disappointing to find later, especially since the system knows from the door sensors that this won’t do anything useful, and even more frustrating because app is frequently out of sync with the panel, so app shows door is closed when requesting locking).
Most lock rules are found under New Rules Builder (Automation > Add New Rule > New Rules Builder)
Relock any door we unlock with lock keypad, after five minutes left unlocked.
Specifically you cant create a rule to lock a lock after its been unlocked but you can lock based on sensor activity.
Using the New Rules Builder (Automation > Add New Rule > New Rules Builder
When: Sensor Closed
Then: Lock X Lock
You can wait 10 seconds up to 40 minutes between the When and Then.
The sensor and lock would be on the same door in this case. (Front Door Sensor, Front Door Lock)
Lock all doors when alarm set.
New Rules Builder (Automation > Add New Rule > New Rules Builder
When: System Armed
Then: Lock X Locks, can select multiple locks.
Disarm system on door unlock by lock keypad.
Under New Rules Builder (Automation > Add New Rule > New Rules Builder
When: Lock Unlocked
Then: System Disarm
Alert me/prevent locking, if I try and use the app to lock a door that is open (current behavior is to throw the deadbolt into open air, which is disappointing to find later, especially since the system knows from the door sensors that this won’t do anything useful, and even more frustrating because app is frequently out of sync with the panel, so app shows door is closed when requesting locking).
You can create notifications to be alerted when a lock is locked, unlocked, or left unlocked for X amount of time.
You cannot prevent a lock from being locked remotely based on sensor activity.
If running into App/Panel lock sync issues:
Verify if the lock status is accurate with the door open. This can indicate the lock latch has trouble fully extending due to available space within the door frame itself.
Eliminate the possibility of Z-Wave communication issues. More on Z-Wave network setup can be found here:
Power cycle the lock and panel, verify that the lock batteries have a strong charge, and then manually lock/unlock to test if the status updates.
Ensure firmware is updated at the panel: Firmware update instructions/patch notes found here:
Do I need specifically something called “New Rules Builder”? I could not find this in the app. I also looked on the ADC website and didn’t see it there either, only a section called Automation. But it seems I can do most of the things you describe from either of those interfaces.
Update: found it in the ADC site, under automations, I misunderstood, I thought New Rules Builder meant an updated version of the old rules builder, or something. But instead I see now that it means " a new rule built using the rules builder."
If running into App/Panel lock sync issues:
Verify if the lock status is accurate with the door open. This can indicate the lock latch has trouble fully extending due to available space within the door frame itself.
Eliminate the possibility of Z-Wave communication issues. More on Z-Wave network setup can be found here:
No the local system works fine, but the application we use to control it does not. The app is often ten of minutes out of sync with the actual panel state. This isn’t a problem with my network connection. Or the cell connection I believe. I think bad programming, or bad UI decisions, at the ADC server side. The result is what I was asking about: locking a door based on ‘closed’ sensor status in the app, when it is actually open (seen on the panel).
The result is what I was asking about: locking a door based on ‘closed’ sensor status in the app, when it is actually open (seen on the panel).
Z-wave automation rules using sensor status do not use cloud status and aren’t impacted by sensor activity monitoring delays. If a rule doesn’t need to involve the cloud, the rule is processed at the panel based on panel status.
Things like third party back end integrations such as with Lutron and MyQ necessarily require cloud involvement for some automation. Z-wave automation generally doesn’t.
As far as using the status in the app to lock the door manually, I’ve never really heard this brought up as an issue in every day use. So that we can best describe the desired use case to ADC, are you manually locking the door via the app frequently based on sensor open/closed notifications after other individuals use the door, etc?
The rule to lock after the sensor is closed may address that scenario best.
I am happy to forward use cases to Alarm.com to consider.
As far as using the status in the app to lock the door manually, I’ve never really heard this brought up as an issue in every day use.
No one forgets to lock a door, ever? And no one uses the app to relock it? And no one trusts the door sensor to tell them it’s closed, before locking, and finds out later the sensor state was out of date? How is it that I am the only one to experience this? Are there troubleshooting steps I should be taking? It appears to me this is a design flaw in the ADC system, but I’m happy to try other things. I would be VERY happy to find that the system design is much smarter than it appears, and I just have some misconfiguration or hardware problems.
So that we can best describe the desired use case to ADC, are you manually locking the door via the app frequently based on sensor open/closed notifications after other individuals use the door, etc?
Yes, more clarification below.
The rule to lock after the sensor is closed may address that scenario best.
Agreed, I’m now trying out the rules you guys have helped me with. These rules for auto relocking should reduce the frequency of need for a manual relock from app and an associated “door closed sensor out of sync” error, thank you. The other thing I’m doing to help work around these bugs is add hydraulic closers to every door.
I am happy to forward use cases to Alarm.com to consider.
Awesome, thanks. To reiterate and clarify for ADC feature requests:
ADC rules are now one IF and one THEN only. Not good enough. They need to expand this (like IFTTT, Zapier, Integromat, Hubitat, Home Assistant, etc.) so we can say: IF it’s been five mins since lock was unlocked AND door is NOT open, THEN relock it.
When using the mobile app, verifying that door sensor is closed, then locking door: it can frequently occur that the bolt is actually thrown when the door is standing open. Because the app is never in sync with the panel or the site; always one to ten mins delay. And worse, multiple sensor state change instances are skipped. To fix: speed everything up by two orders of magnitude. Bandwidth is cheap. Charge us more money. Whatever, we don’t care. It’s supposed to be a security system, not janky, unreliable and insecure, as an artifact of trying to keep costs down. Just insure that the app is always in sync with the true state of the system, within a second or two tops.
I think there may be an unintended consequences problem with the “suppression of multiple signals within some window” strategy. When subsequent on or off signals are ignored, the app can get stuck in an incorrect sensor state indication, for a very long time! These signals don’t occur in pairs! So the indicated state vs the true state is random. Just don’t ignore or suppress any signals, ever!!
No one forgets to lock a door, ever? And no one uses the app to relock it? And no one trusts the door sensor to tell them it’s closed, before locking, and finds out later the sensor state was out of date? How is it that I am the only one to experience this? Are there troubleshooting steps I should be taking?
People do forget to lock their door and do forget to close the door sometimes. Those two scenarios are typically best handled by notifications, specifically left unlocked and left open notifications.
These will notify you when the door is left open or left unlocked for a period of time you set, then you can take appropriate action based on one or both of those being received, rather than actively refreshing and checking the door status.
If your system is having general signaling trouble or the sensors are having trouble reaching the panel with their status then the window for a mismatch status would be wider, but typically it should only be up to 3 minutes if the door is opened, closed, then opened again right away and left open.
Bolts being thrown while the door is open is a very common issue on locks with built in re-lock timers that just count down from when it was unlocked before throwing the bolt.
I understand the desire for a shorter sensor activity delay though in general. It would help remove confusion from a few areas of Alarm.com service. We have brought this up with Alarm.com to request a shorter built in delay for latency etc. I am happy to forward the feedback.
