August Smart Lock Pro 3rd Gen: "Partially" not working

[whinson]

I have an August Smart Lock Pro 3rd Generation connected to zwavejs2mqtt running in a container that I am attempting to use via HomeAssistant (2021.2.1) also running in a container. When I initially setup zwavejs2mqtt about 3 weeks ago, everything was going fine for about a week and then it randomly partially (for lack of a better word) stopped working. I say partially because there are only two noticeable things not working - the ability to lock/unlock the door and the reporting on the status of the door and whether it is open or not. Other things seemingly work fine - e.g. if I manually unlock or lock the door, the locked/unlocked status is instantly reported back as expected.

After checking everything I could think of to make sure nothing changed, I excluded the node and re-added it securely (it was added securely originally) and it started working again for about 5 minutes and then it stopped again. After repeating this exercise about 5 times, I am pretty perplexed as in my experience stuff just doesn't stop working after a few minutes - albeit I have little zwave experience and there could be something I just don't know.

So - I spent some time looking at the logs (snippets copied below) and nothing jumps out at me as there being an issue. At this point, I am not sure if there is an issue with the lock, my setup, or something else completely.

Does anyone have any advice advice on steps I can take to hone in on the issue or how I should proceed?

Thanks for the help!

2021-03-06 14:15:49.579 INFO ZWAVE: Node 18: value updated: 98-0-currentMode 255 => 255
2021-03-06 14:15:49.581 INFO ZWAVE: Node 18: value updated: 98-0-outsideHandlesCanOpenDoor false,false,false,false => false,false,false,false
2021-03-06 14:15:49.583 INFO ZWAVE: Node 18: value updated: 98-0-insideHandlesCanOpenDoor true,false,false,false => true,false,false,false
2021-03-06 14:15:49.584 INFO ZWAVE: Node 18: value updated: 98-0-latchStatus open => open
2021-03-06 14:15:49.586 INFO ZWAVE: Node 18: value updated: 98-0-boltStatus locked => locked
2021-03-06 14:15:49.588 INFO ZWAVE: Node 18: value updated: 98-0-doorStatus closed => closed
2021-03-06 14:15:49.589 INFO ZWAVE: Node 18: value updated: 98-0-lockTimeout 8 => 8

14:15:41.819 SERIAL « [ACK]                                                                   (0x06)
14:15:41.823 SERIAL « 0x0104011301e8                                                       (6 bytes)
14:15:41.823 SERIAL » [ACK]                                                                   (0x06)
14:15:41.824 DRIVER « [RES] [SendData]
                        was sent: true
14:15:43.098 SERIAL « 0x01050013e2000b                                                     (7 bytes)
14:15:43.098 SERIAL » [ACK]                                                                   (0x06)
14:15:43.099 DRIVER « [REQ] [SendData]
                        callback id:     226
                        transmit status: OK
14:15:43.119 SERIAL « 0x0110000400120a9880b365179e301fa72c10                              (18 bytes)
14:15:43.120 SERIAL » [ACK]                                                                   (0x06)
14:15:43.120 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceReport]
                          nonce: 0xb365179e301fa72c
14:15:43.128 SERIAL » 0x011e001312179881e05021892464ee73a2390cf7b3c76af2134326a3d225e366  (32 bytes)
14:15:43.130 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      227
                      └─[SecurityCCCommandEncapsulation]
                        │ nonce id: 179
                        └─[DoorLockCCOperationSet]
                            target mode: Unsecured
14:15:43.134 SERIAL « [ACK]                                                                   (0x06)
14:15:43.139 SERIAL « 0x0104011301e8                                                       (6 bytes)
14:15:43.139 SERIAL » [ACK]                                                                   (0x06)
14:15:43.140 DRIVER « [RES] [SendData]
                        was sent: true
14:15:43.162 SERIAL « 0x01050013e3000a                                                     (7 bytes)
14:15:43.162 SERIAL » [ACK]                                                                   (0x06)
14:15:43.163 DRIVER « [REQ] [SendData]
                        callback id:     227
                        transmit status: OK
