I'm assuming last sent and last received on the Repair page are valid since they are populated in my test with actual date\time when these 2 test devices were connected directly to the hub. That along with event times is what I'm drawing my conclusion that these devices are not acting as repeaters.
I'll do another test now that @vjv has pointed out the issue of pairing in place but in previous attempts these device would not pair while only close to these repeaters.
After first removing a Zooz 4-in-1 from my system I tired repairing in the are where it would be placed which has 2 of the 3210-Ls and that was a no go.
Now that @srwhite has added a bunch of these 3210-Ls to his Hubitat system he might be able to tell us a definitive answer for how these units perform as zwave repeaters.
There's no question that these work as Z-Wave repeaters. I cannot say if they're better or worse than other alternatives, but they do work. I make a point of keeping one within a few feet of every lock, despite having GE switches nearby as well.
I have not yet mapped out my Hubitat Z-Wave network, but I did in SmartThings and they all were showing in the Z-Wave routing table. I've not had any Z-Wave performance issues since Hubitat released the update to remove ghost devices from the routing table.
I did a ZWave repair on Sunday evening and indeed, all my devices, including Battery devices showed in the logs... what they didn't do is 'finish.'
Node 8: Repair starting
Node 16: Repair starting
Node 18: Repair starting
Node 20: Repair starting
Node 22: Repair starting
Node 23: Repair starting
Node 24: Repair starting - bat
Node 25: Repair starting - bat
Node 27: Repair starting
Node 28: Repair starting - bat
Node 29: Repair starting - bat
Node 30: Repair starting
Node 32: Repair starting
Node 33: Repair starting
Node 34: Repair starting
Node 35: Repair starting
Node 36: Repair starting
Node 38: Repair starting
Node 39: Repair starting
Node 40: Repair starting
Node 42: Repair starting
Node 43: Repair starting
When ZWave repair is complete, I find the following messages:
Node 8: Repair is done.
Node 16: Repair is done.
Node 18: Repair is done.
Node 20: Repair is done.
Node 22: Repair is done.
Node 23: Repair is done.
Node 27: Repair is done.
Node 30: Repair is done.
Node 32: Repair is done.
Node 33: Repair is done.
Node 34: Repair is done.
Node 35: Repair is done.
Node 36: Repair is done.
Node 38: Repair is done.
Node 39: Repair is done.
Node 40: Repair is done.
Node 42: Repair is done.
Node 43: Repair is done.
I see that battery devices trying multiple times at the intermediate points of the repair:
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 24: Repair setting SUC route
Node 25: Repair setting SUC route
Node 25: Repair setting SUC route
Node 25: Repair setting SUC route
Node 25: Repair setting SUC route
Mine show up in the routing table but when they are the only zwave repeater available to a battery powered device they do not repeat and they will not allow any of the battery powered zwave devices I own to pair when those devices are outside of the hub signal.
First off, I've just released a port of my Iris Z-Wave Repeater driver. Give that a shot as that will tell you if the devices are able to communicate.
I do not believe Hubitat supports network wide inclusion (NWI) so I'm not surprised that battery powered devices do not pair through them. Any device that requires secure inclusion has to be in direct range of the hub.
I will say from experience that the radios in these plugs aren't super strong. Now that I have 3-6 in every room I don't notice that anymore.
I haven't found that to be true, unless the Hub's radios are exceptionally strong. 
I have two Secure devices, a Yale door lock and a Linear/GoControl Garage Door opener. Neither would securely pair close to the Hub. I accidentally was able to have them Join securely, as a result of giving up.
I had given up on those two devices and moved on to join devices in the vicinity. There's a Qubino Flush2 relay and a Leviton wall switch and a GE wall switch and both an Aeon SmartSwitch 6 and a Dome On Off switch, all within 'arms reach' (imagining my arms could go through walls.)
I migrated all those devices and more out in the garage, and then one of the last devices was the Recessed Door sensor. Battery driven so it was last, hoping the mesh had formed. Since I was standing there, Aeon ZStick in one hand (for exclusions) and iPad in the other (for inclusions) I decided to just try the Door lock again. Bingo, first try it joined. Then I thought, cool... before the moon shifts, I'll try the Garage Door Opener. It's 35' further from the hub than the Lock. It too paired first try. I've since decided that it was the result of migrating the specific device that supported Beaming.
As you probably know, ZWave repeater algorithm picks devices further vs nearer. This is to build out the physically largest 'sphere' of radio coverage. While I had beam capable devices already migrated and physically closer to the lock, evidence suggests it wasn't using them. Probably the GE, just outside the door, inside the garage was 'further' than the Qubino and so it got picked.
I really don't have that many....
Oh boy have I.. I solved it with splitting everything onto 2 hubs, including locks... Each hub is located no more than 30 feet from any of my locks so I was able to pair them in place. However, before that? Had to move the hub all over the house.
You're shackrat ! I loved that DH on ST, was really missing it on HE. Thanks for porting that Z-Wave repeater driver
I'm really grateful you'll be hanging around. Your disasters have produced some great strides in debugging & fixing zigbee.
What's that saying- "no pain no gain", again very grateful you and the family are safe, and not making light of your personal "hell"
EDIT- I'm renaming this driver as the "Reincarnator", it brought back 2 3210-L plugs that were dead for a month, without a zwave repair.
Actually considering it gets devices to do things after sitting idle for a month, maybe a better name is the ............
"WIFEY"
So, here's the results of a fresh Zwave repair and I'll focus on just a single device that is sitting 6 feet from a new C5 hub.
And here's what I see for that device after Test Communications.
Thoughts @srwhite
Edit to add this additional info from you quite nice driver. Many thanks for that effort.
That's me.. lol. It was my old CB handle from my days working at Radio Shack in the late 80's-early 90's.
Fortunately, we can now laugh at the events of a few weeks ago. That is, until the credit card bill comes for the replacement furnace.... My Hubitat build is starting to really run smoothly so it looks like I'll be sticking around for a while.
Glad you enjoyed the DTH. It's been on my to-do list to release for a while now which I'm finally starting to get caught up on. Thanks for the feedback!
That's to be expected. I've updated my original post.
Hubitat doesn't yet support the Power Level Node Test command class which is a Z-Wave Plus extension.
What it does is allow the sender to transmit a predetermined number of test frames, at a specific transmit power, to a node which in turn echoes it back to the sender. In simplistic terms, it is the Z-Wave Plus equivalent of an ICMP ping.
Hubitat doesn't support that command class at the moment so the command will always fail. I've left the function in the driver so it's ready when and if they add support for that test. Until that its supported, the interrogate device is the closest to a real communication test that we can do.
Lol, mine was Raider or "the unit 725". Early 90's too. I was at PR in that time and on CB I talked with people from Maine!
But all those "repair starting" or "repair is done" were together? Or you just put them like that? I don't know if in the latest firmware something was changed but I never seen a battery device in a repair. I will run a repair now because your fault....
So, if these are the only zwave repeaters on the system and other battery powered zwave devices are not found in the system what does that say?
no, I took the live logs and sliced it to understand what was occurring. I sliced off all the text to the left of what you see then sorted it to allow me to "count" how many of each step started and completed.
Therefore, I know that 29 started and 18 finished. 11 battery devices.. statistics like that. (Whatever the real numbers were.. )
It really doesn't say anything conclusive, only that the Monoprice/Zooz (same thing) sensors may not like to use them as repeaters. But that's all it really says.
You mention that they don't work after moving them away from the hub. But have you run a Z-Wave repair, after moving them to their final location? A Z-Wave repair basically walks the entire network, asking every routing capable device for a list of all nodes within range which gets returned to the hub to build the routing table. With the exception of Z-Wave plus devices that support explorer frames, most Z-Wave devices cannot simply be moved around without doing a repair afterward.
That said, another possibility exists in that there is something in the firmware of those Zooz devices that causes them to not route through repeaters in the Iris plugs. We know that the Iris plugs repeat Z-Wave just fine as they have been the cornerstone of the Iris system for 4 years. The Zooz devices were never approved by Lowes, so one cannot discount the possibility that these devices do not play well with the Iris repeaters.
Yes I did a z-wave repair after they were in place, more times than I'd like to remember at this point.
The only z-wave devices I've found that are repeating in this basic setup are these devices made by Intertek for Monoprice and Zooz. They are found at pairing as Zooz Power Switches. Unfortunately they don't always report their accurate state even though they are z-wave plus.
I've tried using one of the new Zooz Zen25 double plugs as a repeater and it does not repeat.
It would be nice to rule the new C5 hub out as part of the issue since it is a different z-wave radio setup.
Could you confirm the node numbers with the list under settings>z wave? I did the repair and no battery devices were showed on the repair logs, only the powered. What device is node 24?
024 (18) 100 258 in: 0x5E, 0x86, 0x72, 0x59, 0x85, 0x73, 0x71, 0x84, 0x80, 0x30, 0x31, 0x70, 0x7A, 0x5A, out: MultiSensor6C 2019-02-12 3:00:36 PM PST 2019-02-12 3:01:31 PM PST
025 (19) 100 258 in: 0x5E, 0x86, 0x72, 0x5B, 0x85, 0x73, 0x71, 0x84, 0x82, 0x30, 0x31, 0x70, 0x7A, 0x5A, out: MultiSensor6D 2019-02-12 3:01:00 PM PST 2019-02-12 3:01:26 PM PST
11 of my 12 Aeon Multisensor 6's are Battery powered at this time.
I see, apparently is some devices only, like the aeon multi 6, I used the z wave tool and confirmed no battery devices were repaired here.
Great to hear.
word on the street is you have a secret prerelease version of HE, with some extra zigbee magic baked in.
I'm anxiously waiting my my red exclamation point to show up
Download the Hubitat app
