Virtual Switches won't change - New App on V3 Hub

virtual
motion
triggers
piston

#1

1) Give a description of the problem
Just migrated from V2 hub to V3 and the new app. Since WC doesn’t communicate with STHM, I’m setting up virtual switches to arm/disarm the stay/away alarm. I have automations in the new app to trigger based on the state of the virtual switches. None of my pistons will change state of any virtual switch in New App on V3 hub.

2) What is the expected behaviour?
I’ve included one example piston: turn off “Night Alarm” virtual switch between certain time and specific motion changes to active and other virtual switches are not on.

3) What is happening/not happening?
Piston is firing but Virtual Switch state is not changed.

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full
Will provide, if necessary.


#2

Have you tried creating Simulated Switches (instead of virtual switches)…??


#3

Part of the problem may be that you are using one of the devices as a condition that you are then changing.

Maybe just have the motion devices as the trigger, only thing in initial if. Then look at your conditions inside the if.

Seeing the log would be helpful though.

If 
    Motion
then
    if time etc
    then
    endif
endif

I have no problem changing virtual switches, but I still have a older hub.

Also are you saying this use to work?


#4

Thank you…I have not tried Simulated Switches. Will the new app play nicely?


#5

Thank you…yes, I had numerous pistons in the classic environment and on the V2 hub that worked great.


#6

I added 2 new Test Virtual Switches, created a Test piston, triggered the piston and it worked!!

Is it possible the new app blocks actions from the cloud that affects STHM or my locks?

Log:

|+1ms|╔Received event [Patio Lights].switch = on with a delay of 116ms|
|---|---|
|+35ms|║RunTime Analysis CS > 18ms > PS > 6ms > PE > 10ms > CE|
|+37ms|║Runtime (37547 bytes) successfully initialized in 6ms (v0.3.110.20191009) (35ms)|
|+38ms|║╔Execution stage started|
|+44ms|║║Comparison (enum) on changes_to (string) on = true (1ms)|
|+46ms|║║Cancelling condition #2's schedules...|
|+46ms|║║Condition #2 evaluated true (4ms)|
|+57ms|║║Comparison (enum) off is (string) on = false (1ms)|
|+59ms|║║Comparison (enum) on is (string) on = true (1ms)|
|+60ms|║║Condition #5 evaluated true (13ms)|
|+61ms|║║Cancelling condition #1's schedules...|
|+62ms|║║Condition group #1 evaluated true (state changed) (21ms)|
|+64ms|║║Cancelling statement #3's schedules...|
|+80ms|║║Executed physical command [Test Mode].on() (14ms)|
|+81ms|║║Executed [Test Mode].on (16ms)|
|+84ms|║║Cancelling statement #6's schedules...|
|+98ms|║║Executed physical command [Test Mode 2].off() (12ms)|
|+99ms|║║Executed [Test Mode 2].off (14ms)|
|+101ms|║╚Execution stage complete. (63ms)|
|+102ms|╚Event processed successfully (102ms)|

#7

To test this, I disabled the automation tied to the Alarm Virtual Switch, added the Alarm Virtual Switch to my Virtual Button Test piston and triggered the piston. The piston fired properly and turned of the Alarm Virtual Switch. Looks like the new app is restricting the use of virtual in automations.


#8

For your original piston, did your logs indicate that all the conditions came back true when the piston fired? Did switch 8 turn on but switch 14 didn’t change or did the piston do nothing when it fired?


#9

Yes, the logs indicated the conditions were true and the piston fired but Switch 14 did not turn off, did not received a notification and Switch 8 did not turn on.


#10

I believe so… The Device Handler is quite different.
Thankfully, it is easy to test. (tips here)


#11

Excellent! Thank you. I was attempting to stay local, but it really doesn’t matter if I’m using WC as my primary rule engine.


#12

If neither switch 14 or switch 8 changed then it seems like it somehow determined the if conditions were not all met and bypassed the block. You might need to confirm in your logs. Seems like something more than just interaction with STHM (unless both are linked to STHM).


#13

I just wanted to point out to users that some changes were implemented over the past few days with Automations in the new app. You can now use location in both the If and then. You may want to check it out :slight_smile:


#14

Thank you, @jkp . I’ve been following that thread since installing the new hub Wednesday. I’ve been using WebCore for a few years and it’s been mostly solid for complex rules. Before that, I was burned way too many times to use SmartThings Automations (routines). I may give SmartThings some non-essential Automations to give them a chance to win my trust back.


#15

I have a few automations using virtual switches in the new app. They are working for me. I use them to open and close my Leviosa blinds which can not be activated via the classic app.

I trigger the virtual switches in WC and when the switches are changed it triggers the automation in the new app. So, for me, the new app is not blocking those automations which use virtual switches.