A Warning About Iris Smart Plug Z-Wave Repeaters

Thanks for reminding me, I’ve updated my post to include that information.

Here’s an update… Been very busy re-connecting the rest of the Z-wave devices and rebuilding the various rules, SmartApps, etc., but everything is re-paired and all rules reset.

Since reconnecting, several of the Z-wave repeaters in these devices have disconnected. I’ve manage to use the “repair device” function to reconnect a few, but one had to be force-deleted and reset. The head-scratcher is that most (but not all) of these disconnected plus were in direct line-of-sight of another connected plug or GE mains-powered wall switch. To ensure that these were connected I also several z-wave tests on the devices using my custom DTH prior to them disconnecting.

Observations on Pairing… These devices do not like routed-association through other devices. I have been utterly and completely unsuccessful at pairing-in-place outside of the room where the hub is, or the wall immediately adjacent to that room. This is especially true for the devices in the front of the house, or basement. Both of which had to be paired near the hub then moved to their final location. I did not have any issues pairing-in-place any of the GE wall switches or in-wall receptacles, leak sensors, or smoke detectors, regardless of what floor they were on.

The detached garage, which has always been a problem as it is located a solid 40-50 feet from the house. The garage contains 1 older GE in-wall switch, one new GE Z-Wave plus in-wall switch, plus an Aeon 6-in-1 multi-sensor. On the exterior of the house facing the garage I placed a new GE Z-wave plus Outdoor module. With this arrangement I was able to pair both GE switches inside the garage, in-place, and on the first attempt. (The 6-in-1 sensor lives outside, because of the weather it was paired inside then moved into place)

In conclusion, as far as pairing goes, I believe these repeaters require direct-hop access to the hub in order to connect. I was not able to get them to pair unless they were within 10-15 feet of the hub. I did not observe this behavior with any other Z-wave or Z-wave plus devices. Once connected they are, for the most part, stable.

Not a z-wave repeater but First Alert smoke detector is also like this. It needs to be close to the hub to pair but very stable afterward.
I usually pair one device at a time close to the hub then do a z-wave repair after I place that device in its permanent location.

These devices are weird, no question. They were really designed to work with their own hub which does some magic with them to get them to connect.

I suspect the problem is that the firmware does a sequence when it first powers up: it begins by looking for a zigbee network and attempts to join that. If that is successful, it then automatically initiates the Z wave add.

If there is no zigbee network open for joining, it does not start the Z wave add.

You can get it to join a Z wave network by factory resetting the device, putting it on power, and then immediately tapping the button on the front, although the number of taps appears to vary based on the firmware version. That will then put it into Z wave inclusion.

Once you have joined it to a zigbee network but for whatever reason you didn’t get it added to Z wave network as part of the same sequence, you have a problem. It looks like it may be difficult to get it to add. But there’s a second layer to that difficulty, because this device supports secure Z wave communication.

You add all of that together and I suspect a couple of things.

First, I don’t think these devices are ever going to add in place in an outer ring. So I agree with the observation that there is a one hop maximum for joining. I think that’s because the security join is failing when sent through a repeater. This is similar to the problems that occur with Schlage locks. This would produce the symptoms where the device is listed as being part of the Z wave network, but it won’t do anything and it won’t respond to any commands.

I do think if they are correctly added they should then work fine a couple of hops away, which matches what other community members have said.

I may be mistaken, but I believe there are stock device handlers for this now that added as both a zigbee and a zwave device. If that is true, then I would always add these devices by putting them close to the hub (to improve the odds that the security gets set up correctly) for the initial pairing and doing that with the stock device handlers. Once the device is on both networks, then you should be able to manually change the device type handler if desired.

There are two possible explanations for why the devices are failing when they are more than six for 7 feet away from the hub even though they are still within one hop.

The first possibility is that the pairing is timing out before it completes, and then ever after you run into that sequencing issue where you just can’t get it into inclusion mode again.

But the second possibility, particularly If This is older firmware, is that the secure pairing is failing but leaving the device on the network without the encryption key. You may remember that when the Aeotec zwave plus smart switch pocket socket first came out it had this problem. That was later fixed by improved firmware.

