Is there a way to improve node health for Kwikset lock?

Hi All,

I have a Kwikset lock on my detached workshop which does not seem to work very reliably. It is about 25’ away from my back door, which itself has a Kwikset lock and has 3 Leviton switches installed right beside it. Just inside the workshop door are another 3 Leviton switches, and a Wayne Dalton thermostat. My hope was that at least some of these should be helping to relay messages around. I should also note that the thermostat and all three lights in the shop work very quickly and reliably.

I tried running a heal just against the workshop door lock, and it looks like it can see lots of neighbors, but the stress test seems pretty bad if I am interpreting things correctly. Any ideas on what might be wrong or what I can do? I am running the latest 1245 with 3.20 z-wave firmware and have mios routine enabled.

Thanks in advance… am finally doing pretty well with Vera/z-wave if I could get this issue licked!

Here is the heal report:

11-04-25 16:14:12 report for HealNetwork. Successful: Y Updated net: N mr_only:0 Job ID: job#1708 :heal network (0x75e5d0) P:71 S:5

=======NEIGHBOR NODE UPDATES=======
Node 35 Device 38 Workshop Side Door neighbor nodes updated 0 times (incomplete 1 in a row 0), woke up 0 times configured: YES

=======STRESS TEST RESULT=======
Node 35 Device 38 Workshop Side Door
Test: NOP Sent 2 test frames and 2 succeeded (100%) with average of 10.071112 seconds and maximum of 11.666750 seconds
Test: Basic_Get Sent 2 test frames and 0 succeeded (0%) with average of 0.000000 seconds and maximum of 0.000000 seconds
Test: Secure Sent 2 test frames and 0 succeeded (0%) with average of 0.000000 seconds and maximum of 0.000000 seconds
Test: Get Node Info Sent 2 test frames and 2 succeeded (100%) with average of 7.528903 seconds and maximum of 13.748858 seconds
–HEALTH SCORE: 1–

=======NEIGHBOR NODE RESULT=======
Node 35 Device 38 Workshop Side Door took 0.28091000 seconds to report neighbors: 1,4,15,20,22,23,26,27,28,29,31,

Inversely:
Node 35 Device 38 Workshop Side Door is seen by: 1,4,15,20,22,23,26,27,28,29,31,

=======EDGE NODE PROFILE=======

=======DETAILED LOG=======
–Stage #1 started: 11-04-25 16:14:12 completed: 11-04-25 16:14:12 successful: N
—11-04-25 16:05:44 Job unknown
–Stage #2 started: 11-04-25 16:05:44 completed: 11-04-25 16:14:12 successful: Y
—11-04-25 16:05:44 Pass 0/5 Updating neighbors for node 35
—11-04-25 16:06:36 Job job#1709 :heal_neighbor_node 35 (0x851f10) P:70 S:4 was Successful
—11-04-25 16:06:36 Neighbor Update Done
–Stage #3 started: 11-04-25 16:06:36 completed: 11-04-25 16:14:12 successful: Y
—11-04-25 16:06:36 Routing update node 35
—11-04-25 16:06:36 Job job#1710 :heal_routing_node 35 (0x76ec98) P:70 S:4 was Successful
—11-04-25 16:06:36 Routing update done
–Stage #4 started: 11-04-25 16:14:12 completed: 11-04-25 16:14:12 successful: Y
—11-04-25 16:11:08 Calculate Routes Done
–Stage #6 started: 11-04-25 16:14:12 completed: 11-04-25 16:14:12 successful: Y
—11-04-25 16:11:08 No battery nodes
–Stage #7 started: 11-04-25 16:11:08 completed: 11-04-25 16:14:12 successful: Y
—11-04-25 16:12:45 Node Details heal 35
—11-04-25 16:13:58 Node Details heal 35
—11-04-25 16:14:12 Stress test Done

How many heals have you performed? I would suggest you do at least three.

JOD.

@JOD, remind me if things have changed, but it used to be that Leviton switches wouldn’t relay a secure classes message. In the old days we had to use Schlage lamp modules as the last hop before a lock because they could talk to both Vera and the lock securely.

Ah, interesting… maybe it is something to do with the secure classes! Anybody know of a list of modules that would relay? Or perhaps the newest Leviton controllers (-MR)?

I know the older Levitons do not support beaming but some of the newer ones do. In this case, I think several heal networks (not just a heal node) will setup the routing to this device, maybe even directly since the other devices are beyond the lock.

JOD.

How does one tell which Levitons support beaming? I know the upcoming VRC0P (released this month) supports beaming, but how about the Leviton Vizia RF + switches and dimmers?

Thanks.

No other Leviton devices at this time support it. At some point updated VRP03 and VRP15 modules will be released that support beaming.

I had the exact same problem with one of my Kwikset locks 2 weeks ago and sent in a trouble ticket for it. MCV responded that the lock was failing to communicate secure classes and suggested I place a beaming device somewhere in between Vera and the lock. I asked them for recommendation and they referee me to their wiki. http://docs2.mios.com/doc.php?page=door_locks

