It has been a little over a month since my first weekly update. I’m proud of the progress we are making and it has been wonderful to see the support from so many in our community who are feeling the improvements in their day to day experience with SmartThings. We are going to keep at it!
Here’s a summary of some of the progress we made this week:
Hub Firmware Update - 14.40
We released a new firmware for the V2 hub that had two very important fixes. We squashed a bug that could cause the hub to go offline even though the hub LED was green and also addressed an issue with Z-Wave device identification.
Platform Updates
Our platform release this week had a ton of backend changes to improve latency across the platform as well as a fix for IDE event streams. Take a look at the release notes for more information.
Smart Home Monitor
Our Smart Home Monitor engineers made significant strides in arming and disarming errors with this week’s update. They worked the logs, combed the code, and made some tweaks. These tweaks made the arming and disarming error rate decrease by a further 85% from the already big improvements of recent weeks.
iOS/Android Mobile Apps
We did a lot of work on the backend to further improve mobile app stability. This week we rolled out a range of changes to the way the mobile app communicates to our client connectivity API. I’m happy to report that these changes have further improved app crash rates to less than 0.10% for all mobile sessions over the past 24 hours. The industry average for iOS and Android is about 3%.
I am hopeful you are seeing the positive effects of the work we are doing on the platform every day. I look forward to sharing our progress again with you next week.
All of the updates have been very promising and I am happy to say that my personal setup has been very solid for the past few weeks.
One question about SHM improvements; when are we going to get entry and exit delays built into the system? Currently I’ll get at least one or two false alarms a day due to my tenants (who don’t have mobile presence) opening the door after unlocking it using a smart lock. I have it set to disarm the system when they unlock the door but it still takes a few seconds to register.
Great suggestion. What is the behavior you would like to see? For example, auto-disarm when a lock is unlocked as an option? Sounds like you have that set up, but you’d like it to wait a few seconds to enable the disarm to take hold before triggering an incident?
I currently have it set up using @ethayer’s lock code manager, I merged in some code to allow the use of ZigBee keypads which also gives me the ability to add an exit delay but there is no way to have an entry delay.
Having SHM auto-disarm with an unlock might be nice however you’d want to make sure you differentiate between a manual unlock and a keypad unlock. Disarming the house if someone picks the lock would not be a great feature… It would also be nice to be able to change the SHM entry and exit delays, maybe give a range of options between 30 and 120 seconds or something like that. Any routine/SmartApp that calls the SHM disarm command should have this delay applied.
To state the obvious; the exit delay would be the time between the ‘Arm’ command and SHM actually being fully armed. The entry delay would start a countdown when an action is triggered (possible create some sort of trigger for sirens or connected speakers for a warning sound) and only if the house isn’t disarmed in the set time will it actually trigger a SHM event.
4 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
I think this issue may vary from device to device and use case to use case. I have a similar setup to what @blebson has. I have a Schlage Z-wave lock, which takes about 5 seconds to send commands to the hub. I have a contact sensor on my front door. I have my unlock option set to disarm SHM upon successful entry of a user code. The issue is that if I open my front door within that 5 second delay, where the lock is sending the commands to the hub my alarm goes off. This happened so many times I had to remove all contact sensors from SHM and start using Smart Alarm which incorporates entry/exit delays. As soon as I moved my entire setup that issue went away.
This feature request is beyond just for convenience, it is a necessity in cases like this.
Since the update now the hub doesn’t recognise our presence at home until after we’ve opened the door and the alarm and siren has gone off … This never happened before the update ? Previously the alarm would deactivate a good 200 metres from home …
Massively disappointing and frustrating … I’ve spent a thousand pounds on my setup and don’t expect such fundamental regression. Do you have a thorough regression test suite ?
@alex
First, yes the system has been vastly improved over the last month. Thanks.
Second, on the alarm delay, please note carefully the difference in what @blebson is mentioning and what @dshokouhi is saying. There are smart door locks like Schlage, and there are zigbee keypads (like a traditional home alarm from ADT or something). These have very different uses, one outside and before entry while one is inside after a zone has opened. Please design for both situations! As the various rules apps have shown, give us a field to define a delay, do not hard code one. Some might want the 5 seconds, I want 30.
This item is really the last item outstanding for me finally ripping out an old Control4 system controlling lights, AV, thermo and alarm and going all Smartthings.
Thanks again for the improvements it really is getting close.
Yup I have seen the same - I track my partner coming home usually this was prior to her arriving so I could surprise or give her an heart attack now I get a notification when she unlocks the door - too late …
@alex
What about github integration I guess outside the US? Still not available in the UK …
Failed devices (battery) should not set off the alarm, I’ve had that happen with the Smartthings multi-sensors and
When disarmed, if zones are open, it should list them in SHM rather than “Everything OK”. It is ok, but the information of what is open would be valuable
When you attempt to arm (probably a configurable option), it should fail if zones are open (and allow some report out that it failed - chime, text to speech, etc).
Let’s really make an alarm replacement. Your partners in #Scout and #ADTPulse will get more business!
False intrusion alert earlier in the day. Cannot dismiss it because SHM is on an endless spinning circle attempting to load.
So guess what? My phone is going to buzz to remind me of the intrusion every hour throughout the night. Which is nice since I have to catch a 6am flight, it will make sure I am up… sure I won’t get any sleep, but at least I will be up thanks to broken SHM.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
15
Nope, done that too. But, the incident was logged and the Status page updated. I’m back up and OK as of a few minutes ago. My ticket was also just updated.
We are working on bringing developer tools to the UK! Jump over to this thread for more information and to participate in a beta: Github Integration for UK users
Thanks. They issued a fix last night, before you tried. This was affecting all platforms.
Glad it was resolved relatively quickly for sure, but cost me about 2.5 hours of fidgeting trying to disable the dang notifications. Seems to always be something. Just really want to get to a point with HA that things are stable and it provides more value and convenience than distraction and toil.
