Interesting example. I can see how that could be a problem with lux values that could have a range of values that could go above the threshold you set. Would it be different if there is only two states: active and inactive?
I was just testing out my piston with TCP set to never, and it appeared to be working ok but did notice a problem.
Based on my original piston. It is after 4pm and there is no motion and my ac switch is on. The timer starts. A moment later the motion detector detects motion (active state). Because the TCP is set to never, the action continues and the counter still counts down based on what I observed. If the motion remains in an active state during the entire duration of the countdown timer, the switch will turn off once the timer reaches 0! So even though there is motion it will still turn off! But if motion stops and becomes inactive, then the counter actually resets (this confuses me also because the TCP is set to never). This doesn’t seem obvious at first because there will always be inactive times even if you are in the room.
But say we set TCP to default, if motion is inactive countdown timer starts. I don’t believe that the motion detector throws out multiple inactive state if it remains inactive or another level of inactivity to reset the counter. Unlike the changing lux levels, the counter shouldn’t constantly reset causing the switch to never turn off in this situation then. If motion detector does change to active then the countdown timer stops. The counter only restarts if it becomes inactive.