Single event fires twice

#1

**1) Give a description of the problem.
Single switch event fires twice. If the events are close enough together, the second will cause a semaphore.

2) What is the expected behaviour?
For a single switch event to only fire once.

3) What is happening/not happening?
Single switch event fires twice.

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

image
image.png1178×397 19 KB

5) Attach logs after turning logging level to Full
4/2/2022, 10:20:00 AM +569ms
+0ms ╔Received event [East Lamp].switch = on with a delay of 74ms
+10051ms ║RunTime Analysis CS > 15ms > PS > 10024ms > PE > 11ms > CE
+10052ms ║Piston waited at a semaphore for 10020ms
+10054ms ║Runtime (36538 bytes) successfully initialized in 10024ms (v0.3.114.20220203) (10052ms)
+10054ms ║╔Execution stage started
+10061ms ║║Comparison (enum) on changes = false (1ms)
+10062ms ║║Cancelling condition #2’s schedules…
+10063ms ║║Condition #2 evaluated false (4ms)
+10064ms ║║Cancelling condition #1’s schedules…
+10065ms ║║Condition group #1 evaluated false (state changed) (7ms)
+10067ms ║╚Execution stage complete. (12ms)
+10068ms ╚Event processed successfully (10067ms)
4/2/2022, 10:20:00 AM +565ms
+1ms ╔Received event [East Lamp].switch = on with a delay of 70ms
+35ms ║RunTime Analysis CS > 17ms > PS > 6ms > PE > 11ms > CE
+37ms ║Runtime (36435 bytes) successfully initialized in 6ms (v0.3.114.20220203) (35ms)
+38ms ║╔Execution stage started
+45ms ║║Comparison (enum) on changes = true (1ms)
+46ms ║║Cancelling condition #2’s schedules…
+47ms ║║Condition #2 evaluated true (5ms)
+48ms ║║Cancelling condition #1’s schedules…
+49ms ║║Condition group #1 evaluated true (state changed) (7ms)
+52ms ║║Cancelling statement #3’s schedules…
+57ms ║║on
+58ms ║║Executed virtual command log (1ms)
+61ms ║╚Execution stage complete. (24ms)
+62ms ╚Event processed successfully (62ms)

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

#3

That’s not normal behavior, does it do that consistently? Do you have any different brand dimmer device that does the same thing?

#4

As far as I can tell, webCoRE is working as expected. For me the question is, why are there two on events?

The default behaviour of SmartThings is to only propagate state changes, but the developers can override that behaviour in the device integration. So that too could be perfectly correct behaviour if the switch was being turned on twice. So how is it being turned on? Is there perhaps an implicit on through a change of level and an explicit on?

#5

Yes, I have two different brand switches (GE Enbrighten and Minoston) both are doing the same thing. I also see the issue with smart bulbs and outlets (zigbee or zwave). I do not see the problem with contact sensors.

#6

So I have tried turning the switch on programmatically and manually with the same results. I do not understand how all my switches, bulbs and outlets appear to get 2 events for 1 action. All my contact sensors work as expected.

#7

Anyone?? Can someone else load this piston, change the light switch to your own, run it and show your log files?

#8

I don’t have a dimmer switch, but I ran your piston with a regular light switch and it worked as expected. I’m running on HE.

#9

Any log file you could share?

#10

I’m curious if you can try this piston with a virtual device. See if you get the same double trigger.

#11

Good question, I just tried that out and it works fine. Only happens with actual light switches, outlet switches and light bulbs. I also setup a new hub at my work. Created a new ST account and setup Webcore in the IDE. Connected a light bulb and still had the same issue with that new setup. I’m stumped!

#12

A shot in the dark… Can you change the driver of the East Lamp switch and see if that changes things?

#13

Not exactly sure how to do that but I am having the same problem with other brand switches, light bulbs and outlets. So, I don’t believe it’s a driver issue.

#14

Ended up solving the problem by changing the device handlers for all switches, bulbs and outlets. Even though I had different brands of these device, most used a generic device handler which was causing the double fire of a single event.

Thanks for the help!