14:15:48.174 SERIAL » 0x010900131202984025e4ec                                            (11 bytes)
14:15:48.174 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      228
                      └─[SecurityCCNonceGet]
14:15:48.177 SERIAL « [ACK]                                                                   (0x06)
14:15:48.181 SERIAL « 0x0104011301e8                                                       (6 bytes)
14:15:48.181 SERIAL » [ACK]                                                                   (0x06)
14:15:48.182 DRIVER « [RES] [SendData]
                        was sent: true
14:15:49.426 SERIAL « 0x01050013e4000d                                                     (7 bytes)
14:15:49.426 SERIAL » [ACK]                                                                   (0x06)
14:15:49.427 DRIVER « [REQ] [SendData]
                        callback id:     228
                        transmit status: OK
14:15:49.447 SERIAL « 0x0110000400120a988080d6ec76ef90f4fe52                              (18 bytes)
14:15:49.447 SERIAL » [ACK]                                                                   (0x06)
14:15:49.448 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceReport]
                          nonce: 0x80d6ec76ef90f4fe
14:15:49.453 SERIAL » 0x011d00131216988129a6b5fafcb38ff3d1e719806518b7f8714e8bbe25e548    (31 bytes)
14:15:49.453 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      229
                      └─[SecurityCCCommandEncapsulation]
                        │ nonce id: 128
                        └─[DoorLockCCOperationGet]
14:15:49.457 SERIAL « [ACK]                                                                   (0x06)
14:15:49.462 SERIAL « 0x0104011301e8                                                       (6 bytes)
14:15:49.462 SERIAL » [ACK]                                                                   (0x06)
14:15:49.463 DRIVER « [RES] [SendData]
                        was sent: true
14:15:49.484 SERIAL « 0x01050013e5000c                                                     (7 bytes)
14:15:49.485 SERIAL » [ACK]                                                                   (0x06)
14:15:49.485 DRIVER « [REQ] [SendData]
                        callback id:     229
                        transmit status: OK
14:15:49.509 SERIAL « 0x0108000400120298403b                                              (10 bytes)
14:15:49.510 SERIAL » [ACK]                                                                   (0x06)
14:15:49.510 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
14:15:49.518 SERIAL » 0x01110013120a9880c21d70f949919f1c05e613                            (19 bytes)
14:15:49.518 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      230
                      └─[SecurityCCNonceReport]
                          nonce: 0xc21d70f949919f1c
14:15:49.522 SERIAL « [ACK]                                                                   (0x06)
14:15:49.525 SERIAL « 0x0104011301e8                                                       (6 bytes)
14:15:49.525 SERIAL » [ACK]                                                                   (0x06)
14:15:49.526 DRIVER « [RES] [SendData]
                        was sent: true
14:15:49.546 SERIAL « 0x01050013e6000f                                                     (7 bytes)
14:15:49.547 SERIAL » [ACK]                                                                   (0x06)
14:15:49.547 DRIVER « [REQ] [SendData]
                        callback id:     230
                        transmit status: OK
14:15:49.576 SERIAL « 0x0121000400121b9881a437645125eaa80c511eeb2eb48fb97fc2781e0f4cd4eb6 (35 bytes)
                      1559c
14:15:49.577 SERIAL » [ACK]                                                                   (0x06)
14:15:49.578 CNTRLR   [Node 018] [~] [Door Lock] currentMode: 255 => 255                [Endpoint 0]
14:15:49.580 CNTRLR   [Node 018] [~] [Door Lock] outsideHandlesCanOpenDoor: false,false [Endpoint 0]
                      ,false,false => false,false,false,false
14:15:49.582 CNTRLR   [Node 018] [~] [Door Lock] insideHandlesCanOpenDoor: true,false,f [Endpoint 0]
                      alse,false => true,false,false,false
