August lock revisited

[tmorse305]

I have been an Insteon user for a very long time but recently wanted to add a lock to my home automation.  I chose the August Lock Pro which includes a plug-in wall module that allows the lock to connect with the internet.  The lock also supports IFTTT.  The lock itself has a bluetooth and z-wave radio inside.  It uses bluetooth to talk to the wall module and the smart phone app locally.

So this is my first outing with z-wave and I thought I would share my experience.  I know there are a lot of z-wave users out there who swear by it so I'm hoping that they will help to correct my novice observations.

I ordered the z-wave module for my ISY and 2 JASCO Z-Wave Plus Smart Plugs to use with the lock.  I installed the lock and put the 2 plugs in between my ISY and the lock.  I placed one plug very near the ISY as that is what I’ve seen recommended on this forum, and roughly split the distance to the lock with the other plug.  The straight line distance between the lock and the ISY is about 28 ft with a couple of walls in between.

I joined everything to the ISY, healed the network, and it worked, at least at first.  When the lock joins the network 2 nodes appear in ISY for some reason.  Both show the lock status, in addition the first node shows the battery status.  Both can lock and unlock the lock.

The trouble started soon after with the lock status on ISY not agreeing with the actual lock status.  At times the 2 nodes would not agree, one would be locked the other unlocked.  The first node could be queried and corrected, but the 2^nd node would not correct with the query.  I tried moving the plugs to different locations, I even deleted everything and started over but nothing helped.  Finally, I created a network with just the lock and ISY and moved the ISY to within a few feet of the lock.   This configuration worked for at an entire day, I didn’t test it any longer but concluded the issue must be with my limited mesh.  But given the relative short distances it seemed like I should have enough repeaters to get the job done.

