I’ve had an autolock rule that looks to see if my door lock stays unlocked for 1 min. If it does and the door is closed (different sensor) it locks. If the door is open, it texts me.
This has worked for a while, but a few weeks ago it just stopped.
I created other actions and verified that sharptools can still lock the door, and that it sees the state of the sensor. It seems that the ability to see that the lock state stays unlocked is what is failing. I’ve also verified in ST logs that the state of the lock indeed changes, as it should, from locked to unlocked and back again when it should.
Has anyone else noticed anything like this? Anything else I should check for?
Hi @William_Hirsch, can you take a screenshot of the rule so I can better understand how the trigger and if_condition is configured. And was there any change made recently that you think it might cause it?
The issue started a few weeks ago and I can’t think of anything changed when it started becoming an issue.
While I did change the DTH recently (from one native to the Kwikset 888 to rboy’s Universal Z-Wave Lock With Alarms) this was AFTER the problem started. The device didn’t change (just the DTH), and the hub has since been restarted. Again, separate actions to control the lock still work from ShartTools.
Below is the screenshot of the rule, and in my next post (it’s only allowing me one embed per post) another showing the state is being returned. I do see in that shot that lock is listed twice…which is odd, but both value remain matched to each other and appropriate for the state of the device.
Thanks for the screenshot and additional details. The rule does look pretty straightforward. Here are a couple thoughts for troubleshooting:
Can you go to the device’s Event List (history) in the SmartThings IDE and verify the lock status during your tests to verify if its status does remain the same during the expect 1 min period? And post the event screenshot if you want me to help take a look. I am wondering if the two “lock” attributes reported in device page has any impact in this case though you mentioned the issue occurs before the DTH is changed.
Create a new rule using the same stay unlocked for 1 min as the trigger, and send you a notification directly without any other condition. Verify if this rule gets triggered as expected during your test.
I unlocked my door and waited a few to show the most recent event sticking. Looking back further however you see that there are plenty of times that unlocked remains the value for more than one minute.
That was actually one of the things I did before my initial post, just to verify that it was the trigger itself failing and nothing else. Unfortunate, the text wasn’t sent. I also did this when another device was triggered to be sure.