[OBSOLETE] SHM Delay Version 2.0

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

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

I cannot get the Konnected Buzzer to activate.

Buzzer sounds after disarming from Away. I have to manually turn off the buzzer.

Really not sure what is going on with your system or ST delaying things. In Away mode when the system begins Entry Delay, the buzzer should sound, then stop when the system is set off.

How does it function on Exit Delay?

I assume you are using the SHM Delay BuzzerSwitch module?

Edit. One additional thought. Allow any Exit Delays to expire before testing the Entry Delay.

I am trying it with lights and the Konnected buzzer. It only seems to operate on the entry delay (not the exit delay)–is it supposed to do it both entry and exit?

Also, is there a way to activate the “alarm” or “siren” function of the buzzer? You can see from the screenshot, that it I did when I activated both (manually in the app). The “beep” function is a momentary (built in)–it beeps and then shuts off automatically–like a door chime function.

I will verify the logic tomorrow, supposed to do both exit and entry. When I tested I used lights and it worked for both entry and exit.

Have to review the Knnected buzzer DTH again. You can use the beep with the normal delay profile.

The Konnected buzzer is weird. I have tried several ways in WebCoRE. I can get the “alarm” function to come on very easy. Getting it to go off is another story (sometimes it does, but most times, I can’t).

I have not had ANY trouble with the Konnected buzzer and webcore. I can easily control it. I am having trouble with @arnb’s Buzzer app. I cannot get an exit delay buzzer. Not a big problem though. The entry delay buzzer works. But, after I disarm my SHM system, it turns off and then almost immediately turns back on for 1-2 seconds and then turns off again. Now, I am using ActionTiles and Fully Browser. So maybe there is some interference there.