Sigh. And I thought this would be a simple app. Away is issued/set prior to the the shmDelayTalk.
Will let you know.
Hi - just getting ready to install this. Thank you for the effort youâve gone to in developing the SmartApp.
Does the app support the Z-Wave Zipato RFID Keypad?
Keypad support is determined by the DTH, not the SmartApp.
The suggested DTH does not support that device. This app also supports Rboyâs keypad device handler, but I donât know if that device is supported.
Version 1.0.1 is now in the beta with the following changes:
-
capability is now âswitchâ
-
Fixed: Device now shuts off after non keypad exit delay expires
-
When system is running slow, and non keypad exit delay occurs before away mode, delays the On by two seconds, and the off by four seconds. During my testing I could not recreate this condition. I realize this is a very crude way of doing this, but this was supposed to be a âsimpleâ smartapp.
Also should you encounter any issues please post the Live Logging info for SHM Delay Buzzer
Ok, so after going through and verifying it was not in use by after removing the delay profiles and then re-adding⊠it showed up again. It occurred to me in that process, that the reason itâs âin use byâ was not because of the motion sensors but because I had the the âbeep/chime these devicesâŠâ setting set on the delay profile to use the keypads as door chimes. So thatâs where that all came from even though Iâd removed the motion settings.
I do want to clarify something. On the delay profiles it says:
(Optional!) Ignore this Motion Sensor during exit delay, and when the Real Contact Sensor opens during entry delay. The sensor is monitored in Alarm State: Away (Remove from SmartHome Security Armed (Away) Monitoring)
So, in my example, I have a basement motion sensor (NOT the keypads) that has a few sensors in series on a zone on my konnected panel. One of the sensors can see some motion near my basement door, but not all, but to be on the safe side, I do want it excluded from detection as to ignore it during the exit delay. So, if I put it in the âignoreâ list on my delay profiles, then I DONâT put it in my motion sensors to be monitored via Smart Home Monitor -> gear icon for settings -> Security -> Armed (Away) Intrusion sensors -> Motion sensors? If I arm via the SmartThings app or via ActionTiles to set SHM to Armed (Away) and I do NOT use the Iris Keypads, then is basement motion not monitored? I was confused by the wording on this.
Ok, I see how you did it. I was expecting the SHMDelay smartapp to to fire another event once the delay time was up. Instead, youâre just waiting for x seconds in the new smartapp.
As for the âawayâ issue, I still think itâs better just to ignore the change to âawayâ. Weâre already turning the light (or buzzer) on when the shmDelayTalk event is firing. We only need to turn it off if the alarm is turned off or the delay timer is reached. Youâd never want to turn it off when SHM changes to âawayâ.
Edit
fixed a typo
Correct
Not True.
How the system is armed controls the type of exit delay:
- keypad arming gives a real exit delay
- ActionTiles or Dashboard is simulated, ignoring devices until the non keypad exit delay time expires.
It does not matter how the system gets into Away mode
That is correct when arming from a non keypad source. However, when arming from a keypad the exit delay is real and and away mode is set after the exit delay expires.
Edit: If I remember correctly, The arming event provides the source of the event, so it may be possible to selectivly ignore the Away commands.
Edit2: event source in always âLOCATIONâ no useable
Ok, thanks. So, what I will do is in SHM only monitor âGlass-Breakâ in my away settings and then I will put âBasement Motionâ in my delay profiles only. I think (hopefully) this fixes all the false triggers and Iâll no longer be scaring my dog.
Also, I thought I had that keypad DTH setup to âupdate from the source repoâ or whatever it was, but I canât find out to make it sync and pull it from repo. When I choose update from repo and select the mitchpond one, it only had some other random thing (devicetypes/lgkapps/notdev.src/notdev.groovy) as a âNew (only in GitHub)â option. The âObsolete (updated in Github)â and âConflicted (updated locally and in GitHub)â are both totally blank in the boxes. When I copied what I had published and what you had linked for the source from Github and used ExamDiff, I could see where he was missing a set of closing parenthesis on in the code for the battery:
result.value = Math.min(100, (int) pct * 100)
vs the new
result.value = Math.min(100, Math.round(pct * 100))
So, I think thatâs what you were referring to. I am new to the IDE with this implementation, so I guess I may have it set up incorrectly if itâs not syncing or finding the updates or maybe I misunderstood how that all works. I thought if I grabbed from repo as opposed to just pasting source code in, that it could keep it updated. Can you clarify where I may need to do something to fix that?
In the meantime, I just edited, deleted the old code, pasted the new, saved, and published, so the new is in there. That said, the battery still shows 0%, but I think the basement keypad is having trouble seeing the hub very well. This morning I couldnât arm from the keypad because the little upper right corner âsignalâ light wasnât green so I think it couldnât see the hub. I tried removing the batteries overnight last night and putting them in this morning so it could definitely attempt a reconnect, but it didnât see it. I can try hauling it upstairs and then powering on to see if it behaves closer to the hub and then try relocating the hub to a location that works for both keypads. Iâm surprised itâs having so much trouble.
Understood. Thanks for all your help. Iâve got enough to get it working in my limited scenario.
- Go into the IDE, tap/click on "my device handlers
- Scoll to device mitchpond : Centralite Keypad
- tap/click on the hamburger icon on the far left
- field GitHub Repository set to âCentralite-Keypad (master)â
- Click/tap Save
Should âCentralite-Keypad (master)â not appear in the list go back to the device handlers pageâ> click Settings at the top of the page then add
miriad Centralite-Keypad master
save it then retry
There is also another fix in the DTH to fix multiple keypads sounding Door Open chimes.
if the network light is off, the keypad is not communicating with the hub. Sometimes the battery pull fixes it. However, it usually means the batterys are depleted, or the zigbee signal is weak.
Also regarding the keypad battery %, what does it really mean? Itâs an aribitray and in my opinion useless calculation. For the keypads, what I have done in my personal version of the DTH is to show volts. It also changes to acknowledgement to the DTH to help insure the keypad stays online when the ST system is slow to respond.
Yeah, itâs in my device handlers as that source and the repository is currently set correctly to the Centralite-Keypad (master) as you described. Attached is a screen cap of it.
I will try removing from the wall and walking closer to âunderneathâ where the hub is on the 1st floor to see if it lights and Iâll try swapping the batteries. Itâs the 2nd keypad I bought about a month ago, so it still has the original lithiums that came with it, but I bought a bunch of rechargeables to use after my first keypad ran the initial batteries dead in a little over a month, since the non-rechargeables are about $12 a pair at brick & mortar.
I might try your version to get something more meaningful on that gauge. Does it show up under the âbatteryâ indicator on the status screen for the keypad for the thing (like where it shows mothion, tamper, panic, and battery)? If I install yours, do I have to uninstall my keypads, remote the mitch handler, add yours, then reinstall the keypads with a new synchronization? Or can I point to yours to use instead somehow?
@jlucas090866 Arn is correct, the devices needs a compatible DTH. The Enhanced ZigBee Keypad Lock DTH that Arn is referring to only work with ZigBee keypads.
This Z-Wave keypad should work with the Universal Z-Wave Lock DTH as keypad lock device (it supports, both, user pin codes and RFID tags). You can use the device with a user management smartapp like the ST SmartLocks app or Lock User Management to program user codes and take actions when user codes are used to Lock/Unlock on the keypad (Away is Lock and Home is Unlock).
However, SHM Delay 2.0 has a specific requirement and this Z-Wave DTH unfortunately doesnât support it currently. If there is enough demand from users for these Z-Wave keypads we can look to adapt the DTH to support SHM Delay 2.0
Change the keypadâs device source Github library to SHMDelay beta
Update and pubish the Keypad DTH. That is it.
It shows the volts at a %, for example: 30% - 3.0 volts, or 29% - 2.9 volts (did not bother changing the display text.
I am also using Fire tablets to replace my keypads. I am also using ActionTiles and Fully browser, so having a virtual keypad in ActionTiles would be nice.
Weâve got a substantial improvement to the âpop-upâ PIN Pad in ActionTiles Beta (v6.9.2+) right now: much larger and faster. I think weâll hold off on making a dedicated âalways on screenâ keypad, though. Please wait until this version is Released and then we can discuss again.
Fantastic! The current keypad does not like my big fingers and there is not a correction key. So, some of my key presses are registered incorrectly (or not at all) and my delay expires thus triggering an alarm.
Yup⊠It is a pretty popular ActionTiles Feature Request: https://support.actiontiles.com/communities/12/topics/3466-bigger-pin-pad-full-screen-zoomed
All is working nowâŠ
@arnb Could not save delay and user profiles. âSaveâ was not an option. Completely uninstalled EVERYTHING and re-installed. Still cannot save profiles.
Documentation Updated and System Enhancement
For anyone using Konnected devices wanting to sound the Konnected Buzzer, or anyone wanting to turn on a light, or a real/virtual swtich during SHM Delayâs Exit/Entry delay: Addon Module SHM Delay BuzzerSwitch is now fully documented in paragraph 31 of the SHM Delay documentation.