With respect, I think you just need to adjust a tiny bit of your thinking about automations/pistons. You have to consider when they run, and what they do when they run.
Your webCoRE piston will fire whenever the motion sensor changes state in either direction. Each time that happens it will run from the top and see what it needs to do.
It has been told that if the piston was executed because the motion sensor has just changed from ‘inactive’ to ‘active’, it should turn the light on.
It has also been told that if the piston was executed for any other reason, it should ‘wait’ for 10 minutes and then turn the light off. Those reasons would include the motion sensor changing from ‘active’ to ‘inactive’, or the piston being run from the test button, run from its external URL, or being executed by another piston.
webCoRE also has a common sense feature called the ‘Task Cancellation Policy’. To cut a long story short, for your piston this means that if the motion sensor changes to ‘inactive’ and back to ‘active’ again, it figures it won’t be needing to turn the light off after ten minutes any more. Effectively the timer is cancelled.
There isn’t any constant resetting of a timer while motion is ‘active’ because nothing happens until the motion state changes, and because there isn’t a timer running.
Now I don’t know exactly how the automations work. However they still need an event to make them look to see if they need to do anything. So in your case the automation will execute when the motion sensor changes state. It may actually only execute when the motion sensor changes state to ‘active’.
Your automation will execute because it knows something has happened that might require a response. If the motion is ‘active’ it will look to see what you want it to do, and what you want it to do is turn the light on and they turn it off ten minutes later. So that is what it does.
If the motion cycles via ‘inactive’ and back to ‘active’ it appears that the timer gets reset (this might have more to do with SmartThings only allowing one active wake-up timer than the application of common sense, but I’ll be generous and assume the latter too).
I can appreciate the thinking about resetting the timer, but what about the use cases where you wouldn’t want the timer to be reset?
I don’t see anything as broken. Yes I believe that the Automations could be a bit more sophisticated (an ‘else’ statement would be useful), and I think the event driven nature of things could be made clearer. I also think they need to make Smart Lighting more prominent in the system and explain why it is still so useful.
I am also aware that what seems trivial from our end may appear somewhat differently from the Samsung end. Moving from an ‘if … then’ to an ‘if … then … else …’ means an automation has to respond to more events (a simple motion sensor based automation will need to response to both ‘active’ and ‘inactive’ events, for example) and that requires increased infrastructure. Perhaps it makes more sense to have some users writing two automations when one would seem to be easier.
Also, having seen your other thread, it probably ought to be pointed out that by default SmartThings only propagates attribute events if the state has changed. So if your motion sensor does send reports to the hub when motion is continuous (quite possible), and the device handler generates events from those reports regardless of whether there is a state change (it probably will), the device handler also needs to flag them all as being state changes to override the system (some might do that anyway). That increases the load on the system.
