I’m trying to set up a rule that turns on a light when my front door is unlocked from the outside but the lock code condition isn’t behaving like I thought it would.
I’m seeing that *any lock code* is showing as true even though the last lock action was to manually lock the door from the inside.
Is this intended and if so, does anyone have advice on how to accomplish such a rule? Is there a way to detect “manual” locking (it’s logged but I don’t see it as a criteria in a condition)?
Use a trigger, where the trigger is the lock unlock by code.
I think this is what you want.
Any lock code will always be a true condition, because ANY is the same as every, and that’s always a true condition. Versus something like, the door is currently unlocked, or locked. The idea of showing you the true or false state of a device is really to show you that the device is working the way you expect (ie it is in the state you expect as you’re building the rule) and it helps you determine how the rule should be built. For example, if my door sensor is in a false state and it shows that the sensor is open, then I would want to make sure that my rule said that the sensor should be closed to give me the true state. Therefore my actions for true will occur when the sensor is closed, not when it is open, as would be the case for most door sensors.
This actually is what works for me:
I hadn't tried a trigger or triggered rule. I'll give that a shot and see if it'll do what I want.
You should only need a trigger (not a triggered rule) as detailed in my screenshot above. Once you do that, you can select the actions you want (turn on lights, etc.).
A trigger works fine for my basic need of turning on a light but there are still some other things I’d like to do where it would be simpler if there was a way to tell that the lock was manually controlled (from the inside). @bravenel is this possible at all?
Also, I noticed lock codes is an event in a trigger but not triggered rule. Is there a reason it’s missing there?
Your lock might not be sending the info back. I have a Yale YRD256, using the Generic Z-Wave Lock driver, and it shows that state instantly.
If your lock shows the locked/unlocked state in the driver when it is manually manipulated, then you can use that state for the condition as I showed you in the example.
It looks like it sends that event; see line six in the log in my initial post. I do not see “manual” in the list of lock codes and unlock is triggered regardless of how the unlock was done.
Ah OK, I understood that you wanted to know when the lock had been manually manipulated. You want to know if the lock has been manually locked/unlocked vs unlocked by code?
I'm not aware of any way to do that. It's possible to be notified of which person unlocked by code, or if anyone unlocked by code, but there's nothing that can determine if the lock was specificially unlocked manually, and not by a code. It's always going to report that it was unlocked or locked if you use that condition.
Right, I was hoping someone knew of a trick to do this or, since it's logged as being locked/unlocked by "manual", that it could be added as an option in a future change.
And while I don't need it now, I am curious why "Lock Codes" is not an option for Triggered Rule (deliberate or accident?).
The trigger works fine for my simple case of turning a light on. But I have another use case I'm attempting to get working and it's more complex...
I currently use HSM but w/o a keypad (relying on presence currently) and we're leaving for a few days but have a pet sitter. So what I want to do is disarm HSM when the sitter enters the code and then arm it again when they leave. The problem is that if I simply arm when locked then it'll naively arm when locked from inside as well as outside and thus arm when they're present.
I can probably make this mostly work using a private boolean but it's a bit fragile. e.g.,
- trigger key code unlock then set private boolean to true and disarm hsm
- triggered rule door locked - if private boolean is true: set to private boolean to false else: arm hsm
I'm additionally restricting the above to only work while a virtual switch is on (which I'll set for this duration).
It's easy to mess this up if someone locks/unlocks/locks from the inside (not sure why they would but I stopped trying to predict behavior) and so I was looking to see if there were ways I could detect the manual lock/unlock.
1 Like
Probably should be for consistency sake, but doesn't really need to be. I shows up in a rule and the net result would be the same as if you were to use it in a triggered rule.
You can have the condition for locked by code to trigger an action. Not sure what the issue is? Are you trying to do this in a single trigger or rule (if you need some complex actions)? Make two rules instead. One for unlock by code and the action is disarm, and one locked by code and action is arm.
Make sure you test this well before leaving the sitter to fend for themselves! You might want to make sure you have a Hubitat Cloud dashboard setup with a switch to Arm/Disarm HSM, just in case you get a panicked phone call with the alarm going off in the background!
Sorry for the confusion; what I outlined is two rules and does work mostly it's just easy to get it in an inconsistent state which is why I was looking for more options. So no issue other than it's possible to "trick" the rules into arming HSM if you toggle the lock manually from the inside.
As for testing, I not only have a dashboard to disable this but at this point the "alarms" aren't noise based so the sitter impact is small 
If I can't get it ironed out to my satisfaction prior I'll just disable it entirely when we leave.
1 Like
I see. Yes, unfortunately lock keypads just aren’t a great choice for alarms. I use presence to disarm, but arming is always manual. I also don’t use HSM for intrusion security. I use a stand-alone connected alarm.
Dedicated keypads are what most use for HSM, but there’s not a lot of choices there right now. Hopefully Ring alarm system will be a supported integration in the future, and I will probably move to that when it comes.
