August Lock broken communication


HUB SW is and Lock FW is 1.59.0-2.0.4

I know, there are many related posts (I guess, I red all of them) related to August Pro locks.
However at this time I am not 100% convinced the problem is purely related to the lock.
From the Device Page if I click on the "Refresh" button the lock always responded with a
correct status:

and Znifer also shows some traffic to the lock (lock ID is 124):

However if I try to "Unlock" lock the HE log shows only single related line:
(assuming the "unlock" command was sent to the lock and at this time
this is only action expected from the hub)

and Zniffer shows a correspondent traffic to the lock but Ack is absent:

My question is:
Is this really problem with a lock itself or for whatever reason hub sends unrecognizable
command to the lock?

Why I am thinking this way?
Because lock always responds to the "Refresh" command/button.
This means lock actually wakes up in response to the "Refresh" command but fails to
wakeup for "Lock"/"Unlock" commands.
Does this make sense?

And "yes", if lock is touched either manually or from August application it does respond
to the HE commands during certain time (I guess, until lock goes to sleep).

1 Like

Major update to locks in 2.2.9.. And I have one of these locks in place on 2.2.9 and have no issues with responsiveness..

Just FYI, I have the same issues as @vitaly_kh on 2.2.9. They began about a week before 2.2.9 within hours of upgrading the locks firmware. The same symptoms appeared after an upgrade three years ago and the remedy was a firmware downgrade pushed by August. Got an email from support this morning

Thank you for your response.

We apologize for the inconvenience this has caused.

We have requested a firmware downgrade from our team. We will reach back out to you once this has been pushed.

In the meantime, feel free to let us know if you have any further questions or concerns.

Have a great day!

We'll see what happens.

1 Like

updated my C-7 hub to the latest SW.
And just in case, rebooted hub.
This did not fix a problem but actually made it a bit worse.
Now by doing a "Refresh" lock does not reported lock status at all, it only reports Battery level:

Before the update lock status was reported correctly.
Here is a correspondent Znifer trace:

Lines 147:157 corresponded to the Hub Reboot process.

Now hub log for the "Unlock" command is different:

And lock responded with an Ack:

But lock itself did not do anything at all.
When attempted to "unlock" lock from August app lock worked as expected
and a correct status was reported back to HE:

And of course, when I send a "lock" command from HE it worked as expected:

My conclusion is:
August ZWave FW may not be perfect but HE August Driver also has a problem(s).
Bryan, what do you think?
What else is not right with August-HE integration?
Please let me know if you want me to test something else?

BTW, (@bjcowles) I also emailed August Support regarding ZWave related problem
but so far did not get any response at all.

I am not sure how soon August lock goes to sleep but after about 5 min of inactivity
it stoped responding to the HE commands.

+1 for having a similar issue. I have an August Pro Smart Lock 3rd Generation (Firmware: 1.59.0-1.8.15) linked with Hubitat. It is an "August Pro Z-Wave Lock" device within Hubitat. The latest version of the Hubitat firmware can successfully lock and unlock the August Pro, but the current status of the August Pro always says "locked" no matter what the actual state of the August Pro really is. The status for the accompanying August DoorSense contact sensor works perfectly, though.

I've already submitted all this information to, and the engineering team is currently looking into it.

1 Like

I’d also like to report that I have this issue as well. For now I’ve downgraded to get my locks working again.

1 Like

same issues...

1 Like

So, did I get it right, downgrading lock to the 1.59.0-1.8.15 as suggested @bjcowles
will not work with latest HE SW 2.2.9,134?
Now I am more convinced the problem is rather HE August Pro driver than
August Lock firmware (which is not perfect).
Yesterday after I upgraded my C-7 the latest as suggested by @bcopeland
things became even worse (please see my post above for the details).
I hope, this will be finally fixed.
I love my August Pro.
But assuming the problem was/is a lock firmware I started to think about
replacing it with whatever Zigbee version.
Now I will wait a bit hopping for the fix.

I certainly appreciate the added data, but it baffles me even more :crazy_face:. @Jayhead13 gets lock/unlock to go through,but no status. I get nothing unless the August app is open on my phone or I've manually awakened the lock. Hmm. So maybe I need to get the lock firmware rolled back and the hub rolled back...OR just get a different lock because I'm getting really tired of dealing with it. :rofl:

Mine is working great.. But I have not messed with the firmware version on the device.

1 Like

I downgraded my August Pro's firmware a few years back, and I've been sitting happily on August Pro firmware version 1.59.0-1.8.15 ever since.

