August Lock broken communication

Are you saying all these troubles with August Locks is related to the ZWave is
a secondary Gateway for the Lock Control?
If this is a case then ZWave addition is not implemented right.

If I design something similar, I would keep only ONE protocol
for the main communication with a lock. Since many if not all locks are
using phone app for the primary setup and control, the BT seems to
be a right choice. All other protocols should be added through the Gateway.
Many locks already have/required external Gateway for the BT-WiFi bridging.
So why not add ZWave, Zigbee (and whatever else) radios to the gateway
instead of messing up with locks?
To my EE eyes this should be much better and cleaner implementation.
Plus if you want to add or change whatever communication protocol
only Gateway will require some updates or even a replacement.

(Again, just my opinion).

@bcopeland I have one more question before I completely
stop messing up with HE-August Lock pairing.
With the latest 2.2.9.137 HE SW I am unable to pair August Lock
back to HE. Every attempt ended up with creating not easy to
remove ghost device.
(BTW, pairing with 2.2.8.156 HE SW was done instantly on a first try).
My question is:
Is it possible to pair lock with the Z Stick and PC Controller
with S2 security enabled?
I red somewhere this is impossible because credentials could
not be passed from the Z-Stick to the HE (kind of make sense).
I know, pairing can be done without any security at all but for the
lock I would like pairing with S2 security in place.
But if "yes", I have Aeon Tec Gen5 Plus and Zooz ZST10 700 Z-Sticks.
Which one to use?

Lock status said : "Your lock is not connected to a Z-Wave hub".
And there is a button: "ADD TO Z-WAVE NETWORK".
When I am trying to pair it with a hub it asks for the S2 5 digits
security code. While I am typing this code (as fast as I can)
lock most likely timeouts and reported an error.
Clicking on OK button in the lock app somewhat resumes pairing
but with 2.2.9.134 it resulted into creating ghost device.
Exactly the same pairing behaviour I observed with 2.2.8.156
(timeout, etc.) but pairing after all was successful on a first try.
I did think to factory reset lock. But since this is not easy task
and taking in account very different behaviour between
2.2.8.156 and 2.2.9.137 HE versions I am not 100% convinced
this will produce different results.
I have few Z-Sticks around and PC Controller ready.
Is it possible to use Z-Stick for pairing and to avoid factory
resetting lock?
I know, this could be done without any security but most
likely will be impossible to pair with S2 security in place.

And how about problem with a speakers?

I type the DSK into a document, then copy it before starting the inclusion, and, when the DSK is requested, paste it in.

1 Like

Nice trick but it did not work with August Pro Lock.
Lock timeout (if this is a timeout) is near instant.

Rolling back C-7 to 2.2.8156 fixed an lock inclusion problem.
I was able to include lock with S2 security on a first try even lock
reported a problem during inclusion process.
So, lock is included but it does not respond to the "Unlock" and "Lock"
commands from the HE Device page. However lock is ALWAYS responds
correctly to the "Refresh" command.
And HE Log always shows lock activity if lock is touched manually
or by August app.
Since "Refresh" command always works it points to the stable ZWave
communication with a lock and the ability to wake up lock from sleep.
Failing "Lock" and "Unlock" commands is an indicator for problem with
a lock driver.

1 Like