14:15:49.584 CNTRLR   [Node 018] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
14:15:49.585 CNTRLR   [Node 018] [~] [Door Lock] boltStatus: "locked" => "locked"       [Endpoint 0]
14:15:49.587 CNTRLR   [Node 018] [~] [Door Lock] doorStatus: "closed" => "closed"       [Endpoint 0]
14:15:49.588 CNTRLR   [Node 018] [~] [Door Lock] lockTimeout: 8 => 8                    [Endpoint 0]
14:15:49.590 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[DoorLockCCOperationReport]
                            current mode:           Secured
                            active outside handles: false, false, false, false
                            active inside handles:  true, false, false, false
                            latch status:           open
                            bolt status:            locked
                            door status:            closed
                            lock timeout:           8 seconds
14:15:49.845 SERIAL « 0x010b0004000b05310501010ec4                                        (13 bytes)

[airdrummingfool]

I'm having a similar issue with the 3rd gen August Smart Lock Pro. Sending a 'lock' or 'unlock' command via Z-Wave fails about 50% of the time. My lock has gone through one or two firmware updates recently, and I also recently upgraded to Z-Wave JS from the Home Assistant OZW beta, so I unfortunately can't easily point to any single breaking change.

Current lock firmware version: 1.59.0-2.0.4

Here's the z2m log output when I tell it to "lock" and it fails:

2021-04-05 04:41:07.049 INFO ZWAVE: Node 15: value updated: 98-0-currentMode 0 => 0
2021-04-05 04:41:07.050 INFO ZWAVE: Node 15: value updated: 98-0-outsideHandlesCanOpenDoor false,false,false,false => false,false,false,false
2021-04-05 04:41:07.051 INFO ZWAVE: Node 15: value updated: 98-0-insideHandlesCanOpenDoor true,false,false,false => true,false,false,false
2021-04-05 04:41:07.053 INFO ZWAVE: Node 15: value updated: 98-0-latchStatus open => open
2021-04-05 04:41:07.054 INFO ZWAVE: Node 15: value updated: 98-0-boltStatus unlocked => unlocked
2021-04-05 04:41:07.055 INFO ZWAVE: Node 15: value updated: 98-0-doorStatus closed => closed

I have been able to reliably get the lock to react by opening the August mobile app and using it to connect to the lock via BLE. All I have to do is open the app and tap the name of my home, which brings up the circular lock status screen. After it shows red or green (locked or unlocked, but connected either way), the lock will react when I send a Z-Wave command. I have also connected to the lock via BLE using a standard BLE exploration app (LightBlue), which tells me that the August app isn't doing anything special to 'wake it up' or fix its state.

[robertsLando]

@AlCalzone

[AlCalzone]

No idea what's happening. From the Z-Wave side it looks good. The lock/unlock command is sent, the device acknowledges it, but the verification after 5 seconds returns the old status.
So either:

• the lock is not accepting the command
• locking/unlocking physically fails
• or the status does not get reflected correctly

Have you checked if the lock actually does something when the command is sent?

[airdrummingfool]

I have been researching this a bit and have contacted August support. There seems to be a fairly common bug in the lock firmware which causes the lock to not respond to Z-Wave commands unless the lock has been interacted with outside of Z-Wave recently; i.e. manually operating the lock or connecting to the lock via BLE (e.g. using the August app). This is consistent with my experience. I've seen this referred to as "lock unresponsive to z-wave commands after entering low power mode" and "z-wave deep sleep".

Within the past few months, August put out a firmware update to fix an unspecified security issue. Due to this security "improvement", August is no longer allowing customers to request firmware downgrades to version 1.8.15 (which they were previously doing in order to avoid the aforementioned Z-Wave bug).

I emailed August and their first response hinted at some of these issues:

