August Smart Lock Pro zwave timeout

Configuration Z-Wave
1

I’m having problems with my August Pro 3rd Gen lock via zwave.

First all the details
Running Hass.io 82.1
Lock firmware version is latest available
Aeotec Gen 5 zStick
Lock is approximately 20ft away from zStick through one wall. The lock is a direct neighbor of the hub.

I’m in the process of migrating from Smartthing to HA. The lock worked flawlessly when it was paired to SmartThings. When I tried to pair it with HA I didn’t get any command sets correctly detected by HA for the lock. I went ahead and factory reset the lock and paired it again. This time I was able to get command sets, but it seems that all the commands timeout in OpenZwave:
2018-11-29 14:15:32.709 Info, Node017, Sending (Send) message (Callback ID=0x87, Expected Reply=0x04) - DoorLockCmd_Get (Node=17): 0x01, 0x09, 0x00, 0x13, 0x11, 0x02, 0x62, 0x02, 0x25, 0x87, 0x34
2018-11-29 14:15:32.718 Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2018-11-29 14:15:32.718 Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
2018-11-29 14:15:33.969 Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x87, 0x00, 0x00, 0x7e, 0x12
2018-11-29 14:15:33.969 Detail, Node017, ZW_SEND_DATA Request with callback ID 0x87 received (expected 0x87)
2018-11-29 14:15:33.970 Info, Node017, Request RTT 1260 Average Request RTT 1262
2018-11-29 14:15:33.970 Detail, Expected callbackId was received
2018-11-29 14:15:42.710 Error, Node017, ERROR: Dropping command, expected response not received after 1 attempt(s)
2018-11-29 14:15:42.710 Detail, Node017, Removing current message
2018-11-29 14:15:42.710 Detail, Node017, Notification: Notification - TimeOut

My assumption here is that the timeout value in OpenZwave is too low for this lock, but SmartThings was a little more tolerant of slow devices. I think this is more of an OpenZwave/August problem than an HA problem. I couldn’t find a setting to adjust the timeout of OpenZwave to test my theory.

I did have to modify the zwave_cfg.xml to include the vendor information so it didn’t show up as “Unknown Device”. But I think that’s more of an issue with the OZW database not being up to date in HASS than anything else.

Does anyone else have the ASL-03 working successfully via Zwave?
Is there a way to adjust the OpenZwave timeout?

2

My August Pro 3rd Gen was showing up for me as an Unknown Z-wave device the first time I tried to add it. Come to find out I needed to enable a network key in options.xml in the HA config directory. The key can be any 16bit value you wish. Make sure to remove the Unknown Device node from your Z-wave config in HA and also unlink the lock from the Z-wave hub in the August app. After that is complete, restart HA and add the August lock as a secure node.

3

@barryq I am having the same issue with timeouts. I see you AverageRTT for the August locks are very high … so I checked mine and have the same issue (despite them being next to multiple repeater neighbors that have no issue).

I did not have to change the config file to get them to show up as August locks. Probably a later update fixed this. But you should know this probably isn’t the cause of your problems.

Any devs on here have some thoughts?

Anyone else with an August zwave lock can check for errors in the OZW_log, and/or long AverageRTT times (>1000).

4

Glad to know it’s not just me. I have seen a few post on the forums by people saying that the lock was working fine.

I didn’t believe that the change to the config file would address my issue. I just wanted the hardware to be identified properly. Glad to know it’s been updated though.

I haven’t had a chance to contact August yet. But they do seem willing to help when I called them asking about the latest firmware issue. Hopefully they can help me. I don’t think there is much the HA devs can do. To me, this seems like an OZW issue. But given all the Z-wave users here, I was hoping somebody may be able to give a push in the right direction.

5

I finally figured this out. Turns out somehow the NetworkKey never got set in the options.xml. I thought this whole time I was was using Zwave Plus and securely adding my nodes that supported it. Turns out I wasn’t. When HA tried to poll a command class that required Zwave Plus the device would just time out instead of responding with an some type of error the ZWP was required to access a specific command class.

6

Thanks for this info. I had the same exact problem with my August lock, then added network_key to configuration.yaml, but saw the key wasn’t in options.xml so I uncommented the network_key section and added it in. Now the August lock is properly detected in Home Assistant.

7

So I am having a similar issue that just started a couple weeks ago. For some reason, the lock will not work on zwave unless it wakes up from the app. If I use the app, then zwave will work - until it stops again. Anyone else experience this? I have the network key in configuration.yaml and options.xml, but I’m baffled.

8

Can’t say I’ve run into that problem. What does the OZW_Log.txt look like? Anything obvious in there? Any other dead Z-Wave devices? Sometimes that causes a lot of odd things.

9

did you find a solution for this. I am in the same boat :frowning:

10

Looks like the issue is not tied to zwave on HA.
There is a similar thread on smartthings forum too

11

Where did you find this option xml? I saved my key on LastPass since a while ago but it never occurred to me to add it to my config I was still a newbie back then and still am I just read and search more now. However I can’t seem to verify if my key is right by looking inside any of the files in my config folder.

I am having this issue too of timeout but I mistakenly forced removal of my August lock many times a few before I added the network key into my YAML and some after.

Nevermind I found the options.xml and I do see my network key was commented out all this time and never set appropriately, it starts at a default value of like 1,2,3, etc. I have already set this in my yaml but I think that I have messed up as none of my devices are set with this network key then and I have already tried force removing my august lock many times.

Now I see in the zwcfg file that my lock is present like 4 times with different node ids. I know this can’t be good.

12

options.xml lives in the root of your HA config.

But something else seems to be going now. The lock doesn’t seem to be responding anymore. It looks like the same behavior as before. It doesn’t seem to be using zwave+ but I don’t have an old log from when it was working to compare to now. I have updated HA a few times and even migrated to docker since I got it working. It could have been a change I made in all of that, but I’m not convinced because the garage door still works and that requires zwave+

13

So i got mine working but I had to change something in the storage > core.config.entries since I noticed that the network key was not right there and after a restart that key now reflected was was in my config .yaml file then I paired my august for like the 8th time now and it finally works!!! Granted I notice that occasionally I have other nodes fail but if I do a test node or heal node they sometimes come back. Z wave seems to be a pretty delicate thing you have to be patient and not move too quickly even restarting back to back can mess a node up if the network wasn’t allowed to come up completely.

Hope this helps. Not sure exactly error you are getting but wondering if my experience can help you or others.

14

Nothing actually “messes up a node” (save from firmware issues or hardware death), the only thing that will get skewed is your cache file the zwcfg_xxxxxx.xml file. Since it’s a cache file you can delete it and it will be re-created by pyozw. Also the more mains powered nodes you have the stronger your zwave mesh network becomes. It’s actually quite stable and versatile when setup properly.

15

So I know that the more mains powered devices I have the stronger the signal and network will be but given my recent experience with my August lock not pairing (until recently) and allowing me to discover that my network key was never properly setup I’m concerned that maybe my devices weren’t “setup properly”. I have about 4 GE zwave plus switches 14294 and one 14287 GE fan control that are zwave plus I’m concerned that they aren’t properly setup. However now that I think of it may be they are given they aren’t secure nodes they don’t need the network key right?

I guess do you know how to measure how strong your zwave signal is? Sort of like you map your WiFi signal?

16

You can use the zwave maping tool someone created for Home Assistant, it doesn’t tell you signal strengths but gives you RTT (latency times) and hop count.

Normally light switches and fan controllers do not require to be secure.

Not a stronger signal, more nodes means more potential hops for commands to go through, similar to how the internet works. If one node goes down/has a poor connection, the command can be routed via another node in the network.

17

I found this one. Which one are you referring to? I had also bookmarked this guide that talks about how to integrate it.

18

That’s the one but here’s the thread:

19

Apparently they pushed firmware to our locks that will make your zwave useless unless you open the app on your phone first. If you message support and ask them to downgrade you to 1.59.0-1.8.15 firmware you will be back to normal zwave working.

1 Like
20

I just wanted to report my experience with this in case it helps someone else out. I was seeing the same log messages as posted at the top and failing to lock and unlock my August lock via zwave in home assistant. I have the latest firmware – the one people had identified as problematic here and in the smart things thread. When I set up my lock I had also set up doorsense. I noticed around the time zwave stopped working doorsense also stopped reporting the door was ajar in the August app. On a hunch I recalibrated the lock and doorsense, and afterward zwave lock/unlock commands started working again, without downgrading the firmware.

It’s as if the lock disables the zwave commands when it can’t reliably detect the door state.