I finally had a free day to experiment a few hours with this, and I got it to work! I'm not sure what exactly did the trick, but it works now, and here are the steps I followed:

  1. Hubitat: Make sure you have a Hubitat backup available (you will need to restore from a backup in a step down below)
  2. Hubitat: Update to latest Hubitat Platform/firmware version
  3. Remove a battery from the August Lock (to turn it off)
  4. Hubitat: Go to Settings -> Z-Wave Details
  5. Hubitat: Press Refresh on the Z-Wave Device that coincides with the lock
  6. Hubitat: Keep pressing Refresh (on the Z-Wave Device that coincides with the lock) until the Remove option appears
  7. Hubitat: Press Remove once it appears
  8. Add the battery back into the August Lock to turn it back on (make sure to put the lock cover back on for DoorSense to work properly)
  9. August Home App: Go to Settings -> Lock Settings -> Z-Wave Settings
  10. August Home App: Remove Z-Wave Device (put Hubitat into Z-Wave Exclusion Mode if it asks)
  11. August Home App: Get the first five digits of the Z-Wave DSK from the August Home App in Settings -> Lock Settings -> Device Information
  12. Hubitat: Devices -> Add Device -> Z-Wave -> Start Z-Wave Inclusion
  13. August Home App: Settings -> Lock Settings -> Z-Wave Settings -> Add to a Z-Wave Network
  14. Repeat Steps 10-13 until a new August Pro Z-Wave Lock is added to Hubitat with S2 Access Control security (pop-ups will appear in Hubitat letting you know about the S2 Access Control, and it will also ask you to verify the first five digits of the Z-Wave DSK. Repeat steps 10-13 until these pop-ups appear. Ignore the errors in the August app as long as the Z-Wave device gets successfully added in Hubitat and shows that it was added in the August Home app.)
  15. Hubitat: Go to the new August Pro Z-Wave Lock device that was just added
  16. Hubitat: Lock and Unlock the door using Hubitat until the "lock" state appears in the "Current States" section of the new August Pro Z-Wave Lock device
  17. Hubitat: Make sure the "lock" state changes at least some of the times you press Lock and/or Unlock
  18. Hubitat: Repair Z-Wave mesh now that the lock is back in business (Settings -> Z-Wave Details -> Repair Z-Wave)
  19. Hubitat: Restore your Hubitat backup (Settings -> Backup and Restore) and wait for the reboot to finish after the restoration
  20. Hubitat: Make sure the Hubitat Platform/firmware version is still on the latest version
  21. Hubitat: Go to the new August Pro Z-Wave Lock device, make note of the "Device Network Id"
  22. Hubitat: Change the "Device Network Id" of the new August Pro Z-Wave Lock device to something random (make sure to hit save)
  23. Hubitat: Go to your original August Pro Z-Wave lock device
  24. Hubitat: In your original August Pro Z-Wave lock device, change the "Device Network Id" to the one you just wrote down (make sure to hit save)
  25. Hubitat: Reboot Hubitat
  26. Hubitat: Test your original August Pro Z-Wave lock device and verify that the "Current States" update appropriately
  27. Hubitat: Remove the new August Pro Z-Wave Lock device from the Devices list at your leisure

Hope this works for somebody else!

Wow!
Thank you very much for posting your algorithm.
It looks like too many steps but I will try this at some point.

After many failed attempts I finally paired lock to HE with S2 security.
Than it took long time before I noticed some improvements in
communication with HE.
As of today my August Lock somewhat fixed itself.
Occasionally it still missing/ignores commands from HE
but surprisingly it works most of the time.

Sounds like you may have a weak mesh issue. Check the LWR RSSI value for the lock to see if it is negative, or if there are a lot of route changes.

After a few days of use, it has missed/ignored a few commands for me, as well, but it's otherwise pretty reliable. So I'd say I have the exact same verdict as you. . . "Occasionally it still misses/ignores commands from HE but surprisingly it works most of the time."