The recent firmware update is a required update as it contains a security improvement. If you were previously on an old custom firmware for Z-Wave functionality purposes then this new required firmware may break your Z-Wave integration. We apologize for the inconvenience this may cause as this is a mandatory firmware update. We no longer have the capability to revert to the old firmware at users' requests.

I asked for more information, but the support person dropped back to the standard response of "reset and try again":

Are you able to unlock/lock the door from the August app?
We recommend in the meantime to try doing a Factory Reset. Please keep in mind that when doing this it will remove all the users from the unit and the lock will be completed deleted from the August app, however, you can try setting up the lock again. Please try the following for the reset.

Open the August app and tap on the three-bar menu on the top left-hand corner
Choose Home, underneath Keychain, select the name of the house
Tap on Settings, followed by Lock Settings
Select Factory Reset
Please remove/reinsert a battery on the Smart Lock. Please make sure you are getting a green light on the lock (only one flashing green light)
Open the August app again and tap on the three-bar menu one more time
Select Set Up a New Device and choose the Smart Lock 3rd Gen Pro
When the set up is done please try adding the lock one more time through z-wave
Once this has been tried let us know the results.

When I get some time I will do what they ask (though based on at least one post I read, I risk losing all Z-Wave functionality) and see if I can push them to acknowledge the bug.

Other references:

• https://community.smartthings.com/t/june-2019-august-pro-z-wave-commands-fail-if-august-app-is-not-in-use-previously-worked-fine/165282
• https://www.reddit.com/r/AugustSmartLock/comments/lsi8ic/august_lock_pro_3rd_gen_does_anybody_else/
• https://community.hubitat.com/t/august-pro-z-wave-issue/46545/28
• https://www.reddit.com/r/AugustSmartLock/comments/lttc9v/august_is_refusing_to_downgrade_the_firmware_of/
• https://community.hubitat.com/t/august-wants-me-to-update-the-firmware-on-my-gen-3-locks-should-i/58546/4

[airdrummingfool]

Update: I did a full exclude/factory reset/reconnect/re-pair cycle as described above, and surprisingly enough the issue seems to have gone away. I have tested it a half-dozen times since I did the reset ≈48 hours ago, and it is locking and unlocking very reliably, regardless of how long it is idle before HA sends a Z-Wave command.

Since it has only been working for 2 days, I'm still a bit skeptical about long-term reliability, but I'm very happy with the performance of the lock with Z-Wave JS currently. I will of course update here (and continue my conversation with August) if it stops working again.

[JPDMaker]

Thanks for the ground work here. I was in the same situation. resetting seemed to have worked... although, still a bit of a delay from pressing command in HA to action about 3-4 seconds.

[brettonw]

