Does it report the keypad status to Hubitat? I’m using some Iris keypads outdoors and this can be a viable replacement
It’s showing a timestamp for communication both to/from the device when I lock or I lock through the device manager, but no information coming in (status/user codes/last event/etc). From looking at the manual the info should be there. As I tried alternate lock devices, some of the additional fields showed up (status: locked for example) but they never updated with the correct info.
I ordered an iris keypad yesterday to try. I was wondering about the weather resistance, they appeared to be designed more for indoors. I presume no issues?
Would really like to get these keypads working, would be nice to have it hard wired with no batteries. I suppose I could do the same with an iris, though.
I have to think it’s just something in the driver that isn’t configured to read the data coming back. Either that or the secure inclusion. The manual does say it’s functions are limited if it’s joined without security, but the status reports secure inclusion successful.
However it seems odd the data wouldn’t be coming back otherwise. The communication protocols are pretty standard. Writing drivers is outside my ability, although I may be able to pull one apart that’s close...
Success.
I may have gotten here the hard way, but I have two keypads fully working now. I was able to get the first one working and repeat the steps to add a 2nd keypad.
It appears the z-wave configuration was incomplete when I added the keypad. I'm not sure if the generic z-wave lock configuration button would work to repair the configuration, it didn't appear to previously and I haven't gone back to try it.
I was searching and found this Z-Wave device driver tool referenced in the devices topic. I installed it to try troubleshooting the keypad, and it appears to be the key (or at least one way) to get the keypad to work.
Thanks @mike.maxwell
The BasicZWaveTool is added to custom device drivers. Driver import link here:
Once saved, the device shows up at the bottom of the devices list under 'User'.
The keypad seems a little finicky to add, I had to add it near the hub, it wouldn't add or exclude from my room upstairs even though I have several z-wave plugs/repeaters nearby. No indication it is using low power inclusion, I suppose that's possible. I removed and re-added the keypad, and this time set the device driver as the BasicZWaveTool. The display looks like this:
Noting that I wasn't going to set any parameters, I clicked through the top row of GETs. When I checked the logs, I noticed that each of these returned responses. Other drivers never got this far.
I changed back to the Generic Z-Wave Lock driver, and when I clicked unlock, it immediately brought up battery 100 and state - unlocked. A few trial/error clicks (get codes/etc), and all data was coming in from the device. I did note that before I could set codes, I had to get user codes. It just took a few clicks, refresh, get codes, and I was able to set codes, unlock device, show which code unlocked, etc. Everything you would expect.
Another possibly useful feature, as I mentioned previously, when you unlock from the device manager it doesn't timeout and go back to locked like it does from the keypad. However, the device status DOES change from 'Unlocked' to 'Unlocked with Timeout' which could be useful. Here is the status report:
Current States
- battery : 100
- codeChanged : added
- lastCodeName : Master
- lock : unlocked with timeout
- lockCodes : **
- maxCodes : 30
Enable lock code encryption works as you would expect and encrypts the user codes just showing the code name. The event log is fully populated now.
To repeat and test the steps, I excluded and included the keypad, and this time went right to the Generic Z-Wave Lock. It operated as before showing no response data. I changed to the BasicZWaveTool device driver to see if I could click through and populate the info as before. This time Parameters didn't appear to provide a response. It reported association and version in the log, nothing else.
Removing and re-adding the keypad; set the driver to the z-wave tool 1st; clicking through the top row a couple times; check logs to ensure all information has been reported; THEN set driver to Generic Z-Wave Lock; click through lock/unlock/get codes, then try setting a code until all functions appear to be working. Lock Code Manager also works great with no problems.
One more check: I moved the keypad away from the hub and device is a little lagging with inconsistent reports. I'm leaving it in place for a short period to see if the network optimizes itself for z-wave comms.
The final step I haven't checked is adding an RFID token and see how the events are reported. Each keypad comes with two keychain size generic RFID tokens. They all work by default until you reset the generic admin password. Then you add the token as you would a regular password at the keypad, except rather than typing in the password, you just hold the token near the middle of the pad 2x. I tried RFID enabled ID cards or a credit card to see if these could be stored as a token. The two I tried had a short response, the keypad beeped and flashed and recognized an RF device was nearby, however it wasn't the longer beep associated with the token, and it wasn't saved as a valid unlocking device.
Update this morning / tested key fob use:
Repaired the mesh network to reconnect the keypad away from my hub, but after the repair it started working without issues.
Key fob usage. Adding the key fob from the keypad generates a user (default name "Code X") with a unique 8 digit pin. The pin will not work from the keypad, only with the fob. You can rename the user from the device manager using the same code slot and same 8 digit pin, just change the name. The fob still works and reflects the new name in the event log. Deleting the fob from the device manager removes the activated fob. Adding the fob from the device manager (vice the keypad) using the unique 8 digit code will enter the code in the list of users, but the fob does not work. The code also doesn't work from the keypad (same as before). Bottom line, the fob must be entered physically at the keypad first, then the name can be modified or it can be removed from the device manager. The unique 8 digit code remains the same each time the fob is entered. I did notice this morning occasionally I experienced a few short beeps (similar to using another RF ID card) before the fob was recognized. I may try a generic ID again to see if it works, however I left them in proximity long enough they should have been able to be coded. I suspect they are generating too long of a chain for the device to save (based on a PKI chain rather than just an 8 digit pin).
Nice work man and congrats on persevering with it. Always good to have new options for things like these keypads. I look forward to hearing how you get on integrating then into your HE setup.
1 Like
Final hardware update:
My initial test was on an HE C5, I migrated to one of my C7s running 2.2.3.148 Initially the keypad paired but didn't respond with either the generic z-wave lock driver or the basic z-wave tool. Once I applied the z-wave firmware upgrade, the device paired with no problem and did not require the basic z-wave tool. A couple of additional trial pairings and I found that the device will configure properly and operate as long as it pairs secure. The keypad manual confirms that non-secure pairing limits functions. Specifically it has no functionality other than returning limited configuration data on a non-secured pairing. This isn't quite what I experienced earlier where you could lock/unlock and set codes, but no events were reported.
The below screenshot shows secure pairing in the 2nd data line.
Here's a simple installation configuration I set with a 12v 2.1mm socket and 2x 12v indicator LEDs (1 red / 1 green) ordered through Amazon. In this configuration the keypad will be mounted outside the garage and the plate will be mounted on a remodel box inside the garage to provide a power point and indicator. Red shows locked with power on and switches to green momentarily when activated. All garage door activation will be conducted through rule machine to activate my connected GO garage door opener.
Wiring is simple and pictured here. Red +/Black - power go to 12v power jack (red middle, black outside). Black - LED leads go to black power. White relay common goes to 12v + red power jack. Green NO (normally open) lead goes to green LED + red lead. Blue NC (normally closed) goes to red LED + red lead. Yellow is reset and is not used, this actually isn't carried through the connector but is connected to ground (black) through a NO spring switch inside the box to reset the device.
The three sample keypads I ordered were not consistently wired, although all color codes were correct and accurate. Two had connected wiring harnesses although the male/female connectors were opposite on each one (connector pictured above). The third was straight wired with no harness connector. These would probably provide an issue for mass production, but not a problem otherwise.
My final test was to check the master reset function to determine how it behaved to the z-wave network. Master reset did not clear the z-wave pairing, the keypad remained paired and on my network. As before, once the master reset (by holding the reset button for 7 seconds or so until a long beep), any number combination would unlock the device and reflected on the device event log. While nothing in the log indicated that the reset had occurred, other than the code list was cleared, the code reported in the event log changed to report 'master code' after the reset was activated. The event log below (code 1 redacted and named 'Reset') shows unlocking with code 1, then unlocking with a generic code 'Evens' in spot 2. Next a master reset was conducted and the lock unlocked with three separate random codes (any number/length works),
For my application, I intend to test for LOCK 'unlocked' AND lastCodeName NOT 'master code'
I also intend to either add a timer when unlocked, or check for LOCK 'unlocked with timeout' to set it back to locked. This is only required when unlocked through the z-wave network.
| lastCodeName | master code | Smart Lock was unlocked by master code | DEVICE | 2020-11-02 08:05:23.453 PM EST | ||
|---|---|---|---|---|---|---|
| lastCodeName | master code | Smart Lock was unlocked by master code | DEVICE | 2020-11-02 08:03:42.276 PM EST | ||
| lastCodeName | master code | Smart Lock was unlocked by master code | DEVICE | 2020-11-02 08:03:11.225 PM EST | ||
| lastCodeName | Evens | Smart Lock was unlocked by Evens | DEVICE | 2020-11-02 08:02:24.874 PM EST | ||
| lastCodeName | Reset | Smart Lock was unlocked by Reset | DEVICE | 2020-11-02 08:02:07.034 PM EST | ||
| lockCodes | {"1":{"code":"xxxxx","name":"Reset"},"2":{"name":"Evens","code":"2468"}} | DEVICE | 2020-11-02 08:01:51.030 PM EST |
I plan to install this coming weekend and will post final results.
1 Like
Finished the rule machine code which uses the keypad to control an Iris / Go Control Garage door opener. My device name is 'Garage Keypad', the garage door controller is named 'Garage Door'.
The control uses 4 separate rules and a global variable:
- Garage Keypad Tamper - checks for code entered of 'master code' (the default code) and sets the global variable to TRUE. To check for 'master code', create a temp user named 'master code', build the rule, then delete the temp user. You can also use the temp code to test the tamper variable/rule.
- Garage Keypad Lock - When unlocked, sets keypad to locked with a 3 sec delay. This resets the keypad if unlocked from the device / dashboard.
- Garage Keypad Close - Checks KeypadTamper, closes door if open and not opening/closing.
- Garage Keypad Open - Checks KeypadTamper, opens door if closed and not opening/closing.
Global Variable: KeypadTamper (boolean) with a switch connector
The switch connector creates a virtual switch of the same name, this allows you to create a dashboard device to indicate the tamper status and reset if necessary. The tamper also provides a simple method to disable all codes by setting KeypadTamper to ON which then bypasses all the conditional controls.
Screenshots of each rule are below:
Rules
-
Garage Keypad Tamper
-
Garage Keypad Lock
-
Garage Keypad Open
-
Garage Keypad Close
A few notes;
-
I initially checked for NOT (last code entered: master code), but recognized it wouldn't be too difficult to conduct a master reset, then set a new code at the keypad. The global variable creates a 'latch' which must be manually reset. Also - since there is no way to set custom code names at the keypad, keypad codes are named 'code #x' by default, you could create custom code which checks for 'code' at the beginning of the last code entered. Rule Machine only allows you to check against valid codes that currently exist at the keypad, rather than a partial code match, AFAIK.
It is also important to note that there was no problem both setting the tamper variable and checking it prior to opening on the same event. So entering a 'master code' did NOT trigger the 'door open' routine the first time through because the KeypadTamper was still set to false. The condition was set, the global variable changed, and the routines were skipped all in the same event. You could add a second (OR) conditional to the open/close routines to check for NOT (last code entered: master code) which would ensure this case, but I found it unnecessary and removed it. -
I created a different version of the Keypad Lock routine (to reset the keypad to locked) which checked for 'unlocked with timeout'. You can check for that specific state by creating a custom condition rather than just checking the standard device condition in Rule Machine. 'Unlocked with timeout' doesn't generate an event until the lock is refreshed, so I added another conditional and custom action to refresh the keypad when the state changed to unlocked. The refresh generated an immediate unlocked with timeout state rather than the built in delay, which effectively relocked the keypad approx 1-2 secs after it was unlocked. To lengthen this, I added a 3 sec delay to the refresh routine.
In the end this method worked, but used more code and additional processing / conditional statements. Each state change ran the routine and it took 2x through the routine to go from locked to unlocked with timeout to locked. The simple routine above is more efficient and does the same thing. -
The garage door controller uses separate commands to open / close the door with a tilt sensor indicator to provide door status. The command to the opener itself is a simple activation (change of status). To remain aligned with the command syntax, two separate rules are built to open and close. Both rules are activated by a momentary unlock of the keypad with a valid code, conditional statements in activation check the current status (open or closed) and execute one or the other. The GO controller also has a built in timer and reports 'busy' until a few seconds have elapsed to ensure the door is either fully opened or closed. This busy report does not impact the keypad routines, one just has to re-enter the code.
2 Likes
This is really very neat. Where is the reset button located? And could reset button be disabled? Is the keypad always lit up or does it have a proximity sensor?
I love the key fob aspect.
Thanks for sharing this !
The reset button is wired in the back and gets tucked inside the bottom of the switch when mounted to the back plate. It can't be disabled, although you could cut/remove it, but you wouldn't want to. It's required for pairing and reset. It took a little work to get around the security aspects of a readily accessible reset switch - but It's working well with no concerns.
The keypad is always lit up. You could wire it to an internal transformer/DC power supply, I just used the power jack for ease of installation.
Here's a photo of the final install.
3 Likes
Update:
A bit of a long post, this details the recent set of Rule Machine apps I revised to solve a state issue and add reporting.
I found that occasionally the keypad gets stuck between states - where hubitat is reporting unlocked when the keypad is locked, or vice versa. I haven't been able to narrow down what causes the problem, it may be just that Hubitat misses a change event from the keypad.
Either state creates a problem that unlocking the keypad fails to generate an event to trigger the code.
If the keypad is locked but hubitat is reporting unlocked, the keypad event doesn't trigger hubitat. This state will usually reset itself when the keypad times out back to locked and Hubitat picks up the state change after the next keypad entry.
If the keypad is unlocked but hubitat is reporting locked OR unlocked, entering a code at the keypad doesn't generate an event to trigger the keypad code. You have to lock or refresh the keypad (through code or manually).
The challenge is without periodic polling or refresh, there's no way to trigger the code to correct the state.
I added a virtual switch to manually generate a keypad refresh, and added additional code and global variables to facilitate reporting. Finally - I added a refresh routine which is captured if the garage door is opened or closed manually from the opener inside the garage. This works for my application, we have people who have access to a remote property either through automated door locks or the garage. If the garage keypad stops working, they can easily access the garage through the house and open the door manually which will reset the keypad.
It would certainly be more streamlined to capture these routines in a custom app which would allow you to link the keypad to a specific device. Ideally the app would would catch and reset the keypad if necessary. That's outside my current skillset, maybe I'll try to tackle it someday.
Updated routines:
There are 5 global variables:
GarageDoor and LastName are strings used for reporting.
GarageDoor: Captures the status of the door - opening/open/closing/closed
LastName: Captures the name associated with the Keypad code
KeypadReport, KeypadTamper, KeypadValid are booleans
KeypadTamper: Tamper check which captures if the keypad is reset from the tamper button. Puts the code in a tamper state which disables any further actions until reset. A Virtual Switch link allows you to reset the tamper mode, and also use it to manually disable the keypad.
KeypadReport: A reporting flag used for the report app. When triggered by the keypad, the first time through the report identifies "(who) is (opening/closing) the garage door."
The flag is reset and the 2nd time is triggered when the garage door is fully open/closed. The report then states "The garage door is (open/closed)."
KeypadValid: Flag used to identify that a valid code was entered at the keypad. Used to differ between manual door operation and keypad initiated activation.
The full code is split into 3 Keypad apps, 5 garage door apps, and 1 reporting app. The split allows each section of code to be specific to an action.
Keypad Check: The primary app which initiates action triggered by Keypad Unlocked.
First checks for tamper (indicated by "master code" as the last lock code, see previous posts for details).
Then if Tamper is false and unlocked true:
Sets KeypadValid flag to true (valid code entered)
Sets KeypadReport flag to false (keypad user has not been reported)
Captures name of individual who entered the code
Runs Garage Door Actions (opens/closes the door)
Runs Delayed Actions - accounts for opener delay between alarm and when door is activated.
Delay was initially set to 10 secs as shown here, I later adjusted to 7 secs.
From initiation, alarm, activation, to fully open my door (Genie Accelerator) fully opens in about 10-12 seconds and closes in 15-17 seconds. The delay is to capture the door after it starts opening before it is fully open (or closed). The action starts about 5-6 secs after initiated (warning alarm duration). When set to 10 seconds, occasionally the door would already be fully opened at the initial report.
Garage Door Actions: Opens/Closes the garage door, captures the garage door state.
Checks the tamper flag and ensures door isn't already opening/closing (not really necessary - the z-wave opener already has a 30 sec delay between accepted commands)
If the door is closed then it opens, if the door is open then it closes.
After 7 seconds captures the door status (opening/closing) in GarageDoor.
Garage Door Actions Delayed
After 7 second delay, if garage door is opening or closing, then make the door report. If it is not opening/closing, then conduct actions check. This is one check to refresh the keypad, however it typically doesn't get triggered unless the opener is in a 'wait' status.
Door Report - Garage Door
If KeypadReport is false and KeypadValid is true (a code was entered and a report hasn't been made yet), then report the name is (opening/closing) the garage door. This should be called after the delay when the door is still moving.
Then reset KeypadReport to True (report was made).
Otherwise notify the door is open/closed. This is triggered when the door triggers an open/closed event (opening/closing are states, but do not trigger an actual event. When the door reports open or closed an event is triggered.
The notifications (two are currently programmed) are tied to virtual switches which allow you to turn off reporting.
Reports will look similar to this from a keypad entry (2 reports per event)
Time: Dave is opening the garage door.
Time+: The garage door is open.
Garage Door Actions Check:
If garage door is not opening or closing, then refresh the keypad. The IF is redundant (also checked before this app is called), that is left from an earlier code version.
The final apps are triggered separately:
Garage Door Report and Refresh:
This reports door actions that aren't initiated at the keypad and also includes the refresh routine.
Triggered when Garage Door triggers a changed event (OPEN or CLOSED).
This can happen either when the door is opened manually, or if it is opened from the keypad.
First make the report (this will be the 2nd time through if keypad initiated, the only report if initiated manually).
If KeypadValid is FALSE (not opened from the keypad), then conduct the refresh.
Lock the keypad (if the keypad is stuck in an unlock mode).
Refresh the keypad.
Send a notification that the keypad was refreshed.
Else (KeypadValid is TRUE - it was opened from the keypad)
Reset the KeypadValid flag to FALSE.
Garage Door Status:
Triggered when Garage Door changes (OPEN/CLOSED) this captures door status in global GarageDoor for reporting. Again - 'between' status (OPENING/CLOSING) do not trigger door events.
Keypad Lock:
Detailed in an earlier post, this auto locks the keypad when unlocked from the hub. When unlocked at the keypad, the keypad automatically locks after a timeout. When set unlock, the keypad will remain unlocked until locked. This is modified with a 5 sec keypad refresh to try and help prevent 'between' states.
Keypad Refresh:
The final Keypad app, this simply ties a virtual switch to refresh the keypad manually from the dashboard.
Actually ZIgbee, but doesn’t look bad. China address so you’d have to find a local reseller.
Looks very similar to the Linkind one:
It appears either it supports both Z-wave and Zigbee
Model Number
7A-KP-Z-B-A0
Protocol
Zigbee 3.0/Z-Wave 700
Radio Frequency
Zigbee 2.4G Hz / Z-Wave 868.42MHz(EU), 908.42MHz,(US)
They offer a U.S. version but for the life of me I can't find one for sale anywhere.
The best Zwave keypad with Hubitat is the Ring Keypad Gen2. Work super fine with Hubitat and look good!
An old post, still long, not sure if anyone is using these rules. However I updated and streamlined the garage door keypad handler routines using RM 5.0. These rules are designed for the z-wave keypad described above, and a z-wave garage door opener add-on such as the GO-CONTROL or similar.
This update corrected/improved the following:
- Resolved notification routines to remove duplicate reporting
- Refined refresh logic to prevent state errors where keypad and/or garage door was stuck between states and not responding.
- Added RM 5.0 predicate conditions to streamline error checking for the tamper state.
- Consolidated multiple rules and conditional statements to streamline rule flow.
- Added a wait handler which re-triggered z-wave opener if opener is on a wait delay. The Go-Control z-wave garage door controller does not send a new command to the garage door opener within 30 seconds of a previous command to allow the door to complete an opening/closing evolution. The GARAGE DOOR CHECK rule now checks for that state (not opening or closing), and tries 3 attempts to resend the command to open/close the garage door (10 seconds apart).
While the RM4.1 version worked fine most of the time, but still occasionally would get stuck between states, this version is running smoothly for a couple weeks with no issues.
Detailed Rules
The rule sets consist of hub state variables and 7 total rules divided into 4 rules handling the keypad, and 3 rules handling the garage door notifications. Each set (keypad and reporting) is independent of the other. Notifications are triggered by a change in garage door state (open/close/etc), and the keypad handler is triggered by the keypad.
The only link between the two sets of rules are 3 common hub variables which passes the code-name (person who unlocked the keypad), whether a valid keypad entry was made (KeypadValid) and whether a keypad report was made (KeypadReport), to the notification routine. That report (that "person" is opening/closing the garage door) is only made if the door was opened via keypad, and is not otherwise executed.
Rules follow with both screen-shots and text / descriptions:
HUB VARIABLES: (disregard variables in the screen-shot not described below).
Dave Reports / Paula Reports: BOOLEANs with switch connectors to turn door reports on or off
GarageDoor: STRING to capture ‘door’ which reports current status of door (open/opening/closed/closing)
KeypadReport: BOOLEAN flag to indicate when initial (opening/closing) report has been sent
KeypadTamper: BOOLEAN with switch connector to indicate that Keypad has been reset and
master code (default) entered. Disables keypad. Switch connector provides a method to
reset from dashboard, or manually set as a method to disable the keypad.
KeypadValid: BOOLEAN with contact connector to indicate a valid entry on the keypad.
Contact connector not used.
LastName: STRING to capture name (code name) of individual who entered valid entry on the keypad.
Used in reporting.
KEYPAD ROUTINES
Keypad Lock and Refresh Independent routine which ensures KEYPAD device locks after 3 seconds. Keypad auto-locks when opened through the device with a code unless opened digitally (through the Habitat Device), in which it will remain unlocked. This captures the unlock action and triggers a delayed lock, also triggers a 5 sec delayed keypad refresh. Includes manual switch option to manually activate, however with revised routines this is no longer required.
Trigger Events:
Garage Keypad unlocked
Keypad Refresh(off) turns on
Actions:
Lock: Garage Keypad --> delayed: 0:00:03
Refresh: Garage Keypad --> delayed: 0:00:05
Notes:
Locks keypad after 3 seconds,
and refreshes after 5 seconds,
if unlocked with timeout or if manual switch Keypad Refresh turned ON.
Keypad Check: Primary keypad handler routine.
PREDICATE CONDITIONS:
KeypadTamper(off) is off(T) [TRUE]
TRIGGER EVENTS:
Garage Keypad unlocked
ACTIONS:
IF (Last Event Device lastCodeName = master code(F) [FALSE]) THEN
Set KeypadTamper to true
Set KeypadValid to false
Notify Dave’s iPhone: 'Keypad Tamper Activated.'
ELSE
Set KeypadValid to true
Set KeypadReport to false
Set LastName to Garage Keypad lastCodeName(Toni)
Run Actions: Garage Door Actions
Run Actions: Garage Door Actions Check --> delayed: 0:00:07
END-IF
NOTES:
Only runs if KeypadTamper is OFF (switch connector to KeypadTamper boolean hub variable).
Triggered when Garage Keypad is unlocked:
IF lock code entered is ‘master code’:
Set hub variable KeypadTamper to TRUE if lock code entered is 'master code'.
'master code' is reported when ANY code is entered after a full keypad reset.
Once set, must be manually cleared by the connector switch and will disable
any further running of this rule through the predicate condition.
Also sets KeypadValid to FALSE
ELSE:
Set KeypadValid to TRUE: Flag to indicate a valid keypad entry was made
Set KeypadReport to FALSE: Flag to indicate when the keypad
opening/closing report is made.
Capture LastName (only link to reporting routine though Hub Variable)
Run Garage Door Actions
Run Garage Door Check after 7 seconds. There is an approx 5 sec notification delay by the GO-CONTROL garage door controller with a warning beep and flashing light before sending the open/close command to the garage door. This delay accounts for the notification prior to checking garage door movement through the next rule.
Garage Door Actions
Actions:
IF (Garage Door closed TRUE) Garage open: Garage Door
IF (Garage Door open FALSE) Garage close: Garage Door
Notes:
This App is called, not triggered.
Open Garage Door if garage door is CLOSED
Close Garage Door if garage door is OPEN
Garage Door Actions Check
Actions:
IF (NOT Garage Door opening(T) AND
NOT Garage Door closing(T) [TRUE]) THEN
Refresh: Garage Keypad
refresh() on Garage Door
Repeat 3 times every 0:00:10 (stopable)
Run Actions: Garage Door Actions
Wait for event: Garage Door changed --> timeout: 0:00:07
IF (Garage Door opening(F) OR
Garage Door closing(F) [FALSE]) THEN
Stop Repeating Actions
END-IF
END-REP
END-IF
Notes:
If garage door is not opening or closing, then refresh the keypad and the garage door sensor.
Then repeat 3 times every 10 seconds (30 secs total), rerun garage door actions,
wait until garage door opening or closing (timeout after 7 seconds).
Exit repeat if garage door opening/closing.
GARAGE DOOR REPORTING RULES
Garage Door Status: Primary reporting rule, Triggered by a change in the Garage Door state (reported by remote garage door tilt sensor to the z-wave garage door controller, part of the controller package).
Trigger Events:
Garage Door changed
Actions:
Set GarageDoor to Garage Door door(closed)
Run Actions: Garage Door Report and Refresh
Notes:
Sets Hub variable GarageDoor to Garage Door status (door) when it changes,
then run Garage Door Report and Refresh
Garage Door Report and Refresh: Primary garage door reporting routine. Called by Garage Door Status.
Actions:
Run Actions: Garage Door Report
IF (Variable KeypadValid(false) = false(T) [TRUE]) THEN
Lock: Garage Keypad
Refresh: Garage Keypad
IF (Variable Dave Reports(true) = true TRUE) Notify Dave’s iPhone: '%time% Garage Keypad refreshed.'
ELSE-IF (Variable KeypadReport(true) = false(F) [FALSE]) THEN
Set KeypadReport to true
ELSE
Set KeypadValid to false
END-IF
Notes:
Run by GARAGE DOOR STATUS
Report garage door
If a Keypad Entry was not made (KeypadValid = FALSE):
Lock Keypad
Refresh Keypad
Send a refresh report
ELSE IF KeypadReport is FALSE (KeypadValid flag is TRUE):
Set KeypadReport to TRUE - 1st time through keypad report was made
ELSE Set KeypadValid flag to FALSE - 2nd time through reset KeypadValid flag
Garage Door Report: Makes actual Garage door report, includes switches to turn off reporting. Devices are programmed directly into the report code, with the separate routine makes it easier to update/change devices. Two included here, easy to add more. While the "keypad refresh" report is made just to my device through the previous routine, that was primarily for troubleshooting the previous issues. All open/closed (opening/closing) reports are made through this rule.
Actions:
IF (Variable KeypadReport(true) = false(F) AND
Variable KeypadValid(false) = true(F) [FALSE]) THEN
IF (Variable Dave Reports(true) = true TRUE) Notify Dave’s iPhone: '%time% %LastName% is %GarageDoor% the Garage Door.'
IF (Variable Paula Reports(true) = true TRUE) Notify Paula’s iPhone: '%time% %LastName% is %GarageDoor% the Garage Door.'
ELSE
IF (Variable Dave Reports(true) = true TRUE) Notify Dave’s iPhone: '%time% the Garage Door is %GarageDoor%.'
IF (Variable Paula Reports(true) = true TRUE) Notify Paula’s iPhone: '%time% the Garage Door is %GarageDoor%.'
END-IF
Notes:
App is called. Delays and setting global variables happen prior to calling the app.
Hub Variables:
GarageDoor - set to status
LastName - set to who unlocked the keypad
KeypadReport - determines whether a Keypad Report was made to make either a keypad report, or a door status report.
Notifies with Name if KeypadValid indicates a code was entered which triggered the action, otherwise reports the door status (open or closed / opening or closing).
UPDATE 12/2/21: I found that the garage door state was sometimes getting stuck in the OPENING/CLOSING state and not reporting OPEN/CLOSED. I updated the GARAGE DOOR ACTIONS CHECK routine which now checks and corrects this.
Changes
GARAGE DOOR ACTIONS CHECK
No triggers - app is called.
IF (NOT Garage Door opening(T) AND
NOT Garage Door closing(T) [TRUE]) THEN
Refresh: Garage Keypad
Refresh: Garage Door
Repeat 3 times every 0:00:10 (stopable)
Run Actions: Garage Door Actions
Wait for event: Garage Door changed --> timeout: 0:00:07
IF (Garage Door opening(F) OR
Garage Door closing(F) [FALSE]) THEN
Stop Repeating Actions
END-IF
END-REP
ELSE-IF (Garage Door opening(F) OR
Garage Door closing(F) [FALSE]) THEN
Wait for event: Garage Door changed --> timeout: 0:00:10
IF (Garage Door opening(F) OR
Garage Door closing(F) [FALSE]) THEN
Refresh: Garage Keypad
Refresh: Garage Door
END-IF
END-IF
1 Like
Wow, you've really provided a wealth of information.
I'm looking for a generic z-wave keypad that can be used for general-purpose authentication. Most of the keypads in this thread seem to be tailored for alarm systems.
The ones you found on Alibaba might be the ticket though. I was considering using a z-wave lock, just for the keypad, where my script would handle successful key entries, and the deadbolt opening would just be a battery-wasting side effect.
Where can I get those keypads? Do you have a resource to get started with it, avoiding the lock state problems you were having?
Thank you
Unfortunately that keypad no longer appears to be available. The link is further up in the post (#78). Here's another Alibaba general keypad supplier (many versions are available) that may be able to provide a z-wave version, although they don't have one listed (they have wifi). You could try sending them an inquiry:
I also thought about using a z-wave keypad lock. I considered installing them in a blank wall to use as a garage door controller as you stated, but would also need a way to access the batteries. You could always dual-use an existing electronic lock with some code to capture and run a routine, but it would also unlock your door at the same time.
I've read elsewhere that the Ring security keypads are z-wave and can be used in a similar fashion, but I haven't tried them myself.
Also, the old Iris (Lowes branded) can be found on E-Bay and those are Zigbee (search for Iris Keypad). I purchased one when I was working through this project but never tried it out after I got this working.
I've worked through the state problems, I made one update since my last post which I added to the end of the above. Since that update the routines are working without getting stuck between states. I also found it was the garage door controller getting stuck, not the keypad.
Here are a few links to check out and consider. Good luck! Happy to answer any other questions or help clarify anything.
1 Like
I located the supplier contact on Alibaba that I used when I ordered the z-wave keypads, I sent them a message to see if they still had them available. I'll let you know if/when I get a response.
