Sigh. And I thought this would be a simple app. Away is issued/set prior to the the shmDelayTalk.
Will let you know.
Sigh. And I thought this would be a simple app. Away is issued/set prior to the the shmDelayTalk.
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”.
fixed a typo
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?
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.