Iris 3210-L Zwave repeating not working

@mike.maxwell or @bravenel, any chance that with all of the Iris interest you can take another look at zwave repeating on those 3210-L smart plugs? While you can get the zwave radio paired they are not serving as zwave repeaters.

How did you confirmed this?

Make sure you have the latest firmware, there was an update that fixed an issue with Z-Wave repeating.

1 Like

Made sure multiple of these devices were up to the latest firmware while paired to Iris Hub. The removed them from the Iris Hub.

Then paired them to Hubitat first catching the Zigbee radio and then in a second pairing paired to the zwave radio. Then do a zwave repair to confirm Hubitat sees these newly paired device and the repair confirms they responded to the repair.

With a new C5 hub in a clean environment I have nothing but 4 of these 3210-Ls, a Zooz 4-in-1 sensor, and a Monoprice 15271 Zwave Plus motion detector. As long as both of these motion detectors are connecting directly through the hub they function properly. Once they are put in a space that would require them to connect to a repeater they will not connect in the space where there are 2 of the 3210-Ls.

The zigbee radio on these devices will repeat perfectly if I test with a couple of battery powered zigbee devices like an Iris door contact or Sengled Zigbee bulbs.

Those battery powered zwave devices won't connect and even after a hub reboot you can look at the logs as a Zwave repair happens and they will not show up.

I don't have the latest firmware and I "think" it's working for me. The only way for me to confirm this is by pressing the refresh button on the Z-wave repeater and look at the info in the Z-wave info page. If you get an update under "last received" then I assume it's working.
Is there some other way to check this?

Is the version they are on 0x20085010? That is the latest.

Battery devices will not show up in a Z-wave repair, only mains powered.

This is one of the reasons I always said you must pair the device at its final location when it's battery powered, the z wave repair doesn't work on battery devices unless you wake up the device at the exact time the hub will repair it, and sometimes the hub doesn't not follow number order so it's difficult. It will be nice to have an option on the z wave repair to choose one device and repair it so we turn it on and then we wake up the device to be repaired.

@mike.maxwell and @bravenel do you think this could be posible? to have an option on the z wave repair to choose one device and repair it so we turn the option on and then we wake up the device to be repaired? Honestly it will be a great addition if its possible.

Not sure if polling the device would be enough, but I would imagine the timing would be an issue. I do not have many battery Z-Wave devices, but I never see them show up in a Z-wave repair. I also do not have any issues with these devices so I never bother to look into it.

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.

1 Like

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.

1 Like

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.

1 Like

I haven't found that to be true, unless the Hub's radios are exceptionally strong. :slight_smile:

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"

2 Likes

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.