Anyway, multiple people have reported since this device first came on the market that they had to pair it very close to the hub to get the Z wave repeater to work. But after that they could move it further away.

I believe @SBDOBRESCU has a number of these at some distance from the hub, he might be able to say more as well.

4 Likes

I concur with you 100%. I have several devices working in a shop of mine… no interference… 50’ max distance and I never observed ANY repeating capabilities whatsoever…

Actually I was using it to try to resolve a Z-wave connection problem I was having with light switches in a metal box… Installing the plug with 8’ of the switches had on benefit…

I ultimately resolved the issue by removing the end on the metal box and placing one of the switches on that end…

ZD[quote=“LittleJohnny, post:25, topic:110696”]
I concur with you 100%. I have several devices working in a shop of mine… no interference… 50’ max distance and I never observed ANY repeating capabilities whatsoever…
[/quote]

I just confirmed from the device details in the IDE these DO NOT repeat.

This is the Raw Description field for all of my Iris Z-Wave repeaters:

zw:L type:0F01 mfr:0246 prod:0001 model:0001 ver:1.02 zwv:4.05 lib:06 cc:5E,72,86,5A,73,85,59

Z-Wave Protocol Capabilities:

L  : Listens
R  : Routes
B  : Beams
RS : Routing Slave
W1 : Requires beaming

The first field (zw:) is the Z-Wave device protocol capabilities description. If you look at the flag it’s type “L”. According to the spec, type L is a listening device. According to Iris Support, its a Routing Slave, so that flag should be a RS, not L.

These devices which identify as listen devices DO NOT report themselves as repeaters to SmartThings. WIth that said, it is quite doubtful the hub is including the in the mesh as repeaters.

@JDRoberts what do you think?

EDIT: The flag doesn’t seem to be set correctly across all devices with all of my GE switches reporting as being type L. I think the mystery continues.

1 Like

JDRoberts said: “Anyway, multiple people have reported since this device first came on the market that they had to pair it very close to the hub to get the Z wave repeater to work. But after that they could move it further away.”

I do this with each and every one of my devices. I pair within a few feet of the ST hub, then move them to their working locations. Dunno whether that has any impact, but I’ve never had a single one of my devices drop off the network… and communication has been uniformly good, with the only glitch being due to a concrete wall. I moved the device, and no more issue.

1 Like

I looked at a few of my Z-Wave devices in the IDE (just to remind myself of how little of this technology I really understand) and for those which showed ‘zw:’ in the raw description, saw none showing ‘R’ for the protocol capabilities All showed “L” except my Aeotec Doorbell, another Z-Wave Plus device, which showed ‘Ls’ in this field.

For some of the devices, including one of four Iris plugs, there was no ‘zw:’ in the raw description; it was formatted differently and contained no non-hex characters (yet all my Iris plugs use the default ‘Zwave device’ type in the IDE). Even stranger, only one of the four plugs showed an endpoint ID in the Data description (the other three showed ‘no data found for device’). Two of the four showed a ‘level’ along with ‘switch:off’ in the current state. In one switch the level showed 99, the other showed 1. In the other two plugs, there was no level text displayed.

For the record, all my devices work without issues, appear to participate as expected in the Z-Wave repair logs, and paired without difficulty (all except the in-wall switches were paired right next to the hub). Still have no clue as to how the device raw data relates to their function.

Tagging @duncan

From the docs:

zw: This field will start with ‘L’ for listening devices, ‘S’ for sleepy devices, and ‘F’ for beamable devices. See the Z-Wave Primer for the meaning of those terms. That capital letter will be followed by a lowercase ‘s’ if the device is securely included into the network via the Z-Wave Security Layer.

All listening Z-Wave devices act as repeaters. The term routing refers to the ability to store routes to be able to send unsolicited commands directly to other devices in the network. We don’t report that in the Raw Description because it’s not very relevant to us.

2 Likes

Thanks for the response, and I hope you had an enjoyable holiday season too!

