Virtual Switch not working

#1

1) Give a description of the problem
I have several Virtual Switches which are used to control various activities. I have 1 which is used to check whether the lights need to be turned on, during a ;Good Morning; routine from a voice command to Alexa.

The function of the switch has become erratic and isn’t always firing the piston correctly.

2) What is the expected behaviour?
When the Virtual Switch is changed to ‘On’ the piston should fire consistently.

3) What is happening/not happening?
The piston is not always firing.

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

image
image.png1178×662 31.9 KB

5) Attach logs after turning logging level to Full
09/11/2020, 09:08:47 +681ms
+0ms ╔Received event [Check Is-Dark].switch = on with a delay of 37ms
+54ms ║RunTime Analysis CS > 15ms > PS > 4ms > PE > 36ms > CE
+57ms ║Runtime (38156 bytes) successfully initialized in 4ms (v0.3.110.20191009) (56ms)
+58ms ║╔Execution stage started
+66ms ║║Comparison (enum) on changes_to (string) on = false (0ms)
+68ms ║║Cancelling condition #43’s schedules…
+69ms ║║Condition #43 evaluated false (6ms)
+71ms ║║Cancelling condition #1’s schedules…
+72ms ║║Condition group #1 evaluated false (state changed) (8ms)
+74ms ║╚Execution stage complete. (16ms)
+75ms ╚Event processed successfully (75ms)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

#2

It seems odd. It appears that your switch is already on and the condition “changes to on” fails. Are you using the TEST button to initiate this piston with switch 2 already on?

#3

Hi - Thanks for your response.

The posted log was from setting the switch directly in the SmartThings App. I have logs where the switch is working as expected.

It seems that once it’s set (and the piston unsets it once complete) the switch fails to subsequently operate correctly either via direct interaction (SmartThings) or via voice command (Alexa).

I have another similar switch which doesn’t seem to exhibit the same issue, but this is controlled programmatically in webCoRe.

#4

Three things to consider:

  1. The Switch 2 switch changes to on trigger condition will only evaluate as true if the event being processed comes from Switch 2, the attribute is switch, the value is on AND if last time it was evaluated the value was not on. So the piston is making its own decision on if there has been a change based on the events it has received, the order they are received, and the order they are processed (see (3)).

  2. If you are using the stock ‘Virtual Switch’ handler, you will find that consecutive ‘on’ events can be propagated. So if you keep setting the switch to on without anything turning it off, webCoRE will see ‘on’, ‘on’, ‘on’ without any intermediate ‘off’.

  3. If the piston turns off Switch 2, that will generate an ‘off’ event that fires the piston again. There is then a race between the existing instance of the piston finishing and a new instance starting. If the new piston wins it may be held for ten seconds, plenty of time for an ‘on’ event to come along and jump the queue.

Your logs suggest that an ‘on’ event from Switch 2, the ‘Check Is-Dark’ switch, has been received out of sequence with an ‘off’ event for some reason. Previous log entries would be useful for suggesting what that reason might be

#5

In addition to what @orangebucket said above, I would add a WAIT before asking Switch 2 to turn back off. (specifically, I would add up the total duration of piston “Switch Lights On” and add an extra 5 seconds. This gives the hub time to “settle down” before resetting Switch 2, and starting this piston all over at the top)

IE: Turning a switch off right after it turns on is bound to cause communication issues…

#6

@WCmore - Thanks for your advice. I’ll put a wait in and see if that solves the issue.