I'm having a very similar problem. The logs showing the device getting messages and responding with no action, and interacting with the locks through the august app makes them respond. These were a new setup, and I've factory reset them several times and re-added to no avail (that's not a painless process) They are on the latest firmware (2.0.4). Do you still see this? Are you using the wifi connect as well?

Also, each time I interrogate the locks HA loses an attribute (battery level, jammed, etc.), but that's a separate problem. Easy enough to delete the integration and re-add it...

[airdrummingfool]

I did not have any further issues after my exclude/factory reset/reconnect/re-pair cycle as described previously. It worked for over 2 months before I moved; my new location provides a smart lock and I am no longer using the August, so unfortunately I can't help debug this further.

[Gangoke]

Doing exclude/factory reset/reconnect/re-pair cycle seems to have worked for me! Thanks!

[skyw33]

I have the exact same issue. I have factory reset both of my August locks twice and they work for a period of time but after a while, they exhibit the behavior mentioned in previous posts. I've contacted August but have not received a reply yet. I'm using home assistant (docker) 2021.11.5, zwavejs2mqtt (docker) 6.2.0, and the latest August firmware. I'm not sure exactly when it stopped working but it was probably in November 2021 sometime.

[whinson]

I came to the conclusion that August locks stop "listening" when their batteries move below 50%, which lead to the behavior I was seeing. I suspect if you insert new fresh batteries, everything will work as desired until it moves back below 50%.

That being said, I moved to Schlage Zwave connect awhile ago, so there isn't anything I can test to verify this for you. I am just going off memory.

[irakhlin]

I highly suggest anyone with this lock open a ticket with August and make as big of a stink as possible. For a while they were rolling back firmware if you contacted support because its an OBVIOUS firmware issue that they introduced along the way. It did not do this when I initially purchased it, but somehow along they way I may have opened the August app which then decided my lock needed a firmware update. The lock will eventually stop actually executing the zwave commands sent to it, the pings and messages are received by the lock just fine but it will not actually do anything. If you go into the August app and toggle the lock open/closed, zwave commands will again continue working.. until they don't. By the time I had contacted support with all of this information they had decided they were "no longer rolling back firmware" and suggested I use the August wifi bridge... Which obviously they suggested I purchase... Honestly has to be the most ridiculous suggest ever. Regardless I do not think this issue is related to zwavejs, I had this exact issue when using Smartthings months ago before switching to HA

[brettonw]

Can they define “latest”? I pulled my August Z-wave locks a week ago because of the lack of reliability.

[irakhlin]

Can they define “latest”? I pulled my August Z-wave locks a week ago because of the lack of reliability.

I am guessing latest is whatever their app suggests to install, if there is no suggested firmware it should be latest. I've checked mine regularly since this issue has been happening and have not seen any updates for a while. I am on the latest available for my 3rd gen pro; currently it's showing 1.59.0-2.0.4

[brettonw]

Since that is the same version I mentioned above, I do not think the problem has been fixed.

[linglingpin]

I'm having this problem as well, did the ticket / tweet gotten anywhere else? I may submit a ticket later.

[irakhlin]

I'm having this problem as well, did the ticket / tweet gotten anywhere else? I may submit a ticket later.

@linglingpin no. Please open another case and link them here again.

[Gangoke]

I wonder if the culprit is "[13-98-0-operationType] Lock operation type"
It has a Constant mode and Timed mode. Maybe its showing as Constant but is actually stuck in Timed mode.
If you're having this issue maybe try setting it to [2]Timed (dont forget to apply) then set it back to [1]Constant

Doing a factory reset and re-pairing worked for me so I don't wanna mess with it right now.

[linglingpin]

After some experimenting past few days, factory resetting solves this issue for me too, but multiple homekit users with the homekit integration to expose the lock breaks it for me it seems.

The below sequence seems to have higher chance to make this paired up and working correctly for me, however I don't use z-wave exposed to homekit with the home assistant integration anymore, only with August's homekit connection set up through the August app. This seems to be less buggy for me, and I use it as an easy to access wifi/bluetooth backup connection to the lock now, although a little slower than z-wave.

1. Exclude from z-wave, remove from homekit, factory reset the lock using the August app (lock settings, factory reset).
2. Wait for the green light on the lock, remove battery and put it back in, wait for another green light.
3. Pair your lock using the August app, connect to new "Home" if necessary, the old users don't seem to connect to the old home correctly for me.
4. Calibrate lock. Don't connect to homekit for now.
5. Connect to z-wave hub using inclusion, make sure connected with S2 encryption and the interview is completed. During my final attempt (it's working correctly now), I include the lock while the lock is in unlocked position, not sure if this matters or not. The lock now seems to work without timeout issue for me at this stage, I have tried a few times. However controlling with other users in homekit without following the below steps or connected before z-wave seems to creates the timeout issue for me, but I'm still not 100% sure...
6. Add all homekit users' August account to the home in August app.
7. Using the August app, connect to homekit in lock settings.

[linglingpin]

Ok, my lock has reverted back to unresponsive after timeout again and again, changing the lock operation type doesn't seem to help either.

Since yesterday, I've setup two input booleans to be switched on while locking or unlocking the door as a backup, automations in HomeKit is setup to lock and unlock the door when the input booleans are on, and finally automations in HA will turn the input booleans off once the lock has changed to the desired state.

So far so good, I do enjoy the super responsive z-wave controls usually, if the z-wave doesn't work, HomeKit bluetooth kicks in in a few seconds, still faster than my experience with controlling the Gen 4 August Wi-Fi lock with either Wi-Fi or bluetooth.

[brettonw]

Why two input_boolean?

[linglingpin]

I thought of using one, with lock = on, unlock = off. With this I'll need to use automations to set the input boolean when I manually operate the lock (state change), I fear the lock would lock / unlock with an incorrect report of state change, not sure it'll really do that though. So just in case, I set mine as a "command to lock / unlock", I only turn the input booleans "on" when I'm issuing a command. I don't use toggle / following state change with them.

That's why 2 input booleans, one "on to lock", other "on to unlock". They'll be set back to "off" when the state confirmed the change.

[brettonw]

Thank you. You’ve got a neat fallback solution to the problem, but it would be better if August would fix the problem. I think it is a significant indicator of their intent that they dropped z-wave on the gen 4 locks.

[lesourcil]

Hi guys,

i'm in the same boat with my gen3 august lock. It was working fine last time around november 2021 and now its unresponsive. It can unlock the door sometimes, but can't lock it back. If I connect with the app and the wifi bridge, then it become responsive again. It's clearly the last time I buy an august device if they don't fix this. I thought it could have been introduce with HA or Z-Wave JS but since we are all experiencing the same issue using multiple system, i'm starting to think that they have a firmware issue to fix.

I wonder how we could make them fix it. Clearly the majority of the population uses their app with the wifi option so we are not major numbers here.

[brettonw]

As evidenced by them dropping z-wave support in their newer products. I have 10+ second latency using them from bluetooth, now - but I'm not willing to go with the cloud interface from wifi even though it is faster.

[Gangoke]

Mines been pretty much stable. I did have an instance where it stopped responding to zwave commands, but a quick power cycle fixed it right up. I was messing around with my servers, so it was likely caused by me rebooting the zjs2m server.

From the behavior I'm still convinced it's a bug with the operationType setting.

Try this, it's been working for me. Start fresh and After you pair the lock, let it complete the interview, then take out a battery from the lock for a few seconds and put it back in. If you ever lose zwave control, just take out a battery for a few seconds and put it back in. Also, Idk if this will be viable for you, but I never open the August app. Not sure if it breaks it or anything, I just don't care to find out.

[Gangoke]

As evidenced by them dropping z-wave support in their newer products. I have 10+ second latency using them from bluetooth, now - but I'm not willing to go with the cloud interface from wifi even though it is faster.

I doubt they'll pick up zwave again. But I can see them doing Thread when that gets more rolled out.

[lesourcil]

Mines been pretty much stable. I did have an instance where it stopped responding to zwave commands, but a quick power cycle fixed it right up. I was messing around with my servers, so it was likely caused by me rebooting the zjs2m server.

From the behavior I'm still convinced it's a bug with the operationType setting.

Try this, it's been working for me. Start fresh and After you pair the lock, let it complete the interview, then take out a battery from the lock for a few seconds and put it back in. If you ever lose zwave control, just take out a battery for a few seconds and put it back in. Also, Idk if this will be viable for you, but I never open the August app. Not sure if it breaks it or anything, I just don't care to find out.

I'll give it a try and post my results here

[anoblet]

Is there any update on this?

[skyw33]

I switched my controller from z wave series 500 to a zooz z wave 700 series controller and have not had any issues with my August locks for 2 months.

[lesourcil]

Interesting. I might give it a try.

[skyw33]

Make sure you upgrade the firmware before using the stick. There have been serious issues with 700 series zwave controllers for those not on the latest firmware. I updated my firmware and have had no issues. https://www.support.getzooz.com/kb/article/931-how-to-perform-an-ota-firmware-update-on-your-zst10-700-z-wave-stick/