So I bought a ZwaveProducts Toolbox ($149) (https://www.zwaveproducts.com/) to help understand what was happening.  There are a bunch of tools but I primary used 4:

Spectrum analyzer to rule of interference

Map to understand the z-wave network

Repeater Finder to measure signal strength

Packet Analyzer to see how the commands move through the network

 

The spectrum analyzer ruled out any steady sources of interference, there still could be an intermittent one although I don’t have anything else in my home operating at 908.4 Mhz and 916 Mhz, and I’m in a rural setting.

Using these tools and available outlets in my house this was the best map I could come up with:

Note despite multiple attempts to heal the network, Plug 10 and ISY were never identified as neighbors, even though the signal strength is comparable to the lock.  That’s why the line is dashed.

Using the Repeater Finder tool I went to each node and measured the signal strength of the distant nodes.  The values in dBm are shown on the map.  For example the signal strength of the lock from the ISY perspective is -62dBm.  The signal strength of the ISY from the lock perspective is -58dBm.  As a point of reference, the signal strength with the toolbox right on top of any of the devices was  -30 to -25dBm.

As you can see from the map the most robust path from the lock to ISY is using both plugs to repeat the commands.

I switched to the packet analyzer to see what was actually happening.  To my surprise the lock was communicating with ISY directly.  Everything stayed in sync with multiple locks and unlocks, always using the Lock to ISY link.  I did however notice that occasionally the lock repeated the initial command to ISY indicating the first one was not received correctly, ISY did not acknowledge it.  I finally got it to change the path when I unlocked and fully opened the door changing the lock location relative to the neighbors.  This time the path was through Plug 7.  Once the path changed it stayed through plug 7 over many lock cycles until there was a failure of plug 7 to communicate with the lock.  Then it switched back to the direct connection lock to ISY.  I have been experimenting with this for a few days and so far it has never tried the path through plug 10 and 7 which I believe to be the best route.  The other observation was that there were more packet errors reported and ISY/Lock sync issues when using the non-direct path. 

There is another aspect of the lock which makes it more susceptible to communication problems.  When ISY commands a plug to turn on, there are 3 commands are exchanged and 3 acknowledgements.  When ISY commands the lock to engage the lock, 16 commands are exchanged and each one is acknowledged.  The opportunity for an error increases sharply.    Only 9 commands are exchanged when the lock initiates the lock sequence but that’s still 3x what is needed for a plug.

I'm beginning to see how the ISY and lock can get out of sync and how the 2 nodes within ISY can get out of sync.  The question is what to do about it.  I could add even more repeaters but I’m actually not sure that would help.  I already have a really good communication path from lock to ISY but it’s not being utilized.

I’m opened to any suggestions you might have, thanks for taking to the time to read a long post.

 

 

[madcodger]

I don’t have a solution, but to this point I am thinking I will not connect my August locks to either the ISY or, in another building, Homeseer. I own three August locks (and had a fourth in another property we just sold). While I find them handy, at least twice each year we have a problem that requires us to manually unlock the door. We even resorted to installing a locked keybox on the outside of each building so that if the August lock is completely dead we - or someone else who needs access, such as an employee or service person - can get in when we’re not close by (they call us, or a few key people have the lockbox code).

Bottom line: Pretty much any home automation is still a toy rather than a reliable device such as a security system with access controls, and I find the August lock chief among those. And fwiw, the connect wifi device and their keypad are even worse than the lock itself. Please, don’t rely solely on anything from August, and have a decent backup solution.

 

[lilyoyo1]

On 10/6/2019 at 10:43 PM, tmorse305 said:

I have been an Insteon user for a very long time but recently wanted to add a lock to my home automation.  I chose the August Lock Pro which includes a plug-in wall module that allows the lock to connect with the internet.  The lock also supports IFTTT.  The lock itself has a bluetooth and z-wave radio inside.  It uses bluetooth to talk to the wall module and the smart phone app locally.

So this is my first outing with z-wave and I thought I would share my experience.  I know there are a lot of z-wave users out there who swear by it so I'm hoping that they will help to correct my novice observations.

I ordered the z-wave module for my ISY and 2 JASCO Z-Wave Plus Smart Plugs to use with the lock.  I installed the lock and put the 2 plugs in between my ISY and the lock.  I placed one plug very near the ISY as that is what I’ve seen recommended on this forum, and roughly split the distance to the lock with the other plug.  The straight line distance between the lock and the ISY is about 28 ft with a couple of walls in between.

I joined everything to the ISY, healed the network, and it worked, at least at first.  When the lock joins the network 2 nodes appear in ISY for some reason.  Both show the lock status, in addition the first node shows the battery status.  Both can lock and unlock the lock.

The trouble started soon after with the lock status on ISY not agreeing with the actual lock status.  At times the 2 nodes would not agree, one would be locked the other unlocked.  The first node could be queried and corrected, but the 2^nd node would not correct with the query.  I tried moving the plugs to different locations, I even deleted everything and started over but nothing helped.  Finally, I created a network with just the lock and ISY and moved the ISY to within a few feet of the lock.   This configuration worked for at an entire day, I didn’t test it any longer but concluded the issue must be with my limited mesh.  But given the relative short distances it seemed like I should have enough repeaters to get the job done.

So I bought a ZwaveProducts Toolbox ($149) (https://www.zwaveproducts.com/) to help understand what was happening.  There are a bunch of tools but I primary used 4:

Spectrum analyzer to rule of interference

Map to understand the z-wave network

Repeater Finder to measure signal strength

Packet Analyzer to see how the commands move through the network

 

The spectrum analyzer ruled out any steady sources of interference, there still could be an intermittent one although I don’t have anything else in my home operating at 908.4 Mhz and 916 Mhz, and I’m in a rural setting.

Using these tools and available outlets in my house this was the best map I could come up with:

Note despite multiple attempts to heal the network, Plug 10 and ISY were never identified as neighbors, even though the signal strength is comparable to the lock.  That’s why the line is dashed.

Using the Repeater Finder tool I went to each node and measured the signal strength of the distant nodes.  The values in dBm are shown on the map.  For example the signal strength of the lock from the ISY perspective is -62dBm.  The signal strength of the ISY from the lock perspective is -58dBm.  As a point of reference, the signal strength with the toolbox right on top of any of the devices was  -30 to -25dBm.

As you can see from the map the most robust path from the lock to ISY is using both plugs to repeat the commands.

I switched to the packet analyzer to see what was actually happening.  To my surprise the lock was communicating with ISY directly.  Everything stayed in sync with multiple locks and unlocks, always using the Lock to ISY link.  I did however notice that occasionally the lock repeated the initial command to ISY indicating the first one was not received correctly, ISY did not acknowledge it.  I finally got it to change the path when I unlocked and fully opened the door changing the lock location relative to the neighbors.  This time the path was through Plug 7.  Once the path changed it stayed through plug 7 over many lock cycles until there was a failure of plug 7 to communicate with the lock.  Then it switched back to the direct connection lock to ISY.  I have been experimenting with this for a few days and so far it has never tried the path through plug 10 and 7 which I believe to be the best route.  The other observation was that there were more packet errors reported and ISY/Lock sync issues when using the non-direct path. 

There is another aspect of the lock which makes it more susceptible to communication problems.  When ISY commands a plug to turn on, there are 3 commands are exchanged and 3 acknowledgements.  When ISY commands the lock to engage the lock, 16 commands are exchanged and each one is acknowledged.  The opportunity for an error increases sharply.    Only 9 commands are exchanged when the lock initiates the lock sequence but that’s still 3x what is needed for a plug.

I'm beginning to see how the ISY and lock can get out of sync and how the 2 nodes within ISY can get out of sync.  The question is what to do about it.  I could add even more repeaters but I’m actually not sure that would help.  I already have a really good communication path from lock to ISY but it’s not being utilized.

I’m opened to any suggestions you might have, thanks for taking to the time to read a long post.

 

 

It sounds counter intuitive but controllers talking directly to a lock is probably the worse thing you can do. I say this because controllers have other devices that they need to talk to.  This can interfere with their ability to talk to your locks in a timely manner.

A device that supports beaming can hold the message and send it at the proper time. It's sort of like a boss having 50 things to do at once. If he tries to handle it all something can get left out. However, by offloading some of his work to other people, more can get done. 

While August has a reputation for bring finicky, I suspect this may be part of your problem. It's partly why I make sure why controllers are nowhere near my locks. I want to ensure they have to go through a repeater. 

[lilyoyo1]

13 hours ago, madcodger said:

I don’t have a solution, but to this point I am thinking I will not connect my August locks to either the ISY or, in another building, Homeseer. I own three August locks (and had a fourth in another property we just sold). While I find them handy, at least twice each year we have a problem that requires us to manually unlock the door. We even resorted to installing a locked keybox on the outside of each building so that if the August lock is completely dead we - or someone else who needs access, such as an employee or service person - can get in when we’re not close by (they call us, or a few key people have the lockbox code).

Bottom line: Pretty much any home automation is still a toy rather than a reliable device such as a security system with access controls, and I find the August lock chief among those. And fwiw, the connect wifi device and their keypad are even worse than the lock itself. Please, don’t rely solely on anything from August, and have a decent backup solution.

 

Comparing automation to a proper security system is like composing apples to oranges. They are far from being the same for many reasons. 

Not only that, a true professional grade alarm system is in a whole different ballpark than the isy. This is why an elk board costs 500 bucks by itself and the isy is 150.

That is in addition to the fact that the isy, homeseer and others are dyi systems. Many people don't take the time to learn the ins and outs about the technologies that they are using so they end up with suboptimal installations and question why they get suboptimal results. At that point we all know who they blame.

A team of professionals (who know their job. Not all installers are good), will properly survey the home to ensure they have what they need to complete the install without fail. The avg person. Not so much. 

There's more but that's the condensed version. When I think about it is less apples to oranges and more apples to beef

[tmorse305]

21 hours ago, lilyoyo1 said:

It sounds counter intuitive but controllers talking directly to a lock is probably the worse they you can do. I say this because controllers have other devices that they need to talk to.  This can interfere with their ability to talk to your locks in a timely manner.

A device that supports beaming can hold the message and send it at the proper time. It's sort of like a boss having 50 things to do at once. If he tries to handle it all something can get left out. However, by offloading some of his work to other people, more can get done. 

While August has a reputation for bring finicky, I suspect this may be okay of your problem. It's partly why I make sure why controllers are nowhere near my locks. I want to ensure they have to go through a repeater. 

Thanks lilyoyo1.  You're right it is counter intuitive but I see your logic.  In my case the only thing ISY has to do is talk to the lock, at least on the z-wave side of things.  The plugs are just there as repeaters.  The double node cannot be helping matters either.  It is curious that the double node shows up inside ISY but the z-wave map only shows one.  If anyone has experience using August locks with a different controller I'd be curious if it shows up as a double node on an non-ISY controller.