About two weeks ago the Kevo smart lock was becoming unresponsive. My kids were having problems unlocking it from the outside and it was difficult to lock it as well.
The old Kevo lock was bluetooth only and with recent iOS updates, the quality of the bluetooth connection has gradually degraded to the point it rarely works. Because it is a very old version, we have not received any firmware updates. We purchased the lock in 2013/14 period so we have gotten a good 6 years worth of use.
We decided to get the August WiFi Smart Lock, with the hope that its WiFi connectivity will enable us to use the lock with HomeKit. Along with the August, I also purchased the Weiser Round Deadbolt Featuring SmartKey. The SmartKey feature allows us to reprogram the lock with our old set of keys so that we don’t have to change the front door keys.
The uninstallation of the Kevo unit and the installation of August was pretty straight forward. However, the operation with HomeKit did not work fully. It registered fine, and HomeKit was able to detect whether the lock was engaged or not. However, HomeKit did not respond very well to locking and unlocking the lock. Things improved when I reset the unit to factory settings and repeat the procedure again.
The iOS August App worked fine. I learned from the App that it has a smart connectivity feature that automatically determines whether it will connect via bluetooth or WiFi. As a person in this profession, this immediately raised alarm bells. My theory is that to save power and battery life, August engineers have aggressively underpowered the WiFi functionality. This was partially confirmed when I noticed the very long latency pings to the unit. Here is a sample inspection:
$ ping 192.168.168.36
PING 192.168.168.36 (192.168.168.36) 56(84) bytes of data.
64 bytes from 192.168.168.36: icmp_req=1 ttl=255 time=381 ms
64 bytes from 192.168.168.36: icmp_req=2 ttl=255 time=10384 ms
64 bytes from 192.168.168.36: icmp_req=3 ttl=255 time=9377 ms
64 bytes from 192.168.168.36: icmp_req=4 ttl=255 time=8377 ms
64 bytes from 192.168.168.36: icmp_req=5 ttl=255 time=7377 ms
64 bytes from 192.168.168.36: icmp_req=6 ttl=255 time=6377 ms
64 bytes from 192.168.168.36: icmp_req=7 ttl=255 time=5377 ms
64 bytes from 192.168.168.36: icmp_req=8 ttl=255 time=4380 ms
64 bytes from 192.168.168.36: icmp_req=9 ttl=255 time=3370 ms
64 bytes from 192.168.168.36: icmp_req=10 ttl=255 time=2370 ms
64 bytes from 192.168.168.36: icmp_req=11 ttl=255 time=1360 ms
64 bytes from 192.168.168.36: icmp_req=12 ttl=255 time=359 msAs you can see the latency is extremely long. The unresponsive aspect of the WiFi connection probably explains why HomeKit connectivity is largely craps shoot. If I was August, it was probably premature to market this product as WiFi capable, should have waited for or designed for better reliability.
In conclusion, the lock works fine with the App and mostly work with HomeKit (70/30 chance). I find that it works better with HomeKit if you are in close proximity with the lock and your iOS device. Can you lock/unlock when you are around the world? Once again, it mostly works depending on the connectivity, but I would not depend on it for emergencies.
