Dimmer switch events coming very slow

#1

I’m seeing slower and slower speeds on a Webcore piston getting event updates when a dimmer switch (in this example, Zwave 12724 GE) turns on.

For example - it just took 40 seconds to inform a piston that a dimmer switch has fully turned on.

6/14/2021, 6:52:51 PM +466ms
+0ms ╔Received event [Kitchen Lights].level = 100 with a delay of 65ms
6/14/2021, 6:52:11 PM +985ms
+1ms ╔Received event [Kitchen Lights].level = 9 with a delay of 110ms

earlier today took about 13 seconds - which has been about average as of late

6/14/2021, 12:33:08 PM +873ms
+1ms ╔Received event [Kitchen Lights].level = 100 with a delay of 73ms
6/14/2021, 12:32:55 PM +108ms
+1ms ╔Received event [Kitchen Lights].level = 9 with a delay of 70ms

Any idea why a switch that goes from dim to bright in 2 seconds or less should take this long to reflect in Webcore? This has been going on for several months – it never used to be this bad. Previously was always updated within 10 seconds.

Using SmartThings hub
Webcore v0.3.113.20210203
Device Handler: Dimmer Switch (published)

#2

Well, if a human is spinning the dial, then technically turning from 9% to 100% will send (up to) 91 alerts to your SmartHome… and if you have a piston monitoring those levels, then you can expect that piston to get seriously SPAMMED.

Basically, your trigger is firing too quickly back to back, and it takes time for the piston to settle down.

Side Note:

Because of this, it is very rare that I use level as a trigger. I usually only use them as conditions or commands, since that way they won’t re-trigger the piston unnecessarily.

#3

It’s a good point, but I assumed that there was some kind of governor in play that would prevent however many levels the device is reporting to the hub from being sent to Webcore when a dimmer was being turned on. I’ll recode it, and see if that makes a difference.

#4

The “governor in play” is us programmers and the pistons we create. :sunglasses: