Have to agree with @a4refillpad - my sensors had been behaving quite well for the last few weeks. But since last week’s hub update it has been a real mess - may be coincidence but it is frustrating and so much time wasted when we could be adding value and using great apps like ‘Ask Alexa’.
I could give him the benefit of the doubt that he’s just replying to someone in an engaging way and asking for more details to be polite on what is (obviously) a good idea. This enhancement may or may not be on the table, he’s just trying to be an engaging ceo. (I really hope there’s some steak, and not just sizzle.)
To me, I want to be able to arm and disarm the system without using my phone (e.g. by entering a pin on a pin pad). My goal, really, is to not need a phone, rather than to be more tightly coupled to it. That’s where I’m coming from on this. And frankly, that’s required to make me pay for Scout, after the introductory seven months are up.
Yup…that’s the traditional solution that has work for literally decades and it should be considered an essential option. If folks want to use alternative or additional techniques (eg, presence sensors, retinal scanners…) they should not exclude the traditional entry/exit delay with inside house PIN pad. As a base solution, it is very flexible. The IRIS hardware pad is now available, I have written a SmartApp that allows you to use a Minimote to enter a PIN, and SmartTiles will also have PIN support added (currently just use a lock screen) … Oh, and PIN entry on a smart lock is also a possibility.
But these all start with the basic concept.
I guess I can conceive of the possibility of writing a smartapp that goes from mode Away to mode Pending Alarm to either mode Disarmed or mode Armed (and then triggers SHM to actually arm). So the alarm is never really Armed until a bad guy is in the house triggering it. But it would just be such a hack, the App wouldn’t show the “true” state in SHM… it needs to be done right.
In the automated world of SmartThings, pin pads don’t exist. And in a true Home Automation environment, they really shouldn’t be offered. Now from theory to practice, there is a long way. I do have a pin pad hooked to my security system, but I haven’t used it in several months. When we leave the system arms through ST routine via IFTTT. If that fails, my engine arms the alarm and runs ST routine. And if both fail, then life 360 does the same thing 10 minutes later. It’s a shame that we have to use so many redundant triggers, but…at least one out of 3 fires correctly…
Offering more options is almost always more Customer friendly than offering fewer.
And your own example of using 3 redundant “away triggers” is the perfect example. You have many options to trigger “armed” … so there is no reason not to offer exit, entry, and escalation delays along with a secure activation method (e.g., PIN pad, Mini-mote for PIN, App/Web input, and/or presence tags, NFC, lock codes, biometrics, …).
Again, cleaning service.
Or Airbnb guests.
Little kids who often forget their backpacks.
Or in my case, medical aides who come to the house, many of them don’t have smart phones and some of whom may be temps filling in on a one-time basis.
In a true home automation environment, pinpads absolutely should be offered, it’s just not everyone will need them. “Your use case is not my use case.” And all that.
Then i ask for entry,exit alarm delays and pin pads as a tide-me-over until the facial recognition software on the cameras is fully integrated and working at five nines accuracy - otherwise tieing presence to a phone or a fob is not really automation. I should not have to carry a special device with me at all times to enable home automation .
A post was merged into an existing topic: TTS Not working
I disagree. Like you, I use automation to enable and disable my alarm via geoprecense. However, my pin pad is still used by my cleaning people and family, Pinpads should be offered for flexibility.
In theory, no one needs pin pads or delay exit or delay entey…In reality is something different. I wouldn’t have a pin pad if I didn’t have a use case for it. I wasn’t even arguing against it. But would be nice if ST could make this theory a reality.
I didn’t realize the zigbee issues were indeed platform specific, sorry. moving on.
To cheerlead for a second, It’s a good sign that people actually feel comfortable again with the idea of using smartthings for security.
4 months ago I was firmly in the “buy only for neat, lazy, home automation… nothing critical” category. But I feel it’s become reliable enough.
@alex Are you able to look into being able to integrate Smartapp’s into routines?
For example- I have a routine that is set to wake me up with a light and to disable my door security. i’m not currently able to put my Bose speaker directly into the routine due to limitations so i have a Smartapp rule from the marketplace which is for my Bose speakers to wake me up as well. In order to edit these Smartapps, I have to switch between the routines and the Smartapps section which is a little hard to find sometimes. Couldn’t Routines integrate Smartapps so even When you use Smartapps, you can add these to a routine.
I know in the example above i have set both to run at the same time in the morning but with other instances why couldn’t you create a routine where you could say “switch these items on, disable security and run this Smartapp”? As so many people are now creating Smartapps this could help both developers and users.
Thanks for your time
Not to beat a dead horse, but I sit here and my train isn’t moving and… I just hope this is clearly conveying that alarm delays are really useful. The whole thread I’m linking here is a must read if you want to improve SHM. Looking forward to this week’s update, @alex!
Rather than waiting on ST to solve it I have used CoRE to do all SHM options with the exception of the actual modes - I use actions with delays, motion and open/close to trigger, automatic disable on presence sensors, notifications via push/sms, custom audio notifications via samsug speakers etc everything where SHM actually is falling short - the only thing SHM does is monitor the state all the rest I do with CoRE
So what do you do it someone opens a door while the system is supposed to be armed?
Well as mentioned I only use CoRE for any actions so the SHM may still create an alarm but no associated actions
In CoRE I have a wait timer that if expires then notifies via push/sms, alarm via speakers and lights if someone changes SHM mode to disabled I run the I’m back routine and no other action (alarm) is performed
The system however could disable automatically based on presence sensors so I dont need to manually set SHM to disabled in the first place - due to geopresence this disables around 350m from the house before anyone arrives - anyone else I want to be notified
You could also use a timer to notify you via push/sms - use a wait timer to wait a period of time to allow you to take action, eg call someone, use the app to dosable etc until you know you want to do something - doesnt matter reallu if a burglar has 1 minute or 3 from my perspective … The conplete house flashes in red and alarm out of all speakers - they will run anyway …
So in short it doesnt matter what SHM believes to be true if CoRE doesnt match - nothing happens except a false intrusion message in the SHM app itself
Got it - it sounds like an intrusion detection is still being fired, your just surpressing the notification. This would not work with Scout, i think because they would still end up calling (unless you can automatically set the status of the Intrusion Detection to False Alarm, which I hadn’t considered).
It depends how the notification is handled - SHM doesnt send any notifications nor performs any actions in my setup - it just displays the status …
Not sure what Scout is to be honest but all you need to change is whats being monitored and job done I would say …
Edit quick lookup - how are they integrated? Do they receive notifications as well or via oauth?
And to be honest if you only rely on ST this isnt sufficient - I can perfectly flood zigbee/zwave frequencies so no message reaches the hub …
Perhaps, but I’d imagine that’s true of any wireless security system. And retrofitting a wired system to an old house would be prohibitively expensive.
We may be trying to solve different use cases. To me it’s largely any piece of mind and convenience. I don’t live in the fanciest house in town and i don’t have a secret stash of cash or jewels. Average guy trying to prevent crimes of opportunity and keep the lowest hanging fruit out of most people’s reach, with an interface that my family and guests can use without having to keep as phone on them at all times.
Edit : pretty sure Scout receives notifications directly from ST / SHM.