I’m using a Jasco/GE Z-Wave “plug-in outdoor smart switch” near my front vehicle gate. The switch itself consistently responds to on/off commands, but it does not seem to repeat z-wave commands.
I have an aeon lbs door/window sensor within a couple of feet of the switch and have spent a lot of time trying to get the sensor to work, thinking the outdoor switch would act as a repeater (thus I’ve tried z-wave repair many times, removing and adding the devices, so on and so forth) to no avail.
Just today it occurred to me that perhaps the outdoor switch does not repeat z-wave commands and in their own product description is does not say? Would anyone happen to know for sure? I was under the impression, perhaps falsely, that a standard existed in the z-wave world which would have made the outdoor switch a repeater.
Pretty much all means powered devices other than smoke alarms should act as repeaters, so the outdoor plug and should act as a repeater. You can always check to be sure in the official conformance statement for the device on the Z wave alliance website.
However, just because the device is a repeater doesn’t mean that the sensor knows that it should be using that device. When a device is first paired to the hub, it builds a mini address table of the neighbors which are closest to it which are repeaters.
If you then either move that device or add new devices there’s nothing to tell the first device to update its address tables. And so it will not include its new neighbors. This can result in routing problems.
The way you fix this is by running is the zwave repair utility. This just causes the hub to send out a message to all the devices telling them to check and see who their real neighbors are and update their neighbor tables.
Note that although the utility will finish running pretty quickly, typically within about 15 minutes, that just means the hub is done with it part. It can still take a couple of hours before all the individual devices have finished updating their own neighbor tables. So you may not see the results for a few hours.
Running the repair utility is one of those “can’t hurt to might help” things which is always good to try if you’re having problems with a zwave device.
Thanks for the detailed reply @JDRoberts. I have run the z-wave repair many times without success over the past weeks (from the IDE and mobile app). I suppose one more time would not hurt. It is perplexing to say the least.
Once in a great while the sensor will work for brief periods of time. I suspect it is attempting to communicate with the hub, which is probably just out of reach.
I did look up the switch on the website you mentioned (thanks by the way for that) and it says the switch supports “beaming”. Two things I’ve learned today, the website for conformance docs and the meaning of beaming vs. repeating.
“A slave node that simply repeats the signal grabs the message, understands that it is not intended for itself and sends
the packet a long. A module that support beaming will recognizes that there is a battery powered device nearby and
will hold the message in a buffer until the node wakes up with the broadcast request mentioned above.
Note: In a multi-hop situation, only the last node before the destination node needs to be a module that supports
beaming.”
If it’s not too much trouble, I think the next thing I would do is bring the sensor inside near the hub, runs the zwave repair, and just leave it there for a week or so and see if you do get active reporting from it. Not so much because that’s the most likely problem, but just because if that is the problem nothing else is going to make any difference.
Good idea JD, I have done that and the sensor works without issue near the hub. In hindsight I realize that my z-wave repair attempts usually result in the " failed to update route" and “failed to update mesh info” which of course would be an issue. I suppose I need to research how to correct that problem then try again with the sensor?