I was getting a ton of those messages in the Activity Feed and Live Logging, too (I have Yale locks). It’s coming from the Lock Manager app, line 170, doing checks for unmanaged codes and polling:
// runIn(20, doPoll)
So, I commented it out, awaiting @ethayer’s input, … doesn’t seem to impact the overall operation of Lock Manager; everything seems to be working from what I can tell, and the logs are no longer clogged with all those messages — I’m sure my locks’ batteries are happy too.
It looks like your locks/DTH report ‘null’ instead of empty string, so the app is thinking ‘null’ is incorrect and it should be empty string.
Both “Null” and empty string should be falsy, so I just changed the check. removing that line may compromise the reliability of future set code / delete code actions.
I’ve also noticed the same problem on Android. When selecting the slot for a new user, the first time I do so, the number is not saved. The second time I select the slot number, it works correctly.
First off, great job on the app! Really appreciate your efforts!
I have been using the old User Lock Manager with no issues, and decided to give the new Lock Manager app a try. I’ve deleted User Lock Manager and the User Lock Manager DTH, and created a new app using the Lock Manager repos for both the app and DTH, and have been sure to select the correct DTH for the device.
When I add the Lock Manager app in the Smart Things Android app I am able to see and select my lock, but am getting the following error when trying to create a user.
I am using a Kwikset 916 in Z-Wave mode and the Android SmartThings app on Android 7.1.1
Anyone else having the same issue with the Kwikset 916 and Android SmartThings app? Any suggestions of things to try?
Appreciate any input, and thanks again!
ETA: I also just tried using the SmartThings iPhone app, which is also unable to create a new user. Seems the issue may be with the Kiwkset 916, or I’m configuring something incorrectly.
From the IDE logs:
d1143289-2dc8-4844-9acc-c290808fffe1 6:29:00 PM: debug checking children for errors
9e282ec8-2b2d-420e-a086-6bc9a8a6cf31 6:29:00 PM: debug poll is sending [‘9881006202’]
d1143289-2dc8-4844-9acc-c290808fffe1 6:28:00 PM: debug there are 0 lock users
d1143289-2dc8-4844-9acc-c290808fffe1 6:28:00 PM: debug
d1143289-2dc8-4844-9acc-c290808fffe1 6:28:00 PM: debug Updated with settings: [overwriteMode:true, locks:[Front Door Lock]]
d1143289-2dc8-4844-9acc-c290808fffe1 6:27:48 PM: debug checking children for errors
Sorry Erik, I’m late to the party on new app. Was trying to help somebody set up their lock and found this thread/app instead of original.
Am I reading this correctly that with new parent/child I can see, program, control multiple locks in single app ? I’m assuming a parent app and then a separate child for each lock ?
No need to have locks be a child app for now, could end up like that in the future, but since there’s a high storage limit on apps (100k characters) I don’t see a need for locks to be separate.
The user is a child app, so that each individual child can make sure it’s set correctly and also have it’s own schedule methods. (each individual lock user can now have it’s own schedule)
Okay, maybe I’ll play with it later. Now I have 4 installs of old app, one for each lock , oops make that 5, I forgot about the Centralite keypad we never use uses it.
Probably because I haven’t looked at it since I was working with you to make it work with Schlages back in 2015. LOL. You got it working and I haven’t messed with it since. Add and disable codes as needed, sends me push/SMS whenever somebody opens the door. Why mess with success
Only thing I would add is ability to send who opened the door to Big Talker instead of just announcing it was unlocked.
I do like that idea, but would add - how about inclusive ALL notify programs If Erik is inclined(?) I use Notify with Sonos - and think that would be pretty a cool feature - I do get audio notify “the front door in unlocked/locked” now adding the “user” that opened it or “unknown user” would be neat.
… doesn’t seem to impact the overall operation of Lock Manager; everything seems to be working from what I can tell, and the logs are no longer clogged with all those messages — I’m sure my locks’ batteries are happy too.
