Here is the signature for the Z-wave toolbox if you want to add it to Hubitat:
1 Like
That is exactly what I need to figure my stupids lock issues out. Does it work as well as the website vid shows?
I doubt it will work for locks. Since Hubitat doesn't support Secondary controllers, it won't send the secure keys to the stick. I have a Zstick paired to HE and I can see and control most of my devices from the stick, but none of the secure connected devices.
Still learning the ins and outs of the tool (as time allows). I have had a few issues so far and am working on resolving them.
Not officially.. But I have a secondary controller (test device) added to my hub.. It is able to see all my devices
You are seeing and can control secure devices? I will have to try removing and adding my stick again.
Would it still show routing and connection stats? Really all I need not the codes. I have a z-wave switch right next to my lock but they still don't lock 50% of the time. Trying to figure out where the disconnect is.
I use OpenZwave Control Panel on a Linux computer to gather the neighbor tables and hop counts for devices. It works well for seeing more about how your Zwave network functions. I am just using an Aeon Zstick.
As a suggestion, you should try a beaming capable device close to the HE hub. That can forward lock, unlock messages to the network.
Device 1 is my Hubitat
Device 23 is my Keywe Front door lock
Device 12 is a Zooz Zen15 connected to my bathroom heater
Device 9 is a Zooz Zen15 connected to my bedroom heater
Here's a small portion of the packet analyzer from the Z-wave Toolbox
So while I can't see the contents of the packet, it is providing some useful data.
2 Likes
Interesting!
What I find interesting is that the 'Front door range extender' (Aeotec Range Extender 6) which is mounted 3-4 feet from the Keywe front door lock and is only 10-12 feet from the Hubitat (all within the same room) is not being used to communicate despite having direct connections to both the hub and the lock.
Instead it's being routed through devices in 2 other rooms requiring penetrating 2 (to the bathroom) and 3 (to the bedroom) walls and are significantly further away too.
The wonders of automatic route determination. There is a piece of data somewhere that made it decide to do that (it isn't random, its an algorithm). Hard to tell what sometimes though.
3 Likes
4 hop limit.
Therefore, it wants to pick routers that are the furthest away so as to build the biggest 'sphere.'
Imagine you have an out building.. you can only reach it if the furthest device in 'this building' can reach the closest device in the out building. The hub can't know that you will or won't be adding devices tomorrow that need a bigger sphere. It builds the biggest it can today... allowing tomorrow to take care of itself. 
2 Likes
So how do these devices know their physical placement with regards to each other (how do they know how far the out building is....???)? I don't see anything (obvious) that includes geography in the protocol.
Z-Wave routing is actually quite simplistic..
The controller builds the routing table, and it knows the entire routing table, which is purely 2-dimensional; it can even be exported to a spreadsheet.
| Controller | Device A | Device B | Device C | Device D | |
|---|---|---|---|---|---|
| Controller | * | Y | Y | ||
| Device A | Y | * | Y | ||
| Device B | Y | * | Y | ||
| Device C | Y | * | Y | ||
| Device D | Y | Y | * |
Since the controller knows the route to every device in the mesh it will prioritize by the fewest hops required to deliver a message. The controller will always prioritize direct routes first; then 1 hop, 2, 3 and so on. It doesn't need to know distance to build out a distant mesh.
When the controller runs a z-wave repair, it first looks for devices within radio range.. It adds those to it's routing table.. It then asks each of those devices to scan for any devices within its' radio range. The devices report its' neighbor devices back to the controller, and the controller adds those to its' routing table. For any new devices discovered during this second pass, the controller queries them for neighbors and repeats that process.. Up to 4 times, which is the 4 hop limit.
Using the mini-routing table example above..
Device A and Device C both communicate directly with the controller.
Device B routes through A, then to the Controller
Device D routes through C, then to the Controller.
Device B routes through C, the to the Controller
In this scenario, the hub will always communicate directly with A & C..
D has no options but to route through C then to the controller, while B can go through A or C...
So by the very fact Z-Wave controller can "walk" the network up to 4 hops out, starting with the closest, and ending with the furthest (in terms of hops) gives it the data necessary for calculating the shortest path possible for a device, without the need for any geographical data.
7 Likes
That makes sense, as it is purely determined by link signal quality and hop count. There is no physical/spatial coverage known or conveyed in the routing process.
3 Likes
If you have a reference that points to that as the way Z-wave works, I'd appreciate a link. From what I understand, The hub will attempt to route directly to the device if it's a single hop to it. If not, then the hub will use 2 stored tables to determine the route to use. The first is the 'most used node list' which is a list of nodes that they hub has been able to contact directly and ranked by how often the hub has been able to reach them.
What I am unsure about with the 'most used node list' is if commands sent to the node (i.e. the Zen15 switch) are counted in the ranking.
The second table used is the 'preferred repeater list' which is a list of nodes that use smallest group of nodes necessary to reach all nodes in a single hop.
From there the hub will calculate the shortest route to the destination device.
Again, I am unsure how the actual calculation is performed.
What throws a monkey wrench into my example above is that the destination lock is a FLiRS device (Frequently Listening Receiver Slave). So basically the lock sleeps and partially wakes up every second (actually variable from 1 up to 4 times per second based on the manufacturer setting) to see if there is a beam command pending. If there is, it fully wakes up the lock.
Again, how the route is calculated to the appropriate beaming-capable repeater for the FLiRS device target is still FM (freaking magic) to me.
1 Like
I already addressed the answer to this in my previous post.
That’s how Z-Wave maximizes distance.
Thats the point of the table. It’s a prioritized table based on the number of successful messages delivered to the node.
Z-Wave is the simplest of the source routing protocols... There’s not a lot of complexity to it.. The routing table is built upon the results of a simple search by looking for nodes within radio range.. It then extends that search 3 more hops out. Those tables are then calculated based on the results of that search.
Unlike Zigbee which constantly adjusts routes, Z-Wave does not. The routing table is fixed, and only these two “helper” tables are updated. New routes cannot be added, and a bad route cannot be removed. This is why it’s easy for a bad Z-Wave repeater to do a lot of damage to a mesh.
1 Like
Steve,
I did read though your earlier post (twice) to make sure it jived with my current understanding of Z-wave. What threw me for a loop is that the route taken to my front door lock went through two hops using the two Zen15 rather than using the Aeotech range extender (or another route) that would only require one hop.
From that statement, it shouldn't have used a 2 hop route. So I ran a Z-wave repair this morning and now the route from the Hub to the lock only uses one hop... through the Aeotec Range Extender 6 right beside the front door.
So an extremity chatty device (i.e. reporting a lot of data) getting a bunch of ACKs or a device that's used more often (switched on by rules) get their priority bumped up in the most used nodes list?
Now the next thing I have to figure out is how to get rid of the "ghost devices" (Dev 46-50) created by including Z-wave Toolbox and it failing to properly connect (never getting data from the Z-wave network). I did attempt a Z-wave exclusion each time, but some of them ended up being forced exclusions. One trick I used was connecting the Z-wave Toolbox to another Hubitat with only one device currently on it, exclude it, and then it connected to my production hub no problem. No idea why. More FM!
As I mentioned , I did a Z-wave rebuild on the production Hubitat very early this morning and was hoping that the 2am maintenance would address the ghosts. From what I've read elsewhere in the community, I may have to use another tool to remove them.
Help me out here. I think I follow how the z-wave routing table is rebuilt after a z-wave repair. But what happens to devices that Hubitat doesn't query while rebuilding the table (like battery-powered sensors/locks).
Is the route to those devices remain whatever route was taken when they were first paired? If this is true, does it make sense to unpair/re-pair "sometimes" unresponsive battery-powered devices once a complete/robust mesh of powered repeating devices has been built?
Thanks!
2 Likes
