[OBSOLETE] SHM Delay Version 2.0

I made this change a good while ago, for that reason i dont think it will have any issue regurdless of what version of Smartthings app is being run. Ofcourse this is a different app so.

Give yourself credit for being correct.

My perfectionist self prefers to do something like this, but I am currently unable go determine the execution environment

If (V2 app)
    sendPushMessage
else
    sendPush

If I’m reading this correctly the only difference for Classic is that it will now store the push message in the notification feed whereas previously, it didn’t.

Here is the link to the portal where I found this information.

https://docs.smartthings.com/en/latest/smartapp-developers-guide/sending-notifications.html

[Update] Dec 23, 2019, 12:00PM EST

Enhancements and Changes

  1. Added: Full support for UEI keypad than languished, almost forgotten in the Beta repo

I urge everyone to stay up to date, please update your system,

How to Install
There are three (3) modules associated with this update.

  1. SHM Delay (v2.3.0). Module should be Saved, Published, then Installed with the Classic Smarthings app
  2. SHM Delay Child (v2.1.6) Should be Saved, do not publish or install.
  3. SHM Delay Modefix (v0.1.8) Should be Saved, do not publish or install.
  • Install via the repository (preferred), from the following repo.
    Owner: arnbme (in upper case that is ARNBME)
    Name: SHMDelay
    Branch: Version2

Post Installation

  • Review, then Save Global Settings.

Other

1 Like

Hi, is there an option to monitor a simulated contact sensor rather than a real one?
My Visonic alarm has an integration into ST but the sensors seem to be detected as simulated by themselves… The device id is set by the DH as alarmXX etc which is not accepted in the contact name override field…
Thanks.

Enter the “(Optional!) Contact Name: When Real Contact Sensor is rejected as simulated, enter 4 to 8 alphanumeric characters from the IDE Device Type field to force accept device” field to force the application to accept the simulated contact as real.

it may be necessary to scroll down to see this field.

Which field exactly do you mean as I can’t see a field specifically called device type in the IDE (there’s device name, label and network id, which is the only unique identifier and I think is what you mean).
The problem is the network id is more than 8 characters, so is all other fields I try, so the input is rejected.

From Section 10 of the documentation:

Enter a portion of the IDE Device’s Type field data. In the example shown below Simulate or ed Cont or Sensor would work

image

Adding a few letters from the device type worked. Thanks very much!

1 Like

I did an update to the SHM Delay apps through the Community Installer app and it published the modules that the instructions said not to publish. Will this be a problem and if it is can they be unpublished?

I don’t believe it is possible to Unpublish. What it will do is give you a bunch of extra junk apps in the applications page. However, I don’t think it effects execution.

When I inadvertently Publish an app, I will delete and reinstall to clear it.

Ok, Thanks I will reinstall

Unfortunately that also means resetting all the childs apps (profiles).

Hello folks,
Wanted to ask if anyone is working with this through the new app solely?
From what I’ve seen the alerts will trigger only of SHM is set to arm in the classic app. If you arm SHTM only the virtual device does not receive any triggers…
Any workarounds available?

I’m using it exclusively but had the same thing happen when I was setting it up with the new app.

YOU MUST USE THE CLASSIC APP TO SET EVERYTHING UP

The new app will corrupt your profiles. What I had to do was entirely remove the SHM Delay app and start over to fix the problem you are seeing.

Never open any of your profiles from within the new app. Smartthings has a bug with child apps (which SHM Delay uses) and the new app.

Link to the bug. The issue is some of the child apps are set to INCOMPLETE status.

[Release Keypad DTH ] Jan 02, 2020, 08:40EST

Keypad DTH now includes support for UEI and Iris V3 Keypads

Corrections and Updates

  • Adds integrated support for UEI and Iris V3
  • Device option to view real battery voltage. Shows in DTH as volts * 10 as a percent. Example 3 volts shows as 30%. Default: Off/False This was a quick hack in my personal DTH version, ugly but useful.

Installation module changes

  • Update Centralite Keypad device handler from github arnbme / SHMDelay / beta *Save, Publish, For Me
  • Other modules are unchanged and should load from the Version2 repo

Iris V3 Post Installation Setup And Usage

  • User pin profile with number 0000 must be created prior to first use. May not be used to disarm.
  • Arming: tap ON or Partial. Pin not required, and not sent even when entered. DTH sets pin to 0000.
  • Disarming: enter 4 digit pin, then tap OFF
  • There are multiple hardware and software versions of this device.

Issues or Errors?

  • Post questions on this thread.

  • For code errors: Set “Log debugging messages?” to true. In IDE turn on Live Logging; rerun the test, then forward the debug messages in a private message to me.

Thank you
My thanks and appreciation to Steve Jackson, @oldcomputerwiz, for creating the UEI logic, and for testing the UEI logic.

1 Like

I had updated everything via Github and had to reinstall two Iris V2 keypads because I was having issues. Issue one was that the motion seemed to be hung at detecting motion and two the battery level was stuck at 100%. This was on two of five keypads that I had installed. When pairing the keypads the Iris symbol would flash. Previously, after pairing they would flash and you could enter any four digit code and the off button and all would be good. This time the only way to stop the flashing was to remove and reinstall the batteries. Doing this however rendered the keypad useless as if it had never been paired in the first place. I have several of these keypads, even new unused ones and all of them exhibited this behavior. The only difference being the updated DTH. I have since removed all keypads and SHMDelay because I could not get it to work and I will be moving over to Hubitat soon. I just wanted you to have this information in case others run into this issue.

Edit: I just talked to a friend of mine and asked him to try pairing a new Iris V3 keypad that he had and he experienced the same behavior.

Did you try on the V3 to follow the reset instructions on the back of the keypad?
Remove one battery for 10 seconds push and hold small reset button on side, insert battery. Light blinks blue. Pair device. Light blinks green 3 times.

I’m completely on hubitat, with the exception of one keypad I keep for testing shm delay. Pairing keypads on either system can be a PITA.

Additionally when using the V3 with SHM delay pin code 0000 is absolutely required or it will not arm

I did not personally pair the V3 keypad. I asked a friend in another state to try it on his system. It was brand new and had never been paired. All of mine are V2 keypads. I tried to pair two of them (V2’s) numerous times over the course of a couple of days and finally gave up and paired them to Hubitat. All five of them paired instantly and correctly to Hubitat and with the familiar “successfully paired” Iris tone. I really think that there is an issue with the new DTH. Everything has been working fine on my system for a year.