Did the handling of cancel events change in the smart lighting app? I have a bunch that either turn on or off X minutes after motion stops. I use them to give a delay for turning off lights after people exit a room. Very recently (within a week, maybe even 1-2 days) I noticed all these routines no longer cancelling the action if the motion ticks back on. For example motion stops and so a 3 minute timer starts. Then motion starts and stays running yet at 3 minutes the light turns off even though motion never stopped before. Something has definitely changed because I am finding lights turning off while I am still in the room quite often now which I definitely would have noticed before. My more complex routines are in webCore and those have been running fine. Its just the ones in the Smart Lighting app. Any suggestions? I tried opening several up and resaving but that seems to have no impact.
EDIT: I have further determined I think this happens when the second motion event stays on. I.e. off, on and stay on. If it turns off, on, off then it seems the timer is reset.
I’ve moved (3) of my simplest motion-lighting automations to SmartThings Lighting recently (everything else is on WebCoRE) too, but haven’t noticed an issue with ST ignoring new motion resets.
Funny. I am moving my automated lighting FROM WebCore back to Smart Lighting for the exact same reasons that you are considering moving to it. So maybe the issue is systemic.
Did you check what the cancellation policy is for the pistons you are having issues with? I have a bunch on webcore and they have been doing fine, although their timeout is longer so less likely motion stays active.
We found the bug. Basically the code that unschedules the turn off command was looking at the wrong bit of state and wasn’t triggering. However, if the motion stops again, it gets rescheduled over the existing schedule. We are working on a fix, and can hopefully get it out to you soon. As a potential work-around you can create a “Simulated Switch” device and add it to the list of lights controlled by the automation. This will force the rule to run in the cloud instead of locally, and since this is a local only bug, things should go back to functioning again. (Gross, I know…)
Also, this is only a problem when you set up the rule to ONLY trigger on motion stop (i.e. “Do X after motion stops for Y minutes”). If your rule is “Do X with motion, and ALSO do Y after motion stops for Z minutes” it will still function as expected.
Well, that’s good news. I will add the virtual switch until a fix is in place. Will this require a firmware update to resolve? Also, was the bug new or did I just happen to never notice it before?
It’s new as of last week. It will not require a firmware change, but the code that generates the “rule” description in the cloud that gets synced to the hub will need to be updated.
I’ll let you know on this thread when the change goes out, but it’s looking like with QA and missing a release it will probably be next week at the earliest.
This should be fixed now. For anyone else who runs into this, unfortunately the update process is still manual. If you encounter this if you open the rule in smart lighting and just click through to save (or just the removal of the virtual device you were using), it should re-generate the rule and sync it. I know it’s unfortunate and we have plans to make it automatic, but we aren’t there yet.
Glad to see this is fixed, thanks. I was getting some heat from the family when lights kept turning off while they were sitting there. I eventually updated them all to use the virtual switch so while removing that switch it should correct the issues.