So I created an automation that is based on a virtual switch. I have one automation to arm the STHM (new app) and one to disarm. Neither one has any effect on the STHM when the vSwitch is triggered.
At this point, I cannot tell if the Automation is not detecting the vSwitch turning on (history shows the switch turning on and then turning off, as expected), or if the action is not taking place.
What steps can I take to debug either the Automation Detection of the switch or the communication to SMTH to arm/disarm?
How are you turning the Vswitch on and off? I’ve had momentary type switches state not detected in Automations. It seemed like the switch was turning on and off before Automations could detect it.
In the testing phase, I am just manually triggering the momentary switch from Devices.
I have used these types of switches successfully in the old app and in WebCORE.
So the ultimate goal is to use WebCORE pistons to continue my Good Morning, Good Night, Home, Away conditions. This is what I currently have at the end of each piston:
Except WebCORE cannot directly modify the SMTH status, apparently. So instead, I am planning on using WebCORE to turn on the vSwitch at the end of processing to set the alarm status.
Do you turn off the switch at the end of your processing? I was having problems with the non-momentary switches originally because of the “If {switch} is on”, the piston kept repeating itself. With the momentary switch, it turns itself off, and alleviates that issue.
I will test with a non-momentary switch and see if the processing works as expected and let you know.
I have eliminated all momentary virtual switches as Smartthings staff has previously stated that eventually they will not be supported in the new app. I use power allowance in smart lighting to turn switches off after 1 minute or use waits in webCore.
So you use WebCORE to set the Location, and then the automation is triggered by the Location to set STHM?
I tried using a non-momentary switch to set STHM to Disarm, BTW. I also set a timer on the switch to turn off after 1 minute. The automation seemed to have some lag (up to 45 seconds) in detecting the switch condition.
I like your method of setting the location, and I will test that as well.
Thank you for your input! Many ways to skin this cat, and I like seeing other interpretations!
I actually use Automations for everything STHM. I’m using SHM Delay 2.0 because I have a keypad too. I have Automations that check the current mode and then set STHM if the mode does not match the STHM state. I also check STHM state. If it changes (like use the app dashboard) then I’ll set the mode accordingly. It takes 6 Automations to do that. I use the 3 virtual switches for various other indicators within the system. I could probably do without the virtual switches but if it’s working why mess with it.
Thanks for your help. I wound up using WebCORE to set the Location, and in the new app, I use Automations to test for location and set the STHM accordingly. No vSwitch needed.
Its fun making this migration, but this is one of the last things I needed to set before getting rid of the old app.
Your welcome. I made the jump awhile back when @arnb worked with me to make the changes to SHM Delay 2.0 to work with the new app. I have 2 DTH that are still flakey. The DTH for my UEI keypad works but it doesn’t display correctly in the new app and the DTH for the Hampton Bay Fan controller doesn’t display/work quite right. I have work arounds for both. If the new app was as fast as classic I would be a real “happy camper”.
