Try it now I found two places where I capitalized a variable that I shouldn't have in the check locked and check unlocked handler.
(lock1.CurrentValue("lock") should have been (lock1.currentValue("lock")
It's been updated on GitHub but the version is the same so if you run a repair it should fix it. You could also just do a search and replace it in app code.
I have giant hands and coding on a phone is hard lol.
Alright, version 1.1.6 released and it definitely unlocks when the door is open and you lock it. I even have it go into turbo mode for this specific case. And for the opposite, which should never happen, where the lock is locked and the door opens it goes into turbo mode unlock just incase, and does a device refresh on the sensors to make sure that the app is in the correct state. Status updates are working now on the devices in the app. I reworked the handler code so let me know what other cases you find where it doesn't perform as expected. It's 5am I'm goin to bed now.
I haven't done a lot of testing but so far everything seems to be working. I'll do some more testing later today. Thanks again for all of your work on this.
Looking good so far.
Is the "Unlocking Options" Only for when the door is open (via the contact sensor)? If the contact sensor is a bit touchy or its battery goes dead maybe a chance this "Unlocking Option" would inadvertently unlock the door? Feature request: Enable/Disable "Unlocking Options". Thanks.
I had this built into a RM rule. The problem came about when the contact failed and reported the door open. It kept unlocking the door. It would be nice to be able to disable this setting instead of disabling the entire app until you can fix the contact sensor. I've read other posts where people have said they won't put an auto-unlock in their rules/apps because they don't feel comfortable with that feature. Just my two cents. I appreciate everything you've done with this and it is workable as is.
Yes, I agree, as I was confused in the same way, and as everyone knows, I have a brain as large as a planet. (Almost.)
Would also like the option to turn off the unlock feature...I get the reason for it, as I have slammed a door shut w/the deadbolt out and hate that when it happens. But it would be worse if the front door contact sensor died/failed/malfunctioned and the door would not stay locked. I think I'd generally leave the unlock setting off for this reason, and just try to be more careful.
Thanks for the collapsable design, @lewis.heidrick. Nice to be able to keep things out of sight when desired.
It's possible to account for this in the app by only disabling unlock when the contact sensor opens. It's kind of the opposite of the normal logic path since you physically wouldn't be able to open a locked door.
I'll accommodate both, fully disable unlock and only disable unlock when door opens to prevent bolt/frame hits.
Still working on hiding the manual activation minutes when something other than set time is chosen but it's just a gui thing and not a functional issue. Or shouldn't be at least. I need to spend some time on tuning the functions but going to do some reading up on the best ways to deal with humidity. The Bathroom Humidity App was a lot harder than this one. A lot of variables to have to track. There was a name bug that I came across while writing the new version for both but has since disappeared. I think I just had to click done once and it went away for good. I converted the name field to a state variable to hold its value between hub reboots. Something I missed in the earlier version. Was thinking about it when I went to bed and fixed it with my phone lol. I need a life.