Dimmer level caching in Piston?

#1

1) Give a description of the problem
I have a Piston that performs an action based on the level of my dimmer. The Piston is triggered on the Switch event and the first thing it does is capture the level value. Everything generally works fine if I turn the dimmer on and off, but if I turn the dimmer on by giving the dimmer a new value, the dimmer uses the previous off value for the condition.

2) What is the expected behaviour?
If the dimmer is turned on and the end level is below 10%, set level to 10%, else do nothing. I want to read final level, after the dimming has stopped. My dimmer (GE Dimmer Switch model 3038) will fade to the desired level. I want to grab the value the dimmer will end on.

3) What is happening/not happening?
If I set my dimmer to 80%, turn it off, then set the level of the dimmer to 1% in the ST App, the Piston reads the dimmer value as 80%. Even if I put in a 5 second delay, the dimmer value is still read as 80%, where the actual values is 1%

4) Post a Green Snapshot of the pistonimage

piston
piston.png1178×843 97.6 KB

5) Attach logs after turning logging level to Full
11/15/2020, 9:07:53 PM +71ms
+103ms ║80 is the current level after the wait
+125ms ║Basement Stairs Not resetting. Current level is 80
11/15/2020, 9:07:49 PM +224ms
+112ms ║80 is the current level before the wait.

#2

This piston only executes when the Switch changes… It is not monitoring the levels.
(as seen by the lightning bolts in the left margin)

So what is likely happening is a data race…
When you manually change the dim level, it immediately kicks on the switch.
(but the new level might not yet be seen by the hub, or reported to webCoRE)

#3

I figured there was a race condition occurring. Is there a better way to get the status? I don’t mind if there is a couple second delay. This should only perform action when the light is dimmed too low and turned off. I would rather have true negatives (light stays at 1%) than false positives (light goes full brightness then dims to 10%)

#4

For starters, I would be tempted to turn line 33 into a condition:

IF {curDevice}'s switch IS on

Although technically it should always be true each time it evaluates, so you could actually delete that line entirely for the same results. (and just leave IF {curDevice}'s level is less than 10%)