I've tried the latest version of the Hubitat firmware (, and I still have the same issue with the lock status not changing when locking and unlocking the August Pro via Hubitat. The last version of the Hubitat firmware that works as expected with my August Pro is Hubitat version, so I have downgraded my Hubitat to this version (just as @jeffdoubleyou has done). My current plan is to sit on this Hubitat firmware version until a fix gets deployed.

1 Like

1 Like

I am not sure what was the original version firmware version on a lock
but current/latest is 1.59.0-2.0.4
@bcopeland what is firmware version on yours lock?

My lock was working more or less reliably with C-5 hub.
Things became completely broken when I switch top the C-7 hub.
So lock was removed from the C-7 hub.
Recently I tried to pair lock back with the C-7 hub because I need
to improve "auto-unlock" functionality. At this time HUB SW version
Lock was responsive to the HE commands but only for very short time
and only after it was touched either manually or by August app.
Surprisingly lock always responded to the "refresh" command and
always reported a correct status all the time.
This tells me lock is actually waking up but only in resp[once to
the "refresh" command from HE.
This was a whole reason why I started to suspect HE vs. August
and created this topic.
@bcopeland suggested to update hub to the latest SW.
I did and this made things even worse. Not lock still wakes up
bur does not report status anymore.
Taking in account "one variable at a time" approach for the
debugging a problem clearly pointed to the HE Driver
(or whatever else inside HE).
My best hope, this problem will be fixed.
I have Zniffer up and running and I am willing to conduct
any testing in order to nail down this problem.

@bcopeland thank you for this short video.
My lock has exactly the same behaviour but only about 5-10 min
AFTER lock was touched manually or by app.

1 Like

@bcopeland : Do you happen to have a copy of your log at the time you took that video? Curious if there's any glaring differences between yours and mine. I'll attach my log at the bottom for everybody's reference (it's the same one I sent to Prior to recording the log, my August Pro was physically locked and also showing a "locked" state within Hubitat. I then started "recording" the log and did the following:

  • Executed an unlock command from Hubitat
  • Saw and heard the door physically unlock
  • Executed 3 refresh commands (to try and get the status of the August Pro to update)
  • Never saw the state of the the August Pro change from "locked" to "unlocked" in Hubitat

The most important one:


DoorLockOperationReport: DoorLockOperationReport(doorLockMode: 0, outsideDoorHandlesMode: 0, insideDoorHandlesMode: 1, doorCondition: 3, lockTimeoutMinutes: 254, lockTimeoutSeconds: 254)


DoorLockOperationReport: DoorLockOperationReport(doorLockMode: 255, outsideDoorHandlesMode: 0, insideDoorHandlesMode: 1, doorCondition: 1, lockTimeoutMinutes: 254, lockTimeoutSeconds: 254)

Those are some interesting battery reports as well.

@bcopeland : Thanks for that information! I re-updated my Hubitat firmware to in order to test this out a bit more. It appears that the log information on my Hubitat matches the log information on your Hubitat for both locking and unlocking the August Pro.

When I press the refresh button, the log information is also correct (as the log entries match-up with your log entries for the expected state of the August Pro). Unfortunately, the "current state" of the August Pro still remains unchanged in all situations. So it appears that everything is acting as expected except for the "current state" of the lock on Hubitat.

Based on my minimal experience developing custom apps and drivers on Hubitat, it seems like this might be an issue with the initial state of the August Pro when updating the Hubitat firmware. If you're not in the lucky initial state at the time of the Hubitat firmware update, you never enter the blocks of code that allow the August Pro's "current state" to actually update. However, if you're in the lucky initial state at the time of the Hubitat firmware update, you will enter the proper blocks of code and everything will work seamlessly going forward. This could explain why one person's lock state is updating and the other person's is not updating, even though the log shows the same information in both people's cases.

I am not a SW developer but to my eyes the above statement makes very little sense.
Why updating HE SW should/may/could depend on state of whatever device?
The SW updating process absolutely must not depend on the devices states.
And if this is actually a case this must be fixed ASAP because this is absolutely wrong.
What I am missing here?

@vitaliy_kh : Trying to think my way through what could be wrong, since @bcopeland showed a video of his "current state" working, yet many of us are having issues with ours. Especially when you're a code developer, some of your states might've been set during the development process. . . maybe you set a variable somewhere in the development process that helps you enter a loop that nobody else can enter. Seems like @bcopeland works for Hubitat, so that's why this came to mind. Not sure if it's the issue, though, but could be worth looking into if the developers are hitting a dead-end.