Zwave Lock toggle immediately jumps back on lock/unlock #11099
Comments
|
@andrey-git I hate to ping anyone directly, but any idea at all on this? It seems like the Zwave transaction completes so quickly, I’m not sure why there would be a delay in updating the lock state. |
|
Put ozw log of the transaction on hastebin and link to it here. |
|
@andrey-git The hastebin link is here: https://hastebin.com/rurifuroci.sql. After really examining the whole transaction I can see I was wrong about the length of the transaction. The whole thing (from command send to lock to receiving Lock Report) is almost 13 seconds (!). An Alarm Report arrives after about 4 seconds, indicating a lock operation, but then there is a timeout (it seems to happen every time, I'm not sure if that's just a quirk of this lock) which adds about 6 seconds of delay to the transaction. I guess the platform is looking for the Lock Report before changing the toggle, rather than the Alarm Report? The delay in this could just be down to the health of my Zwave network and the location of my lock (away from, but still only one hop from, the controller, though it is less than 10 feet from a powered node). Thanks for any insight! |
|
You have RTT of 3 seconds that a lot. You should add some repeater. |
|
Hi, new here, coming from SmartThings and my lock is the first thing I am automating. I'm getting about a 8 second delay, this happens in the web interface too homebridge interface was just handy. Any idea how to troubleshoot?
|
|
@marthoc any luck with this issue? I just tried removing all of the other devices in my zwave network and readding the lock, it works fine just the delay of the reporting status again is annoying as hell. I do not have this issue with SmartThings hub. |
|
I’m still having the issue. What kind of lock do you have? Same as mine? I notice that in your log you also have a timeout after about 8s to the first request made to the lock by the controller. I think that’s the issue. For some reason that first request always seems to time out for me. It’s a bit frustrating but eventually my toggle in the frontend and in HomeKit does update to the correct status. As an aside - what’s your experience like with SmartThings and the lock? What’s the delay like to lock or unlock it? I assume unsatisfactory or you wouldn’t be moving it to HA. |
|
I have just switched over my schlage lock to home assistant using HUSBZB-1. The range on the stick itself is not that great but I have a light switch right next to it so that probably improves the speed. I don't have much delay if anything. Its a lot faster than smartthings, I think ST's hub simply has better range than most USB sticks. Try adding some devices that act as repeaters. |
|
I suspect it’s a Kwikset specific issue I’m having with my lock, as no matter how close or far my HUSBZB-1 is from the lock, I get Timeout errors, which slows down the transaction by 8-10 seconds. |
|
I have a Danalock V3 and I have some problems aswell. My lock just name itself zwave._ and lock.locked. |
|
@marthoc I'm using a Kwikset 910, yea I wish someone with more z-wave experience would chime in on the timeout, we definitely aren't the only ones experiencing it nor the only lock brand. @tinkerer on discord attempted to help and seemed to think it was reception issue but this device is not fair away and the hub is one of it's neighbors. I even went so far as to deleting all the other devices I added in case they weren't relaying properly. I was looking to switch from SmartThings because homebridge seemed formally supported. The homebridge on ST, although it works just fine, is just maintained by one guy. I also think the response time to thermostats is slightly slower because they go up to the cloud to do some massaging I think of the request. All of that said, I'm back on SmartThings for now, I don't think it's immensely faster I just think it doesn't flip flop between states so it's less annoying. Here's a screenshot of it working remotely, it's anywhere between 5-10 seconds to complete.
|
|
@LeBlaaanc I think it has to do with OpenZwave - the problem I think is partly traceable to the fact that all Kwikset locks seem to have the same ID (0001) so there’s no differentiation in the database between locks with keypads and without, etc. I think there’s something in the config specific to this lock that just isn’t coming through. Obviously it works with SmartThings and Wink so it has to be down to the lock’s implementation in OZW. I’ve emailed Kwikset requesting detailed Zwave information for this specific lock but it’s been a couple of weeks since my request with no response so I guess that’s a dead end. |
|
Would anything in SmartThings help us? |
|
I'm considering raising a issue on the OpenZwave repo (as I'm now pretty sure that the issue is really the timeout and that doesn't have anything to do with Home Assistant but with the actual communications to the lock, which is OZW territory), but unless I get something back from Kwikset I'm not sure how much can be done. I don't know anything about SmartThings, so I'm not sure. I would expect though that implementing support for various vendors' devices is done at a level that isn't exposed to the user, just like Wink (in Wink, you just select Generic Wave Lock from the list and it pulls in the vendor name and device name once paired, but you can't see the database or anything it's pulling from). |
|
@marthoc it's definitely exposed in ST, I'm just not sure what you need to see. I'll post what I can find related: |
|
For further information on this issue: I’ve now tried the Lock with a Vera Edge via the Vera component and locking and unlocking is almost immediate with only a slight toggle jumping issue (which makes sense as it does take several seconds from start to status report). Status update is also very quick after manually locking/unlocking. For another test I also downloaded the trial version of Homeseer and loaded it on a spare RaspberryPi and tried it with the same Zwave USB stick, and there are no communication errors and the lock responds quickly and updates it’s status quickly (though of course there’s no HA integration, but I’m just talking strictly about Zwave communication with the lock). So I don’t think it’s down to the USB I'm using. So I think this is ultimately a problem with how OZW is configuring/handling this lock; when I get time I’ll raise an issue on that repo and link here, would be good if @LeBlaaanc you could chime in there with your logs too once I do. |
|
I can confirm the same issue with a z-wave shield. I'm officially back to ST again, was hoping there was some benefit with home-assistant but there's none I've seen :( |
|
I seem to be having the same issue with an August Gen 3 Smartlock. However, it did work at one point. I'm wondering if a package upgrade broke it recently. It was working fine on January 3rd then broke on the 4th when I did some Ubuntu package upgrades. Going to see if reverting some fixes it UPDATE - I removed the batteries from the lock and reinserted them and it worked like a charm... |
|
I'm seeing a similar problem with the Schlage Connect lock. When unlocking through the UI, the control moves to unlocked (the lock physically unlocks), then moves back to locked after a second, the moves back to unlocked after another second. |
|
@marthoc back again seeing if anything has improved here as I'd like to use HA for some stuff. Everyone here still just "dealing" with this? |
|
OpenZWave/open-zwave#845 maybe related? |
|
My theory was that the default smartcode.xml was giving me problems on my 910 because it doesn’t have any of the features the xml implements (it has no codes, it’s just the basic version with a normal key turn outside and the Zwave unit inside). However, I “solved” my problem by moving to a Vera Edge for all my Zwave devices and passing that to HA. Now it works really well and the toggle updates as it should. One way to test my theory would be to: exclude the lock, shutdown HA, find the ozw device database in your HA install and delete the entries for Kwikset in manufacturer_specific, then delete the zwcfg xml in the HA config dir. Restart HA, and pair the lock. It will pull command class info from the device without any specific info from the Zwave database (which will mean that it will be listed as an unknown device but that’s fine for testing). And then see how it works. If it works better or as it should then we can see about a PR to ozw to update the settings. |
|
@marthoc I did what you mentioned and here's the result... At |
|
I realize I didn't put my thoughts here... I'm not sure whether OZW or HA should be optimistic but it seems it could for the 8 seconds of delay. |
|
I'm also seeing this on 3 Yale YRD110 locks. |
|
@nathanfaber they work fine otherwise on other platforms? My lock is on SmartThings just because of this weirdness. The issue is most likely an issue with OZW. |
|
@marthoc If you could look at the log in the vera to see the Sent and received timing that would be great starting point to tell where the issue is/should be improved. |
|
@spacesuitdiver yes, I currently use them on an ISY-994i and they can be controlled as expected. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 |
|
I'm running V0.80.0 with a Kwikset lock and the state no longer bounces around when toggled. However it doesn't update at all when the lock is manually locked/unlocked. FWIW, I have a custom sensor that reads access control and alarm type which does update for manual changes. |
|
Something to keep in mind, there's like 3 different Kwikset firmwares even across the same product name. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 |
|
Is this still an issue you are experiencing? Can you please try upgrading to the latest version of Home Assistant (0.90) and report back if this is still a problem? Thanks! |
|
@finish06 I think this issue can be closed since we no longer show a toggle in lovelace and just show text, at least for me its no longer an issue |
|
Works for me as well, Kwikset Zwave lock, v0.90. Doesn't bounce and reflects the lock state immediately when operated manually. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (
hass --version): 59.2Python release (
python3 --version): 3.6 (running in Docker)Component/platform: Zwave Lock
Description of problem:
Successfully securely paired a Kwikset Signature Series Deadbolt with Home Connect (model 910 S TRL ZW 15 SMT). It’s detected as a Kwikset Touchpad Electronic Deadbolt, which I understand is down to its entry in the OZW database.
The issue I’m seeing is that on pressing the toggle in the frontend, the switch moves but then immediately jumps back to its previous state. Meanwhile, the physical lock has reacted almost immediately and locks/unlocks as it should. Three to five seconds later, the toggle in the frontend moves to reflect the true state of the physical lock.
Checking the OZW log, the whole transaction from first message to the Lock Report reporting the state of the lock looks like it takes just under 1 second.
Expected:
Toggle to move and stay in it’s new position.
Problem-relevant
configuration.yamlentries and steps to reproduce:Traceback (if applicable):
Additional info:
The text was updated successfully, but these errors were encountered: