All great suggestions, but yeah - tried them and no help.
Just throwing my hat in here too that I’m having the same issue. I’ve contacted August and they supposedly have a bug open and devs trying to repro the issue. It really does seem like it’s related to august’s firmware. I’m pretty sure I started having this issue right around the time I did an update (it auto-starts when you open the august app now).
My guess is the same as everyone else’s they changed an algorithm around when to conserve energy and got it wrong. So BLE stays active but ZWave isn’t in a good state.
Yeah, I feel the same. I noticed the auto-firmware-upgrade change recently; not automatically a bad thing (most smart devices already do it) but it was a shift from their original approach of letting you choose when to do it.
I hope it gets straightened out soon - between the terrible issues with ST presence last year and now this, one of my main smart home use cases (unlock the door when I get home!) keeps getting cut off at the knees.
Exactly. I have several routines that are mostly useless now. As a stop-gap I’ve gone back to using the auto-unlock feature within the august app itself. But if it can’t be fixed I’ll probably be getting kwikset deadbolts. That’s a last resort though, considering in total I’ve spent about 650 for 2 locks/connects/keypads I have.
I haven’t tried it in a long time, but the August native auto-unlock always really disappointed me. It had a terrible time detecting arrivals. Not sure if that’s been improved in the interim.
FYI:
1 Like
Which firmware are you all seeing the issue with? I may have access to an August Lock on older firmware and could help test.
1 Like
My lock is on b87fea72-1.59.0-1.13.2
My firmware version reads 1.59.0-1.13.2 (I don’t have that prefix beginning with b897 displaying in the app).
I also submitted a fresh ticket with August support today. If everyone else who doesn’t have an open ticket does the same, hopefully that will provoke a response.
1 Like
Rob, do you have a support ticket number we can reference?
1 Like
OK, I just emailed the support address with some details and links to these two threads. Hopefully if we get some more folks doing the same it will get us somewhere.
2 Likes
I’ve checked my email thread with August and unfortunately they don’t provide a ticket #.
I did want to add that I have the same firmware that other people are reporting.
Thanks all. I have an August Lock with FW version 1.59.0-1.12.6 I can test with.
Just to confirm, lock/unlock commands via the SmartThings apps works from the device page. The lock is only failing to lock/unlock when the command is from an automation. Is that right?
Same - no support ticket but I referenced the firmware version in my request to them.
Just to confirm, lock/unlock commands via the SmartThings apps works from the device page. The lock is only failing to lock/unlock when the command is from an automation. Is that right?
No, the August doesn’t respond to Z-Wave at all while idle. This includes commands sent directly from the device page and automations. When you look at the log results, it looks like SmartThings tries to send the command and just doesn’t receive a response, so it times out.
1 Like
No, that’s not right - automations and manual operation from within SmartThings both fail.
If you operate the lock from within the August app, manually by hand (twisting it on the door) or via HomeKit, it will respond to z-wave again - for a little while. But after some amount of time (for me a couple hours) it will not work from SmartThings at all - either from the app or from automations.
You’ll tap the “LOCKED” icon and it will show “UNLOCKING” but then go right back to LOCKED. Live Logging shows that the command was sent but it seems no response is received/command is ignored
1 Like
There’s one detail I saw because I wasn’t filtering by thing. I may be wrong, but there seems to be a related debug log where it says there’s an invalid token:
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug getLockProperty: getLockStateCommand response: [lockState:LOCKED, applianceResponseTimestamp:2019-06-04T10:38:56.868Z]
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug in getLockStateCommand
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug in getLockProperty
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug Property Changed event lock: locked (source: DEVICE)
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug handleLockEvent - token is invalid - sending as PSU
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug isCorrelationTokenValid? false (null; evt 1559659636358; tok 0; 60)
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug Is ctData not null? false; Is ctData.token not null? false; token timestamp age: 1559659636358
528a27ed-dafa-409f-8f6a-e4ff100777ac 10:47:16 AM: debug handleLockEvent locked on Driveway Deadbolt (536c881f-3bac-4dea-85a3-7b38ec22a1cc)
Understood. It does seem like a lock firmware issue potentially. Manual operation from within ST works fine for the lock running 1.59.0-1.12.6 firmware.
EDIT: Tried a routine set to lock at a specific time and that worked as well.
1 Like
Hey Brad, just to make sure you understand – this is an inconsistent issue. If the lock is “awake”, it responds to SmartThings Z-Wave commands without issue. The problem is if the lock has been sitting idle (somewhere between 15 minutes and two hours seems to be the cut-off point), then it just completely ignores ST and only responds to the August app.
Using the August app or manually turning the lock, though, will “wake” the device and it will respond to Z-Wave, again for a short time.
You’re correct, this is most likely a problem with August not following Z-Wave spec but maybe your team can help them figure it out.
Some minor good news: support has relayed this forum thread to their engineering team. So whenever one of you reaches out to them and mention it, they should be able to track affected users.
1 Like