Virtual Switches not reliably triggering Piston every time

#1

Hi guys,

Set up a couple of pistons which attempt to open our old electric gates by triggering a Qubino Flush 1D relay to start the start/stop routine and then lock it open.

The piston itself works perfectly, I also have a close one setup. However the virtual switches i’m using to start them don’t reliably start the pistons.

At first I thought it was because I was using a momentary tile, so I went to a on/off button instead and set it to work when it was switching on and occasionally that wouldn’t start the piston. I thought then it was because then SmartThings wasn’t updating the state of the on/off button so thought that “on” wasn’t a “changed to” state so I changed it to “any kind of on” but again, after waiting a while and triggering the virtual switch, the piston failed to start. As usual the second time I press the virtual button to on it works, but that’s no good for setting in scenarios or using voice controls.

I noticed that despite me telling the piston to fire on changes to any version of “on” it say that it was “on” but evaluated it as false. I assume i’m doing something wrong with the virtual switches.

image
switch.png1178×685 95.8 KB

` 22/09/2017, 19:26:33 +488ms

+1ms ╔Received event [Gates - Lock Open].switch = on with a delay of 73ms
+214ms ║RunTime Analysis CS > 17ms > PS > 47ms > PE > 150ms > CE
+223ms ║Runtime (37128 bytes) successfully initialized in 47ms (v0.2.0e9.20170921) (221ms)
+224ms ║╔Execution stage started
+240ms ║║Comparison (enum) on changes_to_any_of (string) on = false (0ms)
+242ms ║║Cancelling condition #8’s schedules…
+243ms ║║Condition #8 evaluated false (9ms)
+244ms ║║Cancelling condition #7’s schedules…
+245ms ║║Condition group #7 evaluated false (state changed) (12ms)
+248ms ║╚Execution stage complete. (24ms)
+261ms ╚Event processed successfully (261ms)`

#2

if you use switch 9's switch changes to on, does that not work?

#3

That’s how I had it originally and it was seeing that it switched on but didn’t consider that to be a change in state. Which is what was making me think it wasn’t seeing the switch go back to off (or not updating it’s status)

#4

Here are two instances where webCoRE see’s the switch turn on - but for some reason it considers “on” to be a false outcome in one of them.

Here it works:

22/09/2017, 19:28:39 +505ms
+1ms	╔Received event [Gates - Lock Open].switch = on with a delay of 77ms
+188ms	║RunTime Analysis CS > 17ms > PS > 44ms > PE > 128ms > CE
+197ms	║Runtime (37134 bytes) successfully initialized in 44ms (v0.2.0e9.20170921) (194ms)
+198ms	║╔Execution stage started
+214ms	║║Comparison (enum) on changes_to_any_of (string) on = true (3ms)
+217ms	║║Cancelling condition #8's schedules...
+217ms	║║Condition #8 evaluated true (11ms)
+219ms	║║Cancelling condition #7's schedules...
+220ms	║║Condition group #7 evaluated true (state changed) (13ms)
+223ms	║║Cancelling statement #1's schedules...
+254ms	║║Executed physical command [Quibino Gate].on() (27ms)
+255ms	║║Executed [Quibino Gate].on (29ms)
+259ms	║║Executed virtual command [Quibino Gate].wait (1ms)
+261ms	║║Requesting a wake up for Fri, Sep 22 2017 @ 7:30:00 PM BST (in 81.0s)
+268ms	║╚Execution stage complete. (70ms)
+269ms	║Setting up scheduled job for Fri, Sep 22 2017 @ 7:30:00 PM BST (in 80.993s)
+287ms	╚Event processed successfully (287ms)

Here it doesn’t work

 22/09/2017, 19:26:33 +488ms
+1ms	╔Received event [Gates - Lock Open].switch = on with a delay of 73ms
+214ms	║RunTime Analysis CS > 17ms > PS > 47ms > PE > 150ms > CE
+223ms	║Runtime (37128 bytes) successfully initialized in 47ms (v0.2.0e9.20170921) (221ms)
+224ms	║╔Execution stage started
+240ms	║║Comparison (enum) on changes_to_any_of (string) on = false (0ms)
+242ms	║║Cancelling condition #8's schedules...
+243ms	║║Condition #8 evaluated false (9ms)
+244ms	║║Cancelling condition #7's schedules...
+245ms	║║Condition group #7 evaluated false (state changed) (12ms)
+248ms	║╚Execution stage complete. (24ms)
+261ms	╚Event processed successfully (261ms)

Always the situations where it doesn’t work is when i’ve left it for a bit and come back to test.

#5

instead of changes to any of have you tried the trigger changes to?

image
image.png1470×1458 144 KB

#6

Yes - that’s how I originally had it. That’s why I ended up trying to change it to “any” because I thought the issue was that it wasn’t seeing “on” as a “changed” state because it didn’t realise it had been off. But now it’s set to “any version of on” it sees that it came on as the log shows and yet it still thinks that doesn’t qualify triggering the events - i’m not sure why.

I have put it back to changes to and will test again tomorrow. Could this be a bug?

#7

got it. i use changes to with virtual switches in a few places, none of them seem to be misbehaving.

lets see what the logs say tomorrow.