I was thinking about that after I typed that reply, but wasn't 100% sure... I've never sent events to devices from apps. At least not like that - I'm typically issuing commands, which then of course make events.
Thanks for confirming! I knew someone smarter would chime in if I said something incorrect.
That is the quirk of using a state/change based logic tool like Reactor with a hub that is fundamentally event driven. Yes the states usually do what you want/follow the events, but not always... It also becomes troublesome if you want to re-trigger something that does not change state - like multiple consecutive "ON" events on a switch.
How would I go about doing this? If I am mentally following you correctly. After my lock is unlocked by person B, I could send an event that person None unlocked it? That way consecutive unlocks by the same person would trigger?
That's the idea. Could have the app subscribe to either the unlock event or the lastCodeName update event and then x seconds later send an event to set the lastCodeName attribute to some other value that you could ignore. Could also make it a manual reset or give you the option to do both by having it create or use a momentary button device.
Only restriction is that the app has to run on the same hub as the lock (sendEvent doesn't work across Hubmesh from an app to a device.)
I have a lot of rules running for Kwikset locks. There may be another completely different way to achieve what you are trying to do. It appears that you are using the change in LastCodeName as a type of event trigger, but then it doesn't trigger if the same person unlocks the lock.
In Rule Machine, I have a rule that triggers on any lock "change", then captures %text% in a Hub Variable string (LastLockEvent) which is the full text description of the last event.
From this text you can pretty much pull out any type of lock/unlock action and use it as the basis for a condition to further refine your rule. You can also just report out that string which gives you the full description of the action. My reports just provide %date% %time% %text%.
Unlocked by a code will include the name associated with the unlock code (LastCodeName). However it also captures "(door name) was locked via keypad [physical]"; "(door name) was locked manually [physical]" and "(door name) was unlocked manually [physical]"
Using the 'change' trigger should trigger your rule, then using the full event text should provide you additional items to search on (such as '[physical]') to further refine what you are trying to do.
Scanned the code and the only things that sticks out to me are "Contact" references that may actually only be labels. But this could be intentional. Line 63 "Contact Sensors Selected" and line 103 "Close Contact Button".
If I understand this app, it's a virtual button that will assign itself to the lock chosen, that when pressed will overwrite the LastCodeName value with "nameOverride"? So if I had two locks, I would have two "reset" buttons?
Yes. You are correct. The learning curve for Rule Machine is steep for me. I have all my logic in MSR (Multi-System Reactor) since I am straddling two HA hubs. I also have a family vacation home with a Vera hub that I will eventually move to HE, but I may not have the luxury of having MSR there. Right now I have the Reactor plugin and mentally trying to determine how to migrate those rules to Rule Machine. Trying to keep things simple there with a single unit there too.
I am very interested in seeing more of your rules on how to accomplish what I am after. Two examples for my vacation home.
I have my Vera watching a calendar. If an event with a keyword is detected AND the lock code updates/changes AND the lock changes from "locked" to "unlocked" AND the mode is Vacation, then run a number of commands, change the mode to Home, and notify me LockCodeName arrived.
And the reverse. When the keyword is no longer detected AND the lock is locked AND mode is Home, then run some commands, set the mode to Vacation, and notify me that LockCodeName has left.
I'm assuming that the above two examples would be two different rules in Rule Machine, correct? I have the calendar watching event figured out by the Google Calendar Search app. It's the Rules and the changing of locked to unlocked with the AND triggers I'm still wrapping my head around. And since a picture is worth a lot of words, like I just typed out.
Lots of way to break down RM. I find that multiple smaller rules that stack/call each other makes it easier for me to break up a complex rule into smaller easier to code individual functions. It's also easier to identify parts that aren't working as you designed. Others prefer a single more complex rule to keep the total number of rules they manage smaller.
Happy to provide examples, I'll cut and paste some here. Also check out the post below. I put several rules in there that I used to code a z-wave keypad to operate a garage door, and I included quite a bit of explanation/documentation. Not exactly what you are doing, but it has examples of how to integrate connect several rules, use hub variables and connectors, etc. The keypad also functions as a lock (uses the same generic lock driver), so much of that is similar.
Final point - if you haven't installed the HE lock code manager app, I'd add that in for your locks. It's not really used in conjunction with any rules, but it's a great app for managing your lock codes. It can be used across multiple locks and multiple users in any combination.
Thank you. I will definitely look at your other post. Just the other day my daughter was asking if we were ever going to put our garage door keypad back up. I hadn't thought of using a Z-Wave keypad to control the GDO instead.
And yes, I do have LCM installed and really like the functions. I'm having some minor issues with it though, noted in this thread. And it doesn't always complete the jobs. Just this morning one of my Enable On tests failed and I needed to Retry the Failed job.
[app:6](http://192.168.0.14/logs#app6)2021-10-20 11:09:25.756 am [info](http://192.168.0.14/installedapp/configure/6)jobs:1
[app:6](http://192.168.0.14/logs#app6)2021-10-20 11:09:21.736 am [debug](http://192.168.0.14/installedapp/configure/6)processJobs- remaining:1
[app:6](http://192.168.0.14/logs#app6)2021-10-20 11:09:21.728 am [debug](http://192.168.0.14/installedapp/configure/6)processJobs- Garage Door Handle.setCode(5,xxxxxxx,Joanne, try:7)
[app:6](http://192.168.0.14/logs#app6)2021-10-20 11:09:21.725 am [debug](http://192.168.0.14/installedapp/configure/6)processJobs- try job:[262_5:[code:xxxxxxx, name:Joanne, codeState:pe, retry:6]]
[app:6](http://192.168.0.14/logs#app6)2021-10-20 11:09:21.723 am [warn](http://192.168.0.14/installedapp/configure/6)processJobs- job stuck:262_5={code=xxxxxxx, name=Joanne, codeState=pe, retry=6}
[app:6](http://192.168.0.14/logs#app6)2021-10-20 11:09:21.721 am [info](http://192.168.0.14/installedapp/configure/6)getLockCodesFromDevices- complete
This is an Away Manger rule I made which sets MODE to current time of day if known individuals unlock a door or open a garage door. Otherwise when they close the door and lock the house it sets mode to AWAY. Mode Manager can handle a lot of that, I built these rules before that was available and haven't ventured into that:
Note this rule uses the text captured in LastLockEvent.
I manage my modes with three rules for Day/Evening/Night which set the mode and associated boolean hub variables based on time of day. Day - sunrise to 30 minutes before sunset, Evening - 30 minutes before sunset to 30 min after. Night, 30 min after sunset to sunrise. The hub variables (DAY/EVENING/NIGHT) just are true, which then captures the current correct mode when not away. AWAY is a rule tied to a virtual switch that when on sets away, when off sets the mode based on the boolean hub variables. Here is the AWAY rule and one of the time of day rules. This is used in conjunction with the away manager.
I have auto-lock rules which automatically close the garage door and / or lock the doors if they have been unlocked more than 30 minutes during the day, or 10 minutes nights/evenings or away. These are controlled by predicate conditions which are both tied to a virtual switch (to turn off the auto-lock function) and based on the appropriate mode (time of day / away) to control which rule is active. Here are both:
Lastly - I found that the NOTIFICATIONS app was much more effective and easier to make notifications. I also have those tied to a virtual switch which you can use to turn notifications on or off for an individual device (my and my wife's phones). Here's a simple notification app 'rule' which notifies my phone of the lock event.
I found my z-wave keypad on AliBaba, took a while to get here and has worked well in the integration. Further up in that same post I have pics and details how I installed it. More recently I understand others have used the RING security system keypad as a stand-alone z-wave keypad, but I haven't tried it.
The z-wave keypad is paired with a go-control z-wave garage door controller which has worked well. The controller is an add-on to your regular garage door opener. You'll see timer delays in my garage door code, that is to allow the door to fully open/close, and in another case to account for a built in delay in the garage door controller between successive commands.
I installed the app and from what I can tell, it is working. I changed the number of buttons to 1, as I only need 1. When pressed it does change the lastCodeName to None.
However when I press the Send Last Code Name Event button from within the app, it gives " An unexpected error has occurred trying to load the app. Check Logs for more information." But I don't see anything.
That is very much like what I'm doing for two homes we're managing. One is my mother-in-laws former home which is being watched by a housekeeper and other friends in the local area since she's moved into assisted living, the second a rental home that is currently under renovation.
The Away manager does the mode management you describe. All the notifications are made through the notifications app which just texts me every time a lock is locked/unlocked. I should have included in the lock notifications that there are also separate texts that indicate when the locks are controlled by a digital command vice physical. Garage door notifications are more complex and handled by the sequence of garage door rules.
The mode is managed through the locks by what the individuals need to do entering or leaving the home. Entering - they either need to unlock/open the garage door, or unlock an exterior door. This is always by code, and I identify those individuals by LastCodeName that I want to set the mode (AWAY OFF). When leaving, they have to lock the door leading to the garage (on Kwikset this is done by pressing the single LOCK button which is recorded as PHYSICAL) and exiting through the garage, then closing the garage door; or alternatively if the garage door is closed, by exiting and locking the front door. The conditions track these actions very well.
Sounds like there are many ways to accomplish what I am after. And just for clarification, "Away manager" is the same has Mode Manager, correct?
I am very interested in learning how to read this into a rule/trigger. This is one thing that the Vera has over HE. When the physical lock button is pressed, the vera will set a variable "sl_lockButton" equal to 1. This variable is missing from HE's generic lock driver. And with my lack of knowledge how to read the "digital" event, I can't distinguish how the lock was locked. Only that it is locked. I have a need to trigger events based on the actual button being pressed.
AWAY MANAGER refers to my RM rule copied in the post above. MODE MANAGER refers to the HE built in ability to do mode management. I haven't used it, just seen others reference it.
When you command a lock, the %text% description states "(lock name) was locked via command [digital]" or 'unlocked' as the case may be. Again, you can use RM conditions with the string variable and 'contains' to use these in conditionals, similar to what I've added in the AWAY MANAGER rule (the second rule in the hidden portion of the post above).
My rule referenced above checks for 'physical' in the text description. You could also easily just check for 'digital' for a commanded lock/unlock. My lock timer generates those events, also when I use the dashboard or HE app to lock/unlock remotely.
Thank you! I hadn't expended your example yet. I just started reading it and realized it answered all my questions from the previous post. I'm sure I will have more as I go through that, but what I have seen so far looks very promising to what I am after.
Thank you both @demillerusn and @thebearmay. I know this thread went down a couple of rabbit holes, but you have both been awesome at helping me understand and working to move me off of my dying Vera platform.
Thanks for this. I used to have go-control GD controllers. They both had issues either remaining connected or actually controlling the door. Lastly, they outright refused to pair to either my Vera or HE. I recently removed them and put in Zooz Zen17 relay switches with two contact sensors to determine fully open or fully closed. Using a virtual GD Controller switch and the MSR logic, it's pretty solid, so far. I'll add the keypad to my to-do list.
I had to replace a go-control controller once or twice, actually an IRIS controller when Lowes still sold those (effectively the same), but haven't had issues otherwise. I have noticed that their version numbers keep going up but haven't seen any real hardware changes except going from z-wave to z-wave+.
I like they not only report OPEN/CLOSED, but also OPENING/CLOSING during operation, and easy to install/integrate. I also have a Zen17 relay, but haven't tried it. As long as the Go-Control keeps working anyway...
It also becomes troublesome if you want to re-trigger something that does not change state - like multiple consecutive "ON" events on a switch.
