When I updated to the first version of 1.1.6 and when I updated to the latest hot-patch, I've lost control of my lock. It will show as locked, but won't reflect any changes in the device page. I tired both removing the battery, rediscovering it and neither worked. I finally had to remove it and reinstall it.
Has anyone else had that issue?
Nope...works fine for me...but I updated from 1.1.5 straight to the latest version with the hot patch already included.
All seems well with mine currently also.
Not specifically with 1.1.6, but otherwise, yes. The 910z has been a pain in my arse with HE.
I've noticed the driver get's out of whack with the actual state then it stops responding all together. Sometimes, if I get the lock into the state the driver thinks it is, and then actuate it from the driver, it'll start working again.
I've noticed my SharpTools.io and Homebridge at least showing my Kwikset 910 is unlocked when it's locked.
This has been happening for a while for me, and happened last night but resolved itself somehow.
In fairness to Hubitat I haven't checked the actual device page during a lot of these incidents because I've forgotten by the time I get home it's back to normal.
It’s working fine for me. I have a rule that refreshes the locked condition every 5 minutes and unlocked every 4 minutes. These times were arrived at by the “pick a number.....any number” method. It even updates immediately on my control panel now.
Well, of course it started working now. Maybe it just had to sit for several hours to sync up. It has been strange and I will report if it occurs again!
Update! - It's not working completely. There seems to be an issue with the refresh. It's not picking up when I manually unlock it, and thus won't run some of the rules as HE "thinks" it's locked. I added it to my 1 minute refresh rule (I use it for my CT-100 Thermostat) for now. I'll keep an eye on it and test more tomorrow, but my thinking is that maybe something with the refresh changed from 1.1.5. Probably not, but I can't explain the symptoms any other way right now.
Seeing a similar type behavior but not sure when it started. I was thinking I had same issue now for a rev or two but maybe it is new with 1.1.6. I've also noticed adding a new code took over 30 mins to take the other night.
It's not an issue with 1.1.6, I have two of these in production and another in dev.
How do you set a rule to refresh the condition? If I create a new rule and choose option to "Refresh" I can only choose the Lock itself, not a condition. Are you doing this via custom command? Thanks in advance!
Starting to think my issue is related to how flaky the Zwave signal can be on these devices. Going to add a new ZWave repeating device super close to the lock and see if that helps. Its weird I have to put the hub within just a few feet of the lock to get the secure pair to complete and then the lock works for days or months and then randomly starts having issues. I can sometimes hit Get Codes and I see an entry in the logs for "Starting Code Fetch, try to fetch code". Right now mine always tries to fetch code 19. Any other commands like lock, unlock, or refresh don't show anything in the logs at all. Would that be an expected behavior if its not getting a good signal? Thanks!
It should look like the below, and shouldn't take any longer than that on a 910, the schlage is much slower.
So it sounds like you have a distance/mesh/interference issue of some sort.
dev:16772018-10-25 11:01:09.035 am infolast code 30 fetched, fetch complete
dev:16772018-10-25 11:01:08.561 am tracetrying to fetch code:30
dev:16772018-10-25 11:01:08.560 am infocode:29 fetched
dev:16772018-10-25 11:01:08.042 am tracetrying to fetch code:29
dev:16772018-10-25 11:01:08.040 am infocode:28 fetched
dev:16772018-10-25 11:01:07.511 am tracetrying to fetch code:28
dev:16772018-10-25 11:01:07.510 am infocode:27 fetched
dev:16772018-10-25 11:01:06.990 am tracetrying to fetch code:27
dev:16772018-10-25 11:01:06.989 am infocode:26 fetched
dev:16772018-10-25 11:01:06.473 am tracetrying to fetch code:26
dev:16772018-10-25 11:01:06.471 am infocode:25 fetched
dev:16772018-10-25 11:01:05.960 am tracetrying to fetch code:25
dev:16772018-10-25 11:01:05.959 am infocode:24 fetched
dev:16772018-10-25 11:01:05.475 am tracetrying to fetch code:24
dev:16772018-10-25 11:01:05.474 am infocode:23 fetched
dev:16772018-10-25 11:01:04.800 am tracetrying to fetch code:23
dev:16772018-10-25 11:01:04.799 am infocode:22 fetched
dev:16772018-10-25 11:01:04.270 am tracetrying to fetch code:22
dev:16772018-10-25 11:01:04.269 am infocode:21 fetched
dev:16772018-10-25 11:01:03.744 am tracetrying to fetch code:21
dev:16772018-10-25 11:01:03.742 am infocode:20 fetched
dev:16772018-10-25 11:01:03.221 am tracetrying to fetch code:20
dev:16772018-10-25 11:01:03.220 am infocode:19 fetched
dev:16772018-10-25 11:01:02.701 am tracetrying to fetch code:19
dev:16772018-10-25 11:01:02.699 am infocode:18 fetched
dev:16772018-10-25 11:01:02.181 am tracetrying to fetch code:18
dev:16772018-10-25 11:01:02.180 am infocode:17 fetched
dev:16772018-10-25 11:01:01.665 am tracetrying to fetch code:17
dev:16772018-10-25 11:01:01.664 am infocode:16 fetched
dev:16772018-10-25 11:01:01.146 am tracetrying to fetch code:16
dev:16772018-10-25 11:01:01.145 am infocode:15 fetched
dev:16772018-10-25 11:01:00.653 am tracetrying to fetch code:15
dev:16772018-10-25 11:01:00.651 am infocode:14 fetched
dev:16772018-10-25 11:00:59.988 am tracetrying to fetch code:14
dev:16772018-10-25 11:00:59.987 am infocode:13 fetched
dev:16772018-10-25 11:00:59.461 am tracetrying to fetch code:13
dev:16772018-10-25 11:00:59.459 am infocode:12 fetched
dev:16772018-10-25 11:00:58.985 am tracetrying to fetch code:12
dev:16772018-10-25 11:00:58.983 am infocode:11 fetched
dev:16772018-10-25 11:00:58.356 am tracetrying to fetch code:11
dev:16772018-10-25 11:00:58.354 am infocode:10 fetched
dev:16772018-10-25 11:00:57.674 am tracetrying to fetch code:10
dev:16772018-10-25 11:00:57.672 am infocode:9 fetched
dev:16772018-10-25 11:00:56.585 am tracetrying to fetch code:9
dev:16772018-10-25 11:00:56.583 am infocode:8 fetched
dev:16772018-10-25 11:00:56.063 am tracetrying to fetch code:8
dev:16772018-10-25 11:00:56.061 am infocode:7 fetched
dev:16772018-10-25 11:00:55.540 am tracetrying to fetch code:7
dev:16772018-10-25 11:00:55.539 am infocode:6 fetched
dev:16772018-10-25 11:00:55.024 am tracetrying to fetch code:6
dev:16772018-10-25 11:00:55.023 am infocode:5 fetched
dev:16772018-10-25 11:00:54.500 am tracetrying to fetch code:5
dev:16772018-10-25 11:00:54.498 am infocode:4 fetched
dev:16772018-10-25 11:00:53.982 am tracetrying to fetch code:4
dev:16772018-10-25 11:00:53.980 am infocode:3 fetched
dev:16772018-10-25 11:00:53.472 am tracetrying to fetch code:3
dev:16772018-10-25 11:00:53.470 am infocode:2 fetched
dev:16772018-10-25 11:00:52.979 am tracetrying to fetch code:2
dev:16772018-10-25 11:00:52.968 am infocode:1 fetched
dev:16772018-10-25 11:00:51.052 am infostarting code fetch, trying to fetch code:1
Thanks.. mine just hangs on "trying to fetch code: 19"... I will get my additional ZWave repeating device in place and see if things improve and report back.
Unbelievable......my lock just started working normal again and I only changed one thing in my environment. An Amazon box..a literal shipping box was sitting between the lock and ZWave repeater (about 4 feet between lock and repeater). This is definitely looking like a signal thing for me but crazy how sensitive this lock seems to be.
My wife for whatever reason decided the best place for a Mylar balloon was directly in front of our production hub, took the whole house down...
So, the refresh wasn't working and I had to remove and add the Kwikset Lock again. It stopped working after I applied the last hot fix. To be fair, the last hot fix didn't have any lock or z-wave updates. This happened when I updated from to 1.1.116 so it's either something within the code base or it's something with my Z-wave configuration.
Currently the lock is about 8 feet away from my hub (which is in the coat closet as that is the center of my house) with one wall in-between. My hub is plugged into an Iris power plug (needed to for the 5 Zigbee devices I use). There may be something related to the Z-Wave of the plug that I have tripped over when the hub reboots after a new code is installed. Trying to figure out how to troubleshoot that.
Prior I did have issues with my Kwikset, but I also think I was one of the first people to find out that the lock started performing poorly when the batteries dropped below approx. 50%. So, I'm not with issues with this lock. Prior to 1.1.116 and replacing the batteries (separate occurrences), everything has been running well. Now that I have removed/added it again, I will keep track and post on this thread the progress.
Just as a data point, I had an Iris plug in the same closet as my hub in the early goings. I was having difficulties with (strangely enough) my Kwikset 910, my zwave garage door opener and an Inovelli outoor plug. My Hampton fan would also be a bit flaky from time to time. I decided that the repeater being so close to the hub might be causing strange behavior and removed it. It might have been coincidence, because we had a few hub updates in that time as well...but all 3 devices have been rock solid since.
Ok so I confirmed today that my 910 is not reporting status immediately either. I didn't note how long it takes but it does eventually show. A refresh will get it to update as well.
KwikSet 888 has same issues as you all do. Not refreshing after the 1.1.6 update. Ugh locks are not autolocking and automations are failing.
So I setup the following rule below. Anything I should be concerned about?
I need some help in understanding this.
There were no changes to this driver in 1.1.6, nor where there any changes in the platform that should now require the lock to be polled for it's current state.
Just to make sure that I'm not losing my mind, I just went to both my Kwikset 910's in production, locked unlocked physically, driver state updated correctly within a second, I then issued a lock and an unlock command from the driver, the lock locked and unlocked and and driver state updated correctly...
the lock command and device response was maybe two seconds on the lock command, the unlock command and its event were about 5 seconds.
So I'm not dismissing the issue, but at this point I can't point the problem to the driver or the platform.
Download the Hubitat app
