In my initial testing this looks good. I will continue to play with it and set up both my front and back porch locks. I just wanted to confirm with you that I understand the logic so I can set the times correctly. It appears that the main lock delay time is postponed until the motion delay completes and each time the motion goes active the lock delay is also reset and will wait for the motion delay after it goes inactive to begin the lock countdown. Am I understanding the logic correctly?
You have built a very powerful app here. I need to play with some of the options you have also. Thanks!
Yea, I had to do it that way because I don't have a good way to track the scheduled events right now and selectively block actions. There are several ways to go about it but this way was the easiest to code for. For things like this I'm still a fan of using a secondary method to cover cases such as a light switch or fan while out on the patio. Unexpected triggers from bugs or whatever could cause unexpected actions and leave you wondering what is going on. I personally use bptworlds combined presence in combination with my app for some powerful combinations. Combining the motion sensors into a single virtual sensor for example would cause less motion inactive triggers and less chances for it to relock on you. You'd have to rearrange the settings in the app but it works well. I use that same app for unlocking and locking the door when we come and go. I also use it for detecting when me and the wife are both in bed and trigger my app to lock up the house, turn off all the lights, and set the alarm.
@MikeSas I use the built in Zone Motion Controllers app for this. Allows you specify multiple motion sensors and different settings to determine if that “zone” is active or inactive. It creates a child mZone device you can then use in rules and apps. Might be worth pursuing.
Thanks! I understand and the logic is fine for me. I just wanted to confirm I was understanding what was happening so I can set the times correctly. That will work just fine for what I need.
I am in a very urban environment and bit more cautious about keeping doors locked than I would be living in the suburbs. They are covered porches on an old 1911 home where we leave lights on all night whether we are on the porch or not for security. So my wife is used to going out there without turning on any switches and same thing during the day. The way I have the motion sensors positioned, I get very infrequent false activity. So that has not been a problem for us. I like your app as it will simplify a complex set of rules I have been maintaining to accomplish the same thing.
Let me know if you are still interested in looking at that August Home Lock and Door Sense driver that seems to be the cause of that null pointer exception?
Yea, shoot me over the driver in a message. A log of the error using the latest Auto Lock version would be helpful. Also, include a screenshot of the variables from settings icon using the gear icon on the child app.
Code line 473 is referencing the physical unlock notifications. Looking at the driver it doesn't look like it provides this capability. To support this I would expect the driver to contain some sendEvent along with some descriptionText or a sendEvent along with a map of possible variables but this driver has none of that.. I'd just disable the notifications or maybe add the events to the driver. They do have notifications for the door opening and closing though.
@lewis.heidrick First, thanks for the great app. I feel like a complete idiot. I built a whole set of rules around presence, HSM status, Envisalink sensors, and even fire alert to do all the stuff your app does. Took months to get it all right. I've now ripped it all out and switched to your app.
I do have two enhancement requests. Unlike your installation, my smoke and CO detectors are not all one zone... rather 8 different zones. Could you perhaps modify the fire/medical sensor to be multiple choice check boxes? I have built a virtual smoke/co detector and some logic in RM but I would rather just use your fantastic app natively. Second (and this one is really all about me) could you perhaps give folks the option to invert the switch to enable and disable the app (in other words, disable with switch on or off)? I have a virtual switch set up that basically says "disable lock and HSM automation" but ON means disabled. I know, I could easily fix my logic and use the app the way it is, but if this is something simple maybe others would use it also.
Awesome! Now I have to figure out how to test :). Maybe I will just keep a virtual smoke detector in the mix and use that. Last time a real one went off the fire department showed up at 2am in turnout gear on my 2nd floor landing. Thank goodness we had accidentally left the door unlocked. I'd never be able to replace the door - it's 130 years old!
I like the Envisalink board... a couple folks had to contribute to fixing it since the developer moved on but now that it's working it's pretty cool.
BTW I'm using Geofency and iBeacons as my presence sensors. iBeacons are nice because they have adjustable ranges. I have one out on the porch that I combine with a geofencing app. It unlocks the front door as I climb up the steps. Usually. I'm still debugging the Geofency part.
Thanks for looking into the driver for me. I just tested it with all the notifications disabled and still got the same null pointer exception on line 473. Is there something else I need to do there. I checked the the settings and all the NotifyOn variables are false.
Whatever you changed resolved the null pointer on line 473 when the door is unlocked, but now I get the same error on line 430 when the door locks.
Sorry that my device driver is difficult. Maybe a similar patch will work for when it locks also? Thanks for sticking with me on this. I really like how your App works.
app:7172021-07-31 04:36:00.572 pm errorjava.lang.NullPointerException: Cannot invoke method contains() on null object on line 430 (method lock1LockHandler)
app:7172021-07-31 04:36:00.545 pm debugTest Auto Lock: null
app:7172021-07-31 04:36:00.515 pm debugTest Auto Lock: Lock command sent
app:7172021-07-31 04:34:48.403 pm debugTest Auto Lock: Locking door in 60 seconds.
app:7172021-07-31 04:34:48.320 pm debugTest Auto Lock: null
And yes, all 3 were empty and the switch disabled.
Uncheck the enable event, low battery, and failure notifications. Those toggles are what is triggering the null errors. All I did for 473 was set the door unlock notification to do nothing if the event description was null. Here is the update to ignore for 430, but you shouldn't need it if you toggle those three off.
Both these changes and all the others between the last release rolled up so you can update via HPM.
I originally started out with about 50 rules and as I changed things around it got harder and harder to deal with all the rules which is why I started working on this app. Chris already had a good app to build from and this gave me flexibility without all the complexity. As a bonus I learned how to write apps for Hubitat. This got me comfortable enough to help people with drivers. It's been a lot of fun just haven't had a whole lot of time. I try to respond relatively quickly but sometimes life happens. This is a great community and I enjoy helping out. Lately I've been working to upgrade my home network. I relocated everything from an in wall Legrand On-Q cabinet to a wall mounted 12u rack. I'm preparing to add several wifi 6 access points and upgrading several of the drops to 10gb. Wan failover is setup now and working great. I ran som fiber from the ONT over to the new rack so I can couple it over and get rid of the ONT from my bedroom once I get AT&T out here to cut me over to the new BGW320 modem.
By the way, all 3 notification types (event, low battery, and failure) were unchecked for all of my tests. I just enabled them for that last screenshot to reconfirm that I had not left my phone as a notification device. If you look at my screenshot from earlier of the variable settings, you can see all 3 NotifyOn variables are false. So something else must have been triggering the null error. Either way whatever you did resolved it.
Will you be pushing this version to HPM so I can keep up with any other updates?
I'm really tempted to submit some changes to that driver to standardize it some with everything else that's out there. We'll see if I get some free time soon.