As for the question from @672southmain, my LWR RSSI is 30dB (the lock is only a few feet away from my Hubitat). The route changes, though can get pretty high (it was at 2 a few hours ago, but it's currently at 18). I do have a rule machine rule set-up on this lock that sends it a refresh command every 2 seconds if it doesn't respond to a lock/unlock command quickly enough (my workaround to make this lock 99% reliable on previous Hubitat firmware versions), so I'll try turning off that rule now that I'm on the new firmware and see if it decreases the amount of route changes.

As a note, I only have one other Z-Wave device, it's about 30 feet away from the hub (LWR RSSI of 0dB and 1 route change), and it works flawlessly. It is a device that plugs into a wall outlet, though, so that might help the cause.

1 Like

@bcopeland My HE is C5 and having hard time to have the lock status updated in Habitat. Log indicates that the lock was sending the right message back after pressing refresh, yet the status doesn't get updated, basically display unlocked while actually locked. See below thread for logs.
https://community.hubitat.com/t/refresh-failed-to-sync-august-lock-status-driver-bug

2 Likes

The problem was very annoying, so I decided to port a SmartThings driver, and it works well so far with only one problem: if the lock/unlock command was sent via Z-Wave, the lock does the job but doesn't seem to send the new status back. The workaround is to send a poll or refresh to get the status updated correctly. If someone else is experiencing the same problem and want to give it a try, the driver is here. (Disclaimer: try at your own risk)

3 Likes

Can’t seem to find the specs on this lock, is it a Zwave or a Zwave+? If not Zwave+ you will need to add a poll or refresh to keep the status updated as the device won’t generate it on it’s own (could add this to your driver if needed).

Thanks for this, @Kenneth! Been dying to have access to the Hubitat driver code for the August Lock, since it's so close to working really well. Just missing a bit of that final polish. Now we all might just have something to tinker with and make our own. I'll give this driver a shot on my next day off and let you know how it goes!

1 Like

is it a Zwave or a Zwave+?

I don't know. But if the lock is operated from other means, i.e. physical, Bluetooth, or WiFi, it sends ZWave update, although I started to notice that it may miss such update sometimes. But a force poll or refresh will keep the status in sync.

you will need to add a poll or refresh to keep the status updated

There is already a poll after the lock/unlock action with a 4200ms delay. And in some rare occasions, I do get the status update back. Maybe 4200ms is not enough, I'll try to increase it and see if it makes any difference.

Edit: Changing it from 4200ms to 6000ms made the difference. I got all status update back in 10 lock/unlock tests.

The driver schedules poll every hour. Another workaround is to add a logic to poll every few seconds until I got a response or timeout.

1 Like

Good news.

@Jayhead13 not sure if you have tried it. It's been working flawlessly for me for the past two days.

@Kenneth Thanks again for posting this! Finally have a day off to test this out. Unfortunately, with my initial testing, I can't get this driver to work. Locking/unlocking from Hubitat doesn't work, the lock/unlock status is inconsistently reflected, and the DoorSense status doesn't change when the door is opened or closed. I've tried the usual troubleshooting steps (restarting the lock, restarting the hub, excluding the lock, re-including it), and haven't had any luck. I'm on the C7 hub, so maybe there's enough of a difference between the C5 and C7 hubs to cause this driver to work on the C5 but fail on the C7?

Sorry to respond late, Jay, and thanks for trying. A lot of work-related stuff and Lunar New Year. I'm sorry to hear that it didn't work for you. I'm curious if you got a chance to capture the logs that you can share for analysis. Here are a few things:

  1. DoorSense doesn't work for me either. I have a separate door contact sensor, so I didn't pay attention to it. But I think it can be fixed in the driver as I can see the status update from the device.
  2. I doubt it is C5 vs. C7, although I know anything is possible. I'm wondering if we are on different lock firmware versions. Mine is 1.59.0-2.0.4. but I'm not sure if this is the latest version. I didn't bother to update because it worked fine for me, and August's firmware update is a nightmare (I digress).

@Jayhead13 I think I know the problem. The driver doesn't handle S2 security. C7 uses S2 and C5 uses S0. Someone (me if I got time) needs add S2 security handling to the driver.

First of all, thanks @Kenneth for all the thought you put into this issue!

Second, I wanted to come back here and report on how things have been going for the past few months. I ended up creating a virtual lock system that takes inputs from the following two locations:

I then have a push notification to my phone that tells me which one actually activated the virtual lock system first. Currently, it's about a 50/50 split. . . sometimes the Z-Wave driver does it first, but other times the cloud driver works first. Having both methods has now increased the reliability of lock/unlock commands to over 99% when the cloud is available. If the cloud is unavailable, Z-Wave takes precedence and the reliability falls. . . but at least I can still control the lock without the cloud (albeit, less reliably).