[OBSOLETE] SHM Delay Version 2.0

Hey, I’ve just spotted some interesting things about your setup that I might like to try. First, some context: My Iris keypad often has trouble with the cloud-based and rather slow response times by the ST hub. Everyone who uses a physical keypad encounters this every now and then: too many 2.4 GHz WiFi networks, or just a little glitch in the connection to the ST cloud, and the keypad receives the desired response in reaction to entering the pin-code too late. That causes the famous light show, temporarily disconnecting the keypad from the hub. If I’m lucky, the hub receives the arm/disarm command a few seconds later. If not, then loud noises and flashing lights. So, not so happy about that. Also, not much can be done, except switching to a local system like hubitat. That scares me a bit ;).

Onwards to two possible solutions:

  1. A tablet or a small phone attached to the wall, using a simulated keypad (with the screen in ‘always on’ mode) or just a button on the screen (after unlocking the phone with a thumbprint) to arm or disarm. This will circumvent the issues the keypad has with the slow response times - am I right?

  2. Using the rfid-keypad you’re using (this one? -> https://www.hashop.nl/rfid-keypad-tag). Are you experiencing issues with dropouts?

The simulated keypad works on Wifi, then posts the ST system. Will it be faster, hard to say.

I don’t use this device. It’s not supported by ST, SHM Delay, or Hubitat as far as I know. No idea how it connects.

If you are experiencing keypad dropouts, there are two causes:

  1. Slow cloud response
  2. weak Zigbee signal or interference. This may possibly be mitigated by installing a Zigbee repeater near the keypad.

BTW most of my system is now running on Hubitat.

I’ll chime in again.

I feel like I have wasted a lot of time here, I’m sure you can scroll up a bit and see. I had loads of odd issues.

Anyhoo, without delving into details my house electricity supply suffered from voltage fluctuations due to damaged equipment on the main fuse board. My smart lights picked up on this (voltage drop error) and to cut a long story short it’s repaired. Since then I have suffered zero hub dropouts etc.

I cant say for sure whether the above issue was responsible for the hickups I had, but due to my experiments with virtual switches and a stack of simplifying/optimising, I’ve got my system working spot on now.

The relevance? I added a rfid keypad. This is cheap as chips and connects via the fibaro ubs (which I already had installed for temp measurements of the hot tub).

I can arm and disarm my alarm with either a key code or a keyring fob, or the usual way through the shm dashboard.

Works perfect. Very very happy with it. And virtually instantaneous reaction time. I’ve also hooked up some 12v indicator lights to show what the alarm status is.

Looks excellent! Could you tell us a bit more about the rfid-panel? What’s the exact name and where can I buy it? And how did you hook it up to the Fibaro ubs? Can you arm in both ‘home’ and ‘away’ modes?

@arnb: thx for the reply about the dropouts. I’m guessing the multitude of 2.4 GHz Wi-Fi signals in my neighbourhood are interfering with my zigbee-signal. Repeaters have had limited success. Not a problem for me, since I usually arm and disarm using Siri ( through Homebridge on my Synology server) but my wife is more of a buttonmasher than someone who likes to talk to digital assistants.

Bought this panel (but to be honest, they’re all the same)…

I’m away from home so don’t have the wiring diagram handy, but there are 2 inputs on the fibaro and you wire the NC/bellbutton (don’t recall) to them. I use the bell button to arm the system (just have a routine set which runs when input 2 is opened, which sets the shm status to armed). The 1st input is linked to the NC connection which is is temp opened when you touch the panel with a (valid) keyfob or type in a code. Again this is linked to a routine which just changes shm to disarmed when ubs input 1 is opened.

I only arm in away mode, but it would be simple enough to set a rule which says “if current mode is disarmed and the button is pressed, change to armed (home). If the current mode is armed (home) and the button is pressed, then change to armed (away)”

I. E. You’d need to arm twice… Not the end of the world =)

Thx! I think I can come a long way on those instructions. And I can always hide a small Zigbee button behind a coat that arms in Home mode. If you arm (away), do you get the grace period using SHM Delay? What’s the behaviour after a power outage?
And a last question: does the Fibaro ubs fit behind the rfid-panel? That would save me some extra wiring running into a closet.

Yes to grace period. SHMDelay is pretty awesome. After power outage system auto powers up again. Fibaro would probably squeeze in beind the panel but might be a push. Would be easy enough to mount the panel on a frame to give a bit more room, but remember both the ubs and the panel need to be powered by a DC power supply anyway, so you’ll need some wiring somewhere.

1 Like

Challenging project - or it is for me. However, it looks great and the SHM Delay integration sounds awesome. And, it might just solve the problem I’m having with my Iris Keypad disconnecting, due to the Fibaro being z-wave instead of zigbee.

