August lock issue

[tmorse305]

I recently added the z-wave module to my ISY994(5.0.15A) so that I could connect with an August lock.  This is my first experience with using z-wave.  I have just 2 devices, the lock and a plug that I'm using to split the distance between the lock and my ISY.  As others have reported when the lock is added it creates 2 nodes.

I'm experiencing a problem where one or both of the nodes are out of sync with the actual lock condition.  I have only seen the condition where ISY is reporting the lock as unlocked but the lock is actually locked.  Last night it happened again, the first node reported locked but the 2nd node reported unlocked.  The door was locked.  I ran a query on the 2nd node but it did not update the status to locked.  There was no communication error reported, the query seemed to complete correctly, but the node status remained unlocked.

The event log associated with the query is below. 

Is there a reference somewhere for interpreting the viewer?  I could only find one for Insteon.

Would a query complete without an apparent error even if there was a communication problem with the device?

I guessing it may be a weak z-wave network but I'm hoping those with more experience can comment.

Thanks,

Tim

 

 

Thu 09/12/2019 10:14:03 PM : [ZWAVE-WAKEUP   3.000] Query device ZW003_1 Thu 09/12/2019 10:14:03 PM : [ZWAVE-TE        ] [80/02] Battery Get ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:03 PM : [ZWAVE-TX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:04 PM : [ZWAVE-RX ZW003_1] [98/80] Security Nonce Report - nonce=[383E195872B9C9B8] ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:05 PM : [ZWAVE-RX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:05 PM : [ZWAVE-TX        ] ... Thu 09/12/2019 10:14:05 PM : [ZWAVE-RD        ] [010A001303038003642500D0]              REQ ZW_SEND_DATA  Thu 09/12/2019 10:14:05 PM : [ZWAVE-TE        ] [62/02] CC=0x62 cmd=0x02 [] ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:05 PM : [ZWAVE-TX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:06 PM : [ZWAVE-RX ZW003_1] [98/80] Security Nonce Report - nonce=[4FE0AC0E8C424DD6] ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:06 PM : [ZWAVE-RX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:06 PM : [ZWAVE-TX        ] ... Thu 09/12/2019 10:14:06 PM : [ZWAVE-RD        ] [010E001303076203FF0101FEFE2500A5]      REQ ZW_SEND_DATA  Thu 09/12/2019 10:14:07 PM : [ZWAVE-TE        ] [71/07] Alarm cmd=0x07 [] ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:07 PM : [ZWAVE-TX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:07 PM : [ZWAVE-RX ZW003_1] [98/80] Security Nonce Report - nonce=[E4A6FADC71566DC4] ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:07 PM : [ZWAVE-RX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:07 PM : [ZWAVE-TX        ] ... Thu 09/12/2019 10:14:07 PM : [ZWAVE-RD        ] [010B0013030471080140250001]            REQ ZW_SEND_DATA  Thu 09/12/2019 10:14:07 PM : [ZWAVE-TE        ] [71/04] Alarm Get type=0x00 ztype=0x06 ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:07 PM : [ZWAVE-TX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE To=0x03 Thu 09/12/2019 10:14:08 PM : [ZWAVE-RX ZW003_1] [98/80] Security Nonce Report - nonce=[D030EE547C78B86D] ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:08 PM : [ZWAVE-RX ZW003_1] [98/80] Security Nonce Report - nonce=[EF5CD333E6C7E2AE] ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:08 PM : [ZWAVE-RX ZW003_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE From=0x03 Thu 09/12/2019 10:14:08 PM : [ZWAVE-TX        ] ... Thu 09/12/2019 10:14:08 PM : [ZWAVE-RD        ] [0110001303097105000000FF0600002500B5]  REQ ZW_SEND_DATA

 

[gviliunas]

@tmorse305

Anecdotally, I have seen the same symptoms of the August lock status not agreeing with ISY. I only casually looked at this problem as a separate door position sensor was more critical to my application.  In troubleshooting the lock communication, I plugged in an Aeontec Z-Wave repeater into an outlet within 4 feet of the lock. I also put the August WIFI connect module on a short cord so that I could position it 90-degrees to the lock (saw this somewhere on a post about August locks). According to the phone app, this orientation greatly improved my connection between WIFI module and the lock. (I think that position of the connect module should not affect lock-ISY communication??)

I had written a program to look for the door left unlocked more than 3 minutes. Prior to my changes, I was getting false triggers due to the lock status in ISY not matching the lock's true status. Now, the lock status appears to be reporting correctly but my testing was not exhaustive. I need to go back and be sure that ISY is truly getting the signal when the lock opens and then closes. I'll update this with my results.

[lilyoyo1]

With only having 1 repeater, you're wasting your time troubleshooting with the lock in place. Take the lock off the door, bring everything close to the isy, run a heal and test it within about 5 feet of the isy. If it works fine then that answers your question 

[dxdc]

@gviliunas @tmorse305 have either of you figured out the solution to this problem? I'm seeing this behavior also, and it causes strange sync issues once it arises.

I'm wondering if lock requests should be initiated from "Lock 2" instead of "Lock", though I think something else may be the problem here. I have a weird suspicion that there may be a difference between a lock being opened manually vs. the August app/Auto-unlock and that this can cause it, but haven't been able to verify it.

Augusts implementation of HomeKit using the Connects is extremely buggy. I contacted their support about it a couple of years ago and they were really unhelpful and kept reading me instructions from their help site about pairing/unpairing.

I read somewhere that removing the Connects helped someone else and may try this myself. With Zwave I get a nearly instantaneous response that a door is locked/unlocked, whereas with August's official HK integration it could take 1-15 seconds depending on the wind speed that day.

[tmorse305]

@dxdc, The second node issue is a problem with the ISY recognizing the lock correctly.  The second node should be the contact sensor but it's not recognized correctly.  I have made UD aware of the problem, they will need to make software changes on their end to fix it during the z-wave pairing process.  The z-wave communication with this lock is very complex compounded by the fact that the lock needs to send lock status and contact status.  You will need a rock solid z-wave network to get it to work reliably based on my experience.  i finally solved the problem by using a Hubitat in close proximity to the lock.  The Hubitat recognizes the lock and contact correctly.  Hubitat updates the lock/contact status variables in ISY via the portal.  The lock is not without issues.  August down graded my lock software to a  version that they said had better z-wave performance.  Even so occasionally the lock will stop communicating via z-wave.  If a pull a battery and wait a few all is well again.  Bottom line for me is that the native app seems to work well but the z-wave is flaky at best.  I would not recommend anyone buy this lock for use with their home automation system.  Maybe the new WiFi version will be better for integration.

[dxdc]

@tmorse305 Thanks for following up.

I was doing some troubleshooting that makes me wonder if the encryption is at least part of the problem. I have several August Pro locks and even the native Homekit performance is unreliable. The Homekit status frequently doesn't align with the actual lock's status, as it appears to be in a "stuck" state on Homekit (e.g., "Locking....").

August support was completely useless, they seem like programmed robots that just regurgitate the same information on the August support website. I'm surprised they actually helped you downgrade the firmware. Strange that their older firmware is more reliable? I'm cross-posting a revelation I made today, which is that ISY is sending unlock/lock commands to BOTH nodes simultaneously. I wonder if that is causing some serious problems.

The native app does work well, but that's only because it operates using bluetooth.

Their new Wifi version has a terrible battery life, I'm sure... with bigger batteries. It does seem like the locks go to sleep periodically and become unresponsive too. It would be a shame to completely switch to a different product but the reliability problems with August are growing. I've been eyeing this one: https://level.co/products/level-lock though I wish it had a door sensor.
 

 

[tmorse305]

@dxdc, thanks for the reply.  The Level is very interesting, clever design.  It looks like it's limited to Homekit for communication.  It can't help the ISY communication if it is trying to unlock the contact sensor.  I could never get it to work reliably with either node and I only had one lock.