[OBSOLETE] SHM Delay Version 2.0

Update - must be a timing issue. When linking the voice announcement to a virtual switch (which is ON when alarm is fully set, no delays active etc), voice announcements don’t behave as they should (see post above).

If however, I link them to a physical smart socket instead - perfect.

Mental!

-=edit=-

Another update! Perhaps I’ve discovered the limits of the platform…?

In a nutshell, I use shm delay along with the buzzer module, virtual switches and some smartlighting rules to determine what’s going on with the alarm.

i.e.

  • alarm completely disabled
  • alarm set, still on the way out the house, an exit delay
  • exit delay completed, alarm now fully set.
  • re-entering the house, entry delay active, waiting for alarm to be disarmed.
  • back to the first stage again (alarm completely disabled).

Depending on which stage it’s at, the hope was to hook up an indicator panel with red, amber green, and a buzzer to clearly indicate what’s going on. I also have things such as a flashing external alarm box to show the alarm’s active, and various sirens which are triggered if there’s an alert.

The aim of all of this was to to create a kick-ass smart system whilst maintaining absolute wife-friendliness. The cherry on the cake was the addition of a rfid panel hooked up to a fibaro ubs allowing seamless and mother-in-law-compatibility, with a few voice alerts using big talker.

Clearly I was hoping to keep the majority of this running as locally as possible, with minimal reliance on cloud. It’s worth noting that had I envisioned I’d be doing as much as I am with the smart platform, I wouldn’t have chosen smartthings due to the issues with cloud reliance, but as with all things, the project started with a bit of mild curiosity and the purchase of a starter kit to control some christmas lights!

As you can imagine, the setup I have now involves a fair amount of “if this, then that, change mode, flick this switch on, flick this switch off…” etc.

Apparently herein lies the problem. Sometimes in the instance where a trigger of some sort might need to turn off 3 switches, turn on, and change the mode and alarm status… you may find that not all switches are actually flicked. An maybe the mode will change, but the shm status won’t. The troubleshooting has been a bit of a pain purely because there hasn’t actually been any errors in my logic, it’s just been partial intermittent ‘misses’.

I’m still keen to figure a way around this, but it seems the problems may be insurmountable. It’s completely doing my head in to know that, for example, shm is supposed to disarm, change the mode to home, and turn a switch off. Using one switch to trigger this works just fine, using another will do all but change shm status, breaking the logic, so to speak.

Sorry to hijack your thread - was never the intention ! Your software (along with kiosk browser) has been an integral part of this all for me, and I truly appreciate it. Maybe hubitat is going to be the next step, eh ? = )

-=/edit=-

Hey, I use the SHM Delay 2.0 for my security system and am looking for a new keypad that will be compatible with it. I have a Iris V2 keypad which gives me a lot of issues. I also have a friend looking to build his system from scratch very soon. What keypad should we get?

I’m not sure if this was brought up in any of the previous posts, but Centralite filed for chapter 7 bankruptcy in March 2019. ( https://staceyoniot.com/centralite-has-filed-for-chapter-7-bankruptcy/ ). I don’t feel like I want a keypad from a company that can no longer support it, if needed.

Are the TCH / UEI / Xfinity keypads the only ones left? or did Centralite somehow make them too? Does it even matter?

Thanks for the help!

If the keypad works it really does not matter. About all that is available today are used UEI versions. Don’t get an Iris version 1, it will not work. When buying used make sure it has the mounting plate.

The first Xfinity keypad was a Centralite clone, Iris V2 was also made by Centralite.

I am using an Iris v2 keypad with the SHM Delay 2.0 and I am curious if there is a way i can make it so putting in a certain code will cause an action to be done. I dont know if that is possible or not but is something I am curious about.

OK… I have searched high and low, so now I beg your assistance.

I cannot figure out how to enable “exit delay beeps”. I am intending to use the pin-protected SHM tile in ActionTiles to enable and disable SHM. However, we need exit beeps to tell everyone “its armed, get out!” Even if using the ST Dashboard to enable, I would want exit beeps. However, the only context I can find for exit beeps is in relation to a real keypad (iris).

I see the settings for entry delay beeps in delay profile, but I cannot find exit delay beeps. What am I missing?

Exit and Entry beeps are hardware commands issued to keypad devices.

Since you are using ActionTiles, consider using the SHM Delay Talker module, the Fully Browser, and the Fully Browser DTH, to generate TTS messages about the state of the system.

Thanks arnb,

Im confused by this though, as it doesnt appear to be completely true.

There are entry delay beeps in the app without Talker/TTS, but no exit delay. I don’t understand why it would have one, and not the other.

I don’t actually want it to talk. I have a chime, and I just want the chime to beep. We dont really use ActionTiles, as we mostly arm SHM from ST Dashboard, and we would want the chime to beep regardless of ActionTiles.

The keypad uses a single hardware command to generate beeps for a specified time duration. Doing this with a “chime” device requires multiple commands issued perhaps every second, this is not recommended using the SmartThings cloud based code running over the internet, but would be feasible with a locally based hub, such as Hubitat.

So i updated to the latest version and now my Iris 3405-L Keypad no longer chimes… What did i do wrong?

I don’t know.

Verify the Delay Profile (page 2) “Beep Chime these devices” has the keypad(s) defined. Save the profile (even if already set)

Ok so page two wouldn’t open on any of my delay profiles… I just went ahead and deleted them all and started over… hopefully that fixes the issue. I’ll know tonight.

If I encountered that issue, I would review and save all other profiles and system Globals.

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.