I’m experiencing a security problem with Mode Fix when combined with Google Assistant, and I’m presuming Alexa integration.

I have Google Assistant integrated with SmartThings. When I have Mode Fix enabled, someone can verbally DISARM SHM Alarm by triggering the “I’m Back” routine (“I’m Back” changes location mode to Home and changes SHM Alarm mode to DISARMED). When Mode Fix is disabled, or when SHM Delay is completely disabled, Google Assistant can only set the location Mode to Home, but it will NOT set SHM Alarm to DISARMED (this is the correct behavior).

I only have three location modes: Home, Night, and Away.
Under Active Mode Fix, it was set to the defaults (Disarmed: Home, Home; Armed: Away, Away; Armed (Home): Night, Night).

I’ve disabled Mode Fix now. I didn’t really need it, because I’m pretty good about triggering both the SHM mode and the Location mode together in my automations. I was interested in using it as a backup. I"ll just use Webcore as a backup, so that changes to all of the SHM Modes will force a change to the corresponding location mode. Additionally, changes to the location modes of Night and Away will force a change to the SHM Mode of Armed (Stay) and Armed (Away), respectively. I don’t want SHM to be forced to DISARMED state when location changes to Home.

Hi Arnb,
Thanks for your reply over in the Keypad section. I have a Xfinity 3400-X keypad. Modefix appears not to be working for me when 1) I arm from Actiontiles and 2) disarm from keypad - alarm is turned off but keypad icon lights still indicate armed. I tried creating a Modefix profile (I did not change from the default settings but clicked Save) and I have Modefix on in the General settings.

more information, if I enter PIN a second time icon light goes off.

Modefix does two things:

  1. Keeps the armState and mode in sync
  2. Adjusts the keypad lights when arming occurs from a non-keypad source.

What may be part of the issue is lack of establishing an additional mode “Stay” in the IDE to match the keypad. However, it should work without the additional mode.

It’s also possible there is a code error, try turning on logging in the IDE, try the failing procedure, then forward any SHM Delay errors in the log.

Should this issue not get resolved, send me a Private Message with your phone number and a good time to call you.

Keypad lights always set from a pin entry.

2019-06-27 1:59:36.877 PM CDT
moments ago DEVICE armMode disarmed Xfinity 3400-X Keypad arm mode is disarmed
2019-06-27 1:59:36.869 PM CDT
moments ago APP_COMMAND setDisarmed SHM Delay sent setDisarmed command to Xfinity 3400-X Keypad
2019-06-27 1:59:35.962 PM CDT
moments ago DEVICE armMode disarmed Xfinity 3400-X Keypad arm mode is disarmed
2019-06-27 1:59:35.953 PM CDT
moments ago APP_COMMAND setDisarmed SHM Delay sent setDisarmed command to Xfinity 3400-X Keypad
2019-06-27 1:59:35.922 PM CDT
moments ago APP_COMMAND acknowledgeArmRequest SHM Delay sent acknowledgeArmRequest command to Xfinity 3400-X Keypad
2019-06-27 1:59:29.997 PM CDT
moments ago DEVICE armMode entryDelay Xfinity 3400-X Keypad arm mode is entryDelay
2019-06-27 1:59:29.884 PM CDT
moments ago APP_COMMAND setEntryDelay SHM Delay sent setEntryDelay c

I’m a bit confused, these messages say they are from SHM Delay, but do not match anything produced by the version I am running, Beta 2.3.0

Please check your install and confirm you are seeing the image below in the Classic phone app after clicking Automation → Smartapps → SHM Delay → then scroll to bottom. You should be running version 2.2.9 corresponding to the latest user release

Yes definitely 2.2.9 thanks.

Your debugging messages do not match anything produced by SHM Delay! What DTH are you using for the Keypads?

Well, in frustration i uninstalled SHM Delay (all components and the keyboard DTH) then re-installed, which hopefully will clean any junk. Haven’t had a change to thoroughly test yet, but will soon and will let you know, thanks.

I am trying to configure SHM to have the Konnected Buzzer beep when my entry door is opened and continue beeping until the mode is set to Home.

I originally tried using Smart Lights, but there is no way to stop the beeping when the mode is changed. I believe SHM Delay BuzzerSwitch will do what I want, but I can’t seem to get it to work. I have the app installed, but I am unclear on how to configure it and/or configure the devices to work with it.

It triggers off of SHM Delay events. You must install and configure SHM Delay.

I have delay configured. I was using that with my original Smart Lights configuration. I don’t know how to tie the BuzzerSwitch to that configuration.