Yea. I just turned it off to test and see if that was my issue. Been working flawlessly now for 5 days. I am assuming that was my issue. Now I just need to figure out where I am going to put it. I’m thinking in the middle of the house by my thermostat. Anyone know if mounting the hub vertically on the wall will affect the signal?
There’s a discussion on that here:
Summary:
There is some directionality to the antennas in the hub, but it probably won’t kill you too much to have it wall mounted. Try and keep the front and left (looking from the front) roughly pointed toward things, and not straight into concrete or metal, and everything will probably work fine.
–Zack
Just got home and keyd in my PIN to disarm but the alarm wouldn’t disarm. Then all my alrms started going off. Even after i manually ran my Home routine the alarm kept picking up new movement and going off…I had to remove smart alarm to make it stop
That’s quite alarming (No pun intended) to hear. It looks like smartthings is still (again!) having issues with smartapp execution, this time including even things like arming/disarming SHM (Which is what controls SmartAlarm’s state).
This page will show you the status of smartthings services, and if there’s any outages that might affect things. Right now they’re experiencing “above average error rates in some areas” on smartapp execution.
http://status.smartthings.com/
So… Sadly, there’s not much that can be done. I’m sorry it broke so terribly though.
–Zack
To add more: Looks like some others are having a similar issue: Mode changes not triggering SmartApps:
@JDRoberts in that thread indicated:
“There has been a recent bug reported where changing the mode would not then trigger the things that were supposed to trigger from that mode change.”, which sounds like exactly what happened.
All (especially @swindmiller and @Navat604):
I’ve updated SmartAlarm (Same link as in first post!) to now separate the option for disabling the delays in stay mode. This allows us (Including my wife, who’s quite happy with the change) to disable the arming (exit) delay, without disabling the 30 (or more) second delay to disarm the alarm if someone forgets to disarm the alarm in the morning before letting the dogs out, or whatever morning ritual involves triggering a sensor.
The new defaults are:
Disable arming (exit) delays and enable alarm (entry) delays while in stay mode.
1 Like
Actually…that other thread seem to be the opposite of what has been previously reported (which I did mention in that thread). That is the “SHM not changing mode” is reporting that the mode itself didn’t change.
The bug that I mentioned was first reported in September where the mode would change, but then nothing that subscribed to that mode would actually happen.
You can find it on the first bug report page in the community – created wiki under smartapps in September 2016
http://thingsthataresmart.wiki/index.php?title=Bug:_First_Reports
I’m not sure whether what people are discussing in this thread is:
A) SHM alarm state not changing
B) mode not changing
C) SHM alarm state changing, but other things not happening that should happen if it changes or
D) mode changing, but other things not happening that should happen if the mode changes.
Those are four different possible bugs. 
Given the symptoms, and that he’s using SmartAlarm, which tracks location mode (not SHM mode), it would either be situation B, or D. I’m not sure which happened here, but I would assume, given the ack’d issue, and that when he ran the routine manually, SmartAlarm didn’t catch it, the mode changed, but the triggered events (in this case, disarm SmartAlarm), didn’t run.
Post 64 above says:
arming/disarming SHM (Which is what controls SmartAlarm’s state).
So that implies SHM alarm state is involved. But it can be hard to tell for sure. A lot of people say “SHM mode” when they mean “SHM alarm state.” So you usually have to untangle that before you can tell what the symptoms are.
1 Like
This is definitely not true. Smart Alarm is using mode and not the state of SHM.
@zcorneli thank you so much for the entry delay silent in stay mode. This is really awesome.
1 Like
It seems to be an issue with modes and routines. My night routine ran but never changed modes to arm alarm and the routine failed to turn off lights
I actually did confuse mode with SHM alarm state there, it’s actually using the location mode, and not the SHM alarm state to control the SmartAlarm arming mode.
It does look like (Especially with @Zevans08 response) that this is an example of the “mode change not triggering routines” issue documented in the bug reports.
1 Like
I have ULM and smart alarm installed with 2 iris keypads working. The major reason i wanted these is for the ability to have a chime when a door or window opens. i have it all setup for the chime but it is not working when i open a door or a window nothing no chimes. what is working when i set the alarm with the delay the keypads beep for the duration of 60 seconds. can someone help me with getting the chime to work when a contact sensor is open and i would rather not have the exit/delay beeping sound… Please Help
Make sure you are using the latest version of SmartAlarm. You need to go into “Notifications” section and set your keypad as a chime device.
Then it should chime for whatever sensors you set in the “configure zones” section.
Excellent, thanks! I will try it out as soon as I can.
I sent in a ticket and according to them the mode and routines ran as they were supposed to. So im guessing D.
And now im having issues with the keypad in general. LED doesn’t change colors and I don’t get the exit delay beep. When I look it up in the app the status always says enrtydelay; I cant get it to update. According to logs it’s been in entry delay mode for 2 days
I just armed the house from my phone and this error showed up…
This error also shows up when trying to manually refresh from the phone…
c4a060b8-5304-4b5e-baa8-3b5e2d056ac5 8:30:39 AM: error java.lang.NullPointerException: Cannot execute null+null @ line 228
c4a060b8-5304-4b5e-baa8-3b5e2d056ac5 8:30:39 AM: trace Arm mode: entryDelay
c4a060b8-5304-4b5e-baa8-3b5e2d056ac5 8:30:39 AM: debug Sending status to device…
You can see that the current mode is entrydelay; which is incorrect.
Motion and temperature will update but only visible when you view “recently”
all DTH and apps are up to date from above post. In notification my key pad is selected for chime and also under configure zones all contact sensors are set to chime on open. I do get a chime every second on exit delay. Any other ideas? Thanks
I just realized mine isn’t reporting battery life, it’s been at 100 since I last replaced the batteries and I don’t see any status updates from when the previous ones died. I graph these and it shows about a year at 100, never a change.
And since two days ago, that I noticed, the off light remains red all the time now. Is that new or have I just never noticed before?
Is there anyone here that can help me trouble shoot me not having a chime when something opens?
Try checking the “Send status to device” button in ULM, then changing the SHM mode (I know you’re not using SHM, but User Lock Manager follows the SHM state), and then unchecking “Send Status to device” again. That should get it out of exitDelay. The only way it would have gotten stuck in exitDelay would be that the scheduled task to finish arming SmartAlarm didn’t run. I’ll probably put a separate check for this into the device handler, just to make sure things don’t get broken like this again.
Check in the preferences for the device (select the device in Things, then hit the gear in the top right corner), and make sure “Enter length of beep in seconds” is set to 1. I think it defaulted to 0 at some point, and wouldn’t have been updated if you installed that version of the DTH originally. If you set it to 1, that might get the chime working.
–Zack
1 Like