Great Product!
I’m just getting started so on a vey steep learning curve!
I have the Simulated switches &Automations created and all is working as it should in Sharptools
Now I want to change the Armed Away switch (in Sharptools) to delay the arming for 30 secs while exiting the entry door.
I’ve tried creating a rule for what I thought that should entail but it still seems to arm right away
Can you give me the basics for the rule I need?
i.e. Trigger, Flow, Action
1 Like
I figured it out - created a new simulated switch called Arm Away Delayed - used that as the trigger, 30 sec delay, then turn on Arm Away and Turn Off Arm Away Delayed - Bingo! I had been trying to use the Arm Away as a trigger and realized that was why it was still setting immediately.
3 Likes
Here’s another thing I came up with:
The Simulated Switches work great for SharpTools …
The issue is that Alexa also picks up the same Simulated Switches - now with Sharptools, you can pin protect the Disarmed Simulated Switch - but in Alexa you can’t. And simply commanding ‘disarm’ will execute that!
But what I discovered is that you CAN pin protect a LOCK in Alexa
So instead of using a Simulated Switch, you define the ‘Disarm’ as a Simulated Lock instead.
It makes no difference to SharpTools - works exactly the same way
But in Alexa you can now set up the Unlock to operate with a spoken pin code.
I know we’re in SmartTools here and it doesn’t affect how that works - however I thought others may appreciate that little subtle change that makes that same function in Alexa now be more secure.
You can just edit the Disarm function accordingly.
Nice - great idea! Thanks for sharing. 
1 Like
When I tested it last night, I just added another (separate) switch - a lock - into the system and added that also to Sharptools for testing - it worked fine like that (with both a Disarm and Unlock) - I had programmed it just to have the Unlock operate the Disarm
This morning I tried to simplify things and change the DisArm function directly in Smartthings to be a Lock - it all worked in Smartthings and also in Alexa, but now the DisArm from Sharptools did not work.(it errors says failed to send command)
I re-authorized but it still did not want to execute for some reason …
But then I just deleted the original Disarm Tile and created a new one and it all worked again.
So it’s all good as per my original premise
I’m not sure why Sharptools wouldn’t just apply the new device type directly to the initial tile - after all it is still just directing the simulated device by the same name. It appears that having changed the device type in SmartThings, Sharptools was unable to update that, even with a re-authorization. No big deal, the tile delete and re-apply establish worked out.
Josh,
just a quick shout out for this very helpful post. I’m new to the group/community and have been using Smartthings for about 3 months now. I stumbled across Sharptools and couldn’t be happier. thanks again.
Bill
3 Likes
Hi Josh,
Thanks for all the detailed information on this. I have followed all the sets and all 3 switch tiles are on my dashboard, but the issue I’m having is that when i change from say Disarmed to Armed Away, Disarmed still stays on. I think i have the settings correct but not sure where I’m going wrong.
Thanks
@Blair_Paterson, can you consistently reproduce the issue? You may want to double check if either one below could be the cause here.
Note that SmartThings has some limits on how frequently you can change your STHM state via automation. In general day-to-day usage, you won’t likely run into this, but you may run into it when you are testing things after first setting it up.
Hi James, thanks for the reply. It consistently does the same error, and I’ve only tried it about 10 times. I’m doubled checked and they are Simulated Switches. Not sure what else to try.
Thanks
This is just a shot in the dark, as mine are working fine on Android. I think you’re on an iPhone, and that app has had a number of issues.
Reorder the switches to put the “turn on” one first. For the other 2, add delays so that they fire one at a time. That’s what I would try if mine weren’t working.
1 Like
Hi Bry, Started again and looks like it’s working now. Thanks for the advice.
2 Likes
@josh
Thanks for opening this helpful address and for his post.
I can confirm that I was able to implement this logic for addressing the issue of enforcing the current security mode status (STHM state) shown in the SharpTools tiles when one inadvertently turns all 3 virtual switches OFF.
Should be self explanatory. Here’s a brief explanation below:
First, I created a Variable called ‘STHMstate’ to store a Text value. The initial value is empty.
I then created a Rule ‘Set STHM Variable State’ which triggers when ANY of the 3 switches for STHM states is ON, and then sets the ‘STHMstate’ variable to the name of the switch that triggered the event using Context Variables.This variable will always hold the name of the STHM switch that was most recently on, and as such the current STHM state.
Another Rule, ‘Enforce Current STHM State’, triggers when ALL of the 3 switches for STHM states are OFF, and then compares the current value of the ‘STHMstate’ variable against each STHM switch name. Once a match is found, the rule then turns the matched switch ON, thus restoring the sync between STHM and SharpTools tiles.
Here’s are some rule logs:
Hope this helps. Would definitely be much better if ST allowed direct integration but I guess this’ll have to do.
1 Like
I found a slightly more efficient way.
Link the SharpTools MODE switches to your Virtual Switches via a rule. The Mode switches don’t have a “toggle off” function, thus eliminating the need for code to keep one on at all times.
Then allow your Mode switches to control your variable instead of virtual switches.