Did it with Sharptools but didn’t realize you could with kiosk. Just did it and bingo. Looks sweet. Thanks Josh
Dave
1 Like
Hi my friends, now Im running a Sharptools dashboard using virtual momentary buttons created by ADT Tools 2 Smart App in Classic app that handles my ADT/ST panel, I can see them in IDE and work perfectly. When I migrate to new App can I still use them ? Or I have to forget them and try new ones ? Im worry because I understand that STHM changes its status when ADT/ST changes its, but no visceversa, ADT Tools 2 smart app helps on it, but what will it happen when I switch to the app? New App handles ADT/ST Panel ?
Hi @Carlos_Juarez, STHM is not open for 3rd party access yet, but you can create virtual switches and create automation rules to sync the STHM’s status to the old SHM and ADT/ST panel I believe.
In the new App, create automation to turn on the specific virtual momentary button (switch) created by the ADT Tools 2, which should change the ADT panel’s alarm state.
From an STHM perspective, I doubt it. SmartThings never had amazing first-party support for the ADT integration and it looks like they’re not really focusing on it or improving it anymore.
Yes. The momentary buttons will still work.
If you’ve got it working today where you have ADT changing STHM and STHM changing ADT, then you are all set. If you don’t have STHM changing ADT, then you probably need to setup a Custom Automation in the new SmartThings Mobile app for If STHM Changes, Then trigger the relevant ADT Tools button.
1 Like
Right. A tad confused because I’ve always used WebCoRE for presence to activate arm away. Which had worked very well. Now I believe that I can no longer use WebCoRE presence. So … any ideas on how I might get the STHM to automate when leaving. Is this not an option any longer using presence ?
Hi @Totally_Nuts, you can still use presence to change STHM status automatically. I’d suggest to use Life360 app and integrate it with your ST account as the presence sensor. Life360 is the most common and recommended among the ST users. Then you can add a new Automation in the ST new app - If your Life360 presence sensor is “Not Present”, then change Security mode to Armed Away.
I think what James is trying to say is that you can use the Virtual Switch approach mentioned in the first post - this creates virtual switches that you can flip on to arm or disarm STHM. Then you can use those virtual switches in any SmartThings integration that can control switches.
I haven’t personally used webcore presence sensor, but from a quick Google Search, it looks like it uses the webcore mobile app along with a custom virtual device, so I don’t see any reason why it shouldn’t keep working (for the time being).
As James noted, Life360 is a really popular solution for accurate presence reporting.
Well I’m not sure if I’m doing something wrong as I’ve only just started using the new app but when I try to automate the the virtual switch to turn on with WebCoRE presence it’s not showing my presence sensors as an option. The phone presence is there but nothing else. I actually paid for each WebCoRE presence sensor on each phone as when I tried it it worked every time. Had life 360 and had some issues like constant away when home even when all settings were correct. Still at a loss of how to turn STHM on when everyone leaves.
Just to reiterate, you’ll want to go through the steps in the first post of this thread to create the virtual switches that control STHM… then in your automations (in SharpTools, WebCoRE, or any other SmartApp), you can use those virtual switches as a proxy for controlling STHM.
In other words, you don’t have to build the presence automation in the SmartThings Mobile app… just the virtual switch to STHM mapping.
Hmmm. Well I have followed the steps above and made 4 virtual switches. But it’s the presence that I’m having an issue integrating as i can’t find the presence sensors I used before in the new app. Maybe a just need to mess a bit more with the new app as ive only just started with it. It’s all new to me LOL
[Bry] (Profile - Bry - SmartThings Community)Bryan Community Master
@blake.arnold Is there some reason STHM isn’t exposed via the API as SHM was? I just converted to the Connect app and I use Sharptools dashboards as a primary means of interaction. Arming and disarming SHM via Sharptools was easy. With STHM, it’s only semi-doable and awkward because STHM is apparently not exposed. Even with a hack, there is no way to “externally” confirm the STHM setting.
Response from Blake Arnold:
Yes - we looked into opening up STHM via the API before we started first rolling out migration and determined that doing so would present an unacceptable security risk to our users. I can’t go any further into the details than that, but it was an intentional decision, not an oversight.
JDRobertsHelpful
[quote=“blake.arnold, post:1841, topic:183948”]
I understand the reasons for this, it’s what most security systems do. However, there is a big missing piece, which is a locally processed keypad and a locally processed key fob which can both change the security.mode so that you can arm or disarm STHM even when the smartthings cloud is not available. The dual logo ADT/SmartThings system had this, and it is very much missed in STHM.
Yeah, it’s frustrating that they won’t open up the STHM APIs. Seems like there are some people within SmartThings who are supportive of it and reading between the lines, it seems like some corporate red-tape kind of stuff preventing them from doing it.
At this point, they’ve opened it up via their built-in Custom Automations, so it seems like users are given at least some level of choice. I can understand wanting to have some level of limitations on just letting the API loose, but why not allow a whitelisted set of trusted third parties to have access to the API.
1 Like
Hello and thank you for the instructions. I am having a problem with the automation having followed your instructions and the YoutTube video linked to it. I really would appreciate some help here as I have been busting my head for the last few days trying to get it to work.
I have ALL three virtual switches and ALL six automations (x3 switch and x3 STHM State) configured as illustrated. I can select an STHM state and virtual switches change accordingly and vice versa BUT only a few times. After doing so 2-3 times, the app goes into this loop where it continuously toggles between the last two states. If I then select either the third state OR switch then it toggles between all three. It does not generally stop until I disable the STHM Status automations but there are times when the loop seems to sort itself out after some seconds have passed. I have cleared cache and force stopped and restarted the app and it still occurs.
Any idea what may be happening here? Your help will be truly appreciated!!
Thanks…
Welcome to the community and thanks for posting!
Try changing from Virtual Switches to Simulated Switches.
There was some discussion over in the SmartThings community about automations getting looped after SmartThings made some backend changes related to virtual switches and the commentary indicated that switching to Simulated Switches solved the issue.
3 Likes
Thanks a lot Josh for the time and quick response. I will definitely try that and give feedback on how it worked out. I assume that I can just change the Device Type in the Samsung IDE.
Will revert once completed…thanks
Is that why mine now run about 15 times per disarm, lol?
Hi Josh:
That DID it!!! 
I went to Samsung IDE and changed all the related Virtual Switches to Simulated Switches. Everything works brilliantly now!
Thanks a whole bunch for the original post and for your responses to my enquiry. This was driving me nuts over the last week or so and I am now relieved.
Great work…thanks again
3 Likes
Hi Bry:
I guess you were having the same issue as I did. Josh’s suggestion solved it for me by changing all the virtual switches to simulated switches. I can’t say that I know why they funtion differently but the looping has stopped and it all works together now as one would expect.
Good luck…
Just curious, but should we also start switching all other virtual switches to simulated switches? Is there any benefit to moving over since they seem to be redundant in concept but clearly mean something different to ST.
Either way, this solved my problems with STHM so thanks so much for this awesome community!!
1 Like
Thanks for the feedback and confirmation - I’ve updated the article at the top to reflect the preference toward Simulated Switches to prevent looping.
As to the background of what seems to be happening…
The big difference is the Virtual Switch will always send the on command as a state change (even if the switch was already reporting as ‘on’). The Simulated Switch on the other hand will only flag it as a state change if the state actually changes from ‘off’ to ‘on’. So if the switch is already reporting ‘on’ and the on command is sent again, no state change will fire for the Simulated Switch. Whereas with the Virtual Switch, it fires a state change again even though the switch is already on which can trigger certain automations to run again.
2 Likes