One question, you mention that the repeating is not reported as it’s not relevant. These devices act as routing slaves so they have an awareness of neighbors and partial routes. Does the SmartThings Z-Wave implementation take advantage of those capabilities?? Or are they being utilized as simple repeaters?

Appreciate any info you can provide. Thanks!

He didn’t say “repeating” wasn’t relevant. He said “routing” for the purpose of sending unsolicited zwave commands wasn’t very relevant. Two different things.

1 Like

If the Raw Description is “zw: L” it is repeating, so we do report that.

Z-Wave is source routed. The entire route to the target device is determined by the sender of the command. The repeaters can’t interfere and use their own information to affect the route.

The exception is explorer frames, which are a kind of flooding routing. In that case, all repeaters that support explorer frames are involved, so it doesn’t matter if the repeaters know their neighbors.

The central controller can assign routes to devices with routing capability so they can send their own routed commands. Currently, SmartThings only does this for the return route – the route back to the hub.

1 Like

Thanks, that does help me get a much clear picture.

These Iris SmartPlugs appear to be very unreliable at acting as Z-Wave repeaters, hence why I created a DTH for troubleshooting. After stripping down my Z-Wave network to nothing, I was unable to build a reliable mesh using 20 of these back before Christmas as documented earlier in this thread.

A number of these will fail during a Z-Wave repair (i.e. Rptr Water Heater [BD]: Could not assign new route, Rptr: Film Storage Refrigerator [DA]: Failed to read protocol info). The next repair, usually a different set will fail, and so-on. During my, with just 5 of these devices connected (and no other Z-wave devices) I ran a rebuild and saw two of them throw errors during a repair. My goal is to get an understanding of why these don’t work reliably with ST, but work great with Iris. Any insight you can provide would be beneficial to myself and others here that use these.

Thanks again!

1 Like

When Iris 2.0 was originally launched in the fall of 2015 many users reported issues with reliability of these devices. In doing some research I’ve noticed that reports of problems with these devices seem to have stopped over the past year.

It is interesting to note that around the same time, in January 2017 Lowe’s Iris pushed an OTA firmware update out to version 0x20085010. Since SmartThings cannot OTA these Iris devices we are stuck with the version that these shipped with (0x20015010). Clearly Lowe’s addressed some issue with these plugs, whether on the Zigbee or Z-Wave side.

Last night as an experiment I took my old Iris v2 hub out of storage and paired a single SmartPlug to it. This morning when I woke up I noted that it had been upgraded by Iris to the latest firmware (0x20085010). This plug was re-connected to SmartThings and a Z-Wave repair was run. On the first rebuilt, the upgraded device threw no errors.

I did note that the upgrade to 2008 firmware does change the Z-Wave pairing behavior. When you press the button 8 times to initiate Z-Wave discovery, instead of the double-blink of the LED there is now a single blink with a 1 second pause. The hub also discovered the device in under 10 seconds which was notably faster than normal, although that could possibly be attributed to other factors.

Another pair of SmartPlugs has been removed from ST and paired with Iris. It appears that the Iris hub only pushes OTA updates overnight so by tomorrow morning these should be updated. My plan is to gradually increase the sample size with Z-Wave repairs in-between. My hope for this endeavor is that a firmware update is all that will be required to make these work reliably.

3 Likes

200w (2)

1 Like

Did firmware upgrades solve the problem for the rest of your plugs?

@SteveWhite thanks for your research on this item. Using the V2 Iris hub I was able to update the firmware on my 3210-L plugs. Before updating with the Iris Hub I first paired one to a ST V2 hub. Firmware on this plug was 0x20015010 .

I left this plug paired on ST for an hour but saw no firmware update. I was probably rushing things but I then unpaired from ST hub and paired with Iris. When I first checked on the Iris hub it was still showing old firmware number. When I checked 15 minutes later it showed 0x20085010 which must be the latest and greatest.

As far as I understand the Iris outlet is not officially supported, thus no ST firmware updates. Other Iris devices are officially supported.

Centralite manufactured both the Iris and older ST smart plug. Only difference was that Iris also had a Zwave radio. I always used the ST DTH with mine and have received a firmware update in the past.