Hi, sorry if I’m being dim but I just received the update for the new app and thought I’d look at controlling SHM with automation. Working through the wizard I managed to create an automation which sets SHM to armed away when my phone isn’t at home, so far so good, I then tried to create the reverse i.e. when I get home SHM switches to disarm. The app doesn’t seem to be able to do this, it only allows if phone (member) is at home then choose state, if I choose disarm would this work or as I fear would this also disable the armed stay option?
You should be able to disarm SHM when a member arrives. I just set it up a couple days ago and it’s working for me:
I’m not sure what you mean by that. Can you clarify?
I think the OP is a thinking that because he is already at home, armed stay will automatically disarm.
It will only disarm “when you come home”. You actually arriving at home is the trigger to disarm.
If you are already at home when you set either armed stay or armed away it’s not going to disarm.
At least that’s the way classic operates and I’m assuming the V3 app is the same. Am I right @johnconstantelo
Thanks, exactly what I meant and question answered, the phrasing when at home rather than arrives at home was the confusing aspect.
I haven’t used STHM in the new app yet so @johnconstantelo will let us know if my assumptions of the new app are correct. 
Yes it seems to follow your description I’ve just set armed stay in the new app SHM obviously while at home and the autumation doesn’t affect it, just the phrasing is confusing as I said.
3 Likes
As @Peter_Wood just replied, it can be confusing. I also have an armed stay scenario and it doesn’t disarm unless I manually disarm it while at home, or disarm it through another automation.
With the new app’s latest updates and capabilities, I’ve been able to do everything in the new v3 app that I was able to do in Classic, including managing SHM states. In fact, I only have the new app on my home screen instead of Classic!
1 Like
I’ve approximated replacements for the four default Classic Routines by replacing each with two custom automations and depending on my having a one to one correspondence between SHM security mode and location mode. This gets me round the limitation where the mode can’t be both a condition and an action.
There are two gotchas when using the security mode as a condition in custom automations. Firstly you can only select one security mode as a condition, unlike with the location modes. Hopefully that can be remedied as it is unnecessary. The second gotcha is that changes to security modes do not trigger the automations. That’s fair enough, but I feel there ought to be some indication in the app that this is the case (I’m assuming there isn’t) as I got caught by that one before I had the light bulb moment and uttered something appropriate.
Update: This ‘second gotcha’ seems to be nonsense. I can only imagine I was being misled by an interaction with something else.
Snap. There is quite a bit of snagging to be performed and some bits that need a tad more work but it is a lot further on than I anticipated (I’ve only had it a few days as the app is massive and I didn’t have anything that could run it).
1 Like
Yup, correct. I’m sure there’s a reason, perhaps to protect a user from selecting a combination of security modes that never trigger?
That can now be done with the latest release. Is this what you mean? Here’s an example:
Yes I know, and I’ve spent quite a bit of time going through all my use cases for automations, Routines, and smartapps in Classic to see how/where the new app can do the same thing.
1 Like
It was what I meant, and when I was writing the automations on Monday it just would not trigger on SHM security mode changes. I was using the security mode to chain two automations together rather than using a virtual switch and I had to redo them to use the location mode in the middle. Today it is as happy as Larry to do it. No idea how I managed to screw up but I wish I’d double checked before I wrote anything. Ho, hum …
2 Likes
I think the biggest workaround I’ve had to overcome is with modes. Two things:
- as stated above, can’t use a mode as a condition and action. Usually get around this by using a scene and then adding the scene to the action and then updating the scene with mode change after.
- mode as an IF in the new app is also a trigger. For a routine in Classic it was only a filter/condition. This has caused some wonkiness with looping/interfering automations in the new app for me.
2 Likes