Simulated Switch isn't turned off sometimes

#1

1) Give a description of the problem
The simulated switch isn’t turned off sometimes.

2) What is the expected behaviour?
The piston is executed when the trigger is turned on and shall turn it off after 1 sec. again. (the switch is used in IFTTT to execute a comman there).

3) What is happening/not happening?
Sometimes it isn’t turned off.

**4) Post a Green Snapshot
image

5) Attach logs after turning logging level to Full
20.2.2020, 10:24:50 +556ms
+1ms ╔Received event [Rollläden ST öffnen].switch = on with a delay of 152ms
+138ms ║RunTime Analysis CS > 19ms > PS > 102ms > PE > 16ms > CE
+140ms ║Runtime (38300 bytes) successfully initialized in 102ms (v0.3.110.20191009) (138ms)
+141ms ║╔Execution stage started
+149ms ║║Comparison (enum) on changes_to (string) on = false (0ms)
+151ms ║║Cancelling condition #2’s schedules…
+152ms ║║Condition #2 evaluated false (7ms)
+153ms ║║Cancelling condition #1’s schedules…
+154ms ║║Condition group #1 evaluated false (state changed) (8ms)
+156ms ║╚Execution stage complete. (15ms)
+157ms ╚Event processed successfully (157ms)
20.2.2020, 10:24:42 +968ms
+1ms ╔Received event [Rollläden ST öffnen].switch = off with a delay of 93ms
+123ms ║RunTime Analysis CS > 26ms > PS > 83ms > PE > 14ms > CE
+125ms ║Runtime (38304 bytes) successfully initialized in 83ms (v0.3.110.20191009) (124ms)
+126ms ║╔Execution stage started
+133ms ║║Comparison (enum) off changes_to (string) on = false (0ms)
+134ms ║║Condition #2 evaluated false (4ms)
+135ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+137ms ║╚Execution stage complete. (12ms)
+138ms ╚Event processed successfully (138ms)
20.2.2020, 10:24:41 +686ms
+1ms ╔Received event [Rollläden ST öffnen].switch = on with a delay of 151ms
+140ms ║RunTime Analysis CS > 20ms > PS > 106ms > PE > 15ms > CE
+143ms ║Runtime (38306 bytes) successfully initialized in 106ms (v0.3.110.20191009) (141ms)
+144ms ║╔Execution stage started
+151ms ║║Comparison (enum) on changes_to (string) on = true (0ms)
+152ms ║║Cancelling condition #2’s schedules…
+153ms ║║Condition #2 evaluated true (5ms)
+154ms ║║Cancelling condition #1’s schedules…
+155ms ║║Condition group #1 evaluated true (state changed) (8ms)
+157ms ║║Cancelling statement #3’s schedules…
+160ms ║║Executed virtual command wait (1ms)
+161ms ║║Waiting for 1000ms
+1164ms ║║Cancelling statement #5’s schedules…
+1204ms ║║Executed physical command [Rollläden ST öffnen].off() (37ms)
+1205ms ║║Executed [Rollläden ST öffnen].off (39ms)
+1207ms ║╚Execution stage complete. (1064ms)
+1208ms ╚Event processed successfully (1208ms)

#2

I suspect your piston is suffering from internet latency. Your wait of 1 second may/may not be enough time for the switch to react or be changed. If possible, I would extend your WAIT and see how that works.

#3

I have read that it’s not a good idea to use a device to trigger an event on the same device.

Try moving the turn off outside of the IF. It should only execute if the switch changes to on. It will wait 1 second and then turn off the switch. Same difference.

#4

The piston would still be fired when the switch is turned off. The only difference would be that the piston will execute the turn off action every time (though probably skipping the actual command).

The ‘positive feedback’ of a piston doing something that triggers itself is really only a problem if you haven’t allowed for it happening.

#5

That’s an interesting one. The piston is getting an ‘on’ event, with an ‘off’ event right up its chuff, caused by turning off the switch. There is another ‘on’ about six seconds later and that one isn’t being recognised as a ‘changes to on’.

The ‘changes’ comparison works by comparing the value in the event to a cached value. So it sees reasonable to consider that for some reason the cached value is wrong.

I don’t understand the piston SmartApp code well enough to know how this cache is handled, and particularly updated, so I can only wildly speculate that the use of a simulated switch might mean the ‘off’ event is coming in so quickly that there is an overlap between the ‘on’ instance putting itself to bed and the ‘off’ instance waking itself up, and somewhere along the line the cached value of the switch gets caught in a race condition with varying results. As I say though, pure speculation.

My suggestion would be to switch to using an ‘is on’ condition rather than the trigger, as that will just look up the attribute value. The piston will fire at exactly the same times.

The only other thing I notice is that the TCP is set to Never on the ‘if’. I don’t think that is a factor here, but I am just curious if anyone has ever worked out exactly what effect that has and why you would want to use it. It certainly doesn’t seem to behave like setting it on the ‘with’ or ‘do wait’ of a task.

#6

This version seems to do the same thing.

Tried many times and it switched it off every time.

Really no different than OPs, and I guess really wouldn’t know if it works consistently without continued use.

1secsw
1secsw.png1178×554 46.9 KB

#7

If the failure mechanism is what I speculated it might be, the one less ‘end if’ between the ‘Turn off’ and the ‘end execute’ might make all the difference. Or it may just seem to make the difference 99% of the time. Difficult to tell.

I’d still recommend the OP tries a condition instead of a trigger though.

#8

To embellish a bit to what @orangebucket said:

If your Simulated Switch is really a Virtual Switch, this is a common event.
(it does not update instantly)

On the other hand, if it is in fact a Simulated Switch, (my preference) then a slightly longer WAIT would be my solution. If you have other pistons running at that same moment (chaotic), then you can add an extra “off” to the bottom:

WAIT 3 seconds
with
    Switch 134
do
    Turn off
    WAIT 2 seconds  <-- New
    Turn off        <-- New
end with

The extra off is just to make sure that that command gets thru the network chatter.

#9

Sorry for my late response and thank you for your help!
The easiest solution way was to try to set the turn off command after the if statement and it worked! Thank you!

Regards,
Jogi