Then in a follow-up message, they sent me this paragraph:
4) Schlage locks work with Zensys’ “Zensor Net Technology” which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of “Zensor Net Beam” (ZNB). Many newer Z-Wave devices support Beaming, including:
I)any GE/Jasco lamp modules/switches with the following versions:
2.0a
3.0a
2.0b
3.0b
NOT 2, 2.0, 3, or 3.0
II) the Homepro ZDP100 lamp module (must be firmware version 3.3 or later). Also, after you’ve added lamp modules, you must do a Heal Network before they will effectively act as relays. Heal Network will also give you a report to confirm that Vera can talk to all your Z-Wave devices
III) and the Schlage RP200 light module.

Trying to find info on firmware versions and beaming support for devices is a real challenge. I wound up using a Cooper Aspire RF Dimmer Master module -pricey!, for a light in the same room (basement) and have now succeeded in controlling the lock, although not in getting event notifications.

Does anyone know if the Trane/Schlage thermostats support beaming? I’m interested in improving signal strength for my kwikset locks.

I’m looking to get the Kwikset lock. Let’s suppose that the lock is more than one node away from my Vera 2. For example, for the Vera to communicate with the lock, it has to go through two other nodes: Vera->Node A->Node B->Lock. Do both intermediate nodes (Node A and Node B) have to support beaming? Or is it okay if only Node B supports beaming but Node A does not?

Thanks.

AFAIK, only the node closest to the lock.

Great. Otherwise, it would complicate setting up the Z-Wave network.

Thanks.

One other hypothetical question (I’m about to setup my Z-wave network in a few days, so trying to design things properly)…

Suppose that my Vera needs to communicate with a Kwikset lock and has to “hop” through 1 node. Suppose there are two nodes, Node A and Node B that are more or less “equidistant” from the Vera and the lock. Node A does not support beaming. Node B supports beaming. So, ideally, I want the routing to go from Vera->Node B->lock. Would the Z-wave protocol favor using Vera->Node B->lock, or might it incorrectly use Vera->Node A->lock? Or, is my only option to ensure that Node B is used to physically move it to ensure that it is used as the hop?

Thanks.

Right. So I certainly have the same expectation as you, and my understanding is it works that way, but it’s all subject to interpretation; I have not actually seen this work that way.

Again, I have the same expectation and my understanding is the routing is smart in that sense. Not sure if the manual routing that currently comes with .1245 / 3.20 messes that up, is equally smart, or smarter.

@ASIHome may have some detail.

[quote=“randman, post:14, topic:168212”]One other hypothetical question (I’m about to setup my Z-wave network in a few days, so trying to design things properly)…

Suppose that my Vera needs to communicate with a Kwikset lock and has to “hop” through 1 node. Suppose there are two nodes, Node A and Node B that are more or less “equidistant” from the Vera and the lock. Node A does not support beaming. Node B supports beaming. So, ideally, I want the routing to go from Vera->Node B->lock. Would the Z-wave protocol favor using Vera->Node B->lock, or might it incorrectly use Vera->Node A->lock? Or, is my only option to ensure that Node B is used to physically move it to ensure that it is used as the hop?

Thanks.[/quote]
I have the same question and could not find any information at all to support that the routing is that smart, anyone?

Both would have to support beaming becuase there is no way to force a specific route yet.

That would be a pain if one had to figure out what route is being taken and have to replace non-beaming Nodes with beaming nodes…

If a network’s switches & dimmers don’t support beaming, and the Vera is too far from the lock, then merely adding a beaming plug-in closer to the lock than any other node is not necessarily a guarantee that the plug-in would be used as the hop between the Vera and the lock? For example, the route might instead use a node closer to the Vera and further away from the beaming plug-in as the intermediate hop (and this intermediate node might not necessarily support beaming)? Or maybe I’m thinking of this the wrong way and all communications are broadcast to all Nodes, and the actual route taken is whatever reaches the target Node (e.g. the lock) first (and so the lock won’t get the beam from the non-beaming nodes but will eventually get the beam from the beaming plug-in)?

Sorry for all the questions… I did an online search for z-wave beaming, and didn’t see anything in detail about how it actually works, so this topic is somewhat interesting, given that I plan to get a lock soon.

Thanks.

I just added a Schlage plugin dimmer module that supports beaming to my network, and it didn’t help. It is certainly within direct reach of Vera and the lock, but I guess the route wants to follow another non-beaming hop or something. I’d be curious to know if anybody has beaming working. It seems like the vast majority of people have at least their locks if not all their devices in direct reach to Vera.

Try another heal if you haven’t done so already. In heal report look at the route that Vera is attempting to the lock. I think it is in the EDGE section of the report. See what nodes are being used as hops from the Vera to the lock. If they are non-beaming, I wonder if it will help if you relocate the Schlage plugin near those nodes to see if Vera might try to decide to use it instead. You may need to move the Schlage around until Vera finally decides to use it. In my home, my Vera can reach my 4 Z-Wave locks, but 2 of them are borderline reachable and from heal report I can see that a thermostat, which supports beaming and secure classes is used as a hop (successfully) I have 2 Schlage RP200 plugins and they are the first not too stable versions that supported secure classes. Dont know if the old firmware version would hurt, but fortunately I haven’t needed them as hops to my locks.