Yes, zwave plus devices will route non-zwave plus devices, and vice versa. But you need a zwave plus controller to see the benefits of the newer generation zwave.
Do you have any reference for that info, or did you pick it up from personal experience? I’ve always thought of repeaters as marketing snake oil, since all mains powered devices will route for other devices. Although, not all mains powered devices have the same signal strength, and placement can be tricky in a sparsely populated mesh. If their range is the same, a smart outlet is just as effective as a repeater, and you can use it to do stuff. Although, you’d likely see an improvement in your network with an upgrade to a gen5 controller.
That should be fine, but another device would build in some redundancy.
this is just anecdotal, but I had terribly response times from a Dana battery operated door lock, even though several mains-powered devices were nearby… and this greatly improved when I plugged in a repeater.
I would agree - from what I’ve seen in the docs, there’s no difference. Most devices use the same silicon so there’s no reason to assume that a repeater is any better, or worse, than any other (mains) device.
All I have to go on is my experience. This repeater made my network rock solid. This mains powered device plugged into the exact same place with the exact same other devices was kept my network slow to respond to messages and dropped messages. There can be other explanations for this but I don’t think my conclusion was unreasonable.
Well, as established, all mains powered devices repeat. As such it is a part of the z-wave library and functionality and they don’t appear to have a field for that as it would be redundant.
The link was specifically in response to beaming which is slightly different. If you find your device and then click on the “view” link under “Z-Wave Protocol Implementation Conformance Statement:”, under product information, you will see a list of supported technologies. Specifically, “Supports Z-Wave Beaming Technology?” yes/no.
That beaming tech will allow battery powered devices to rapidly communicate back through this device to a controller or another beaming capable device.
As for identifying if a device is a repeater ONLY… That should be pretty obvious from the devices name and description but the closest thing I could see that would tell you there would be to look at the Z-Wave library type. Just looking at Rich’s repeater:
Z-Wave library type: Routing Slave
I would made the assumption that a routing slave does little but route.
Just a note that this isn’t 100% correct. It’s not applicable for normal battery devices - only FLiRS devices which are normally limited to locks and recently some thermostats.
Actually, you are correct, it can be used for any battery devices but it was designed for locks for quicker response.
I should also clarify that only the device closest to your lock needs to support beaming. I implied that beaming devices need to be in a chain back to the hub.
The last device will get the command and keep broadcasting it until the lock wakes up and acknowledges.
Yes, but just to be clear (sorry) - it’s only available on devices that support FLiRS. Normally, battery devices don’t support this.
Sorry - this is probably what you meant, but I just wanted to ensure that people don’t think that this will work with any battery devices they have. Most battery devices sleep 99.99% of the time and are only available when they wake up.
So what do you mean with it was designed for “locks” - what do you mean with a lock a switch?
When I do now have to setup a ZWAVE PLUS network for a large house, 3 floors, should I just make sure that I do use on each floor at least one powered device, or some more for each corner per floor, or what is your experience?
FLiRS allows battery devices to be (reasonably) responsive. Most (ie nearly all) ZWave battery devices sleep for 99%+ of the time - you can’t send them anything in that period. This is fine for sensors, but if you want to open your door, then you don’t want to wait 1 hour till the lock wakes up.
A FLiRS device will wake up more often (a number of times per second - depending on the exact implementation). This makes it pretty responsive - a bit of lag, but less than 1 second, and certainly not 1 hour.
Any battery device can use this system, but at the moment, it is mostly implemented by door locks (ie something that opens your front door). There are a couple of radiator thermostats on the market now that also use FLiRS which is great for them as well).
You’ll need more than this for a good mesh. It’s pretty hard to give exact statements as the performance of RF, especially with these devices (small antennas that aren’t aligned), and different types of house construction (wood, brick, concrete) all impact on the performance.
I just checked for my Neo Coolcam PIR (ZWAVE PLUS) of course battery driven, and it says: Zwave-beaming TRUE.
Is this now for all ZWAVE PLUS devices even when battery driven or does it just say when the device is not sleeping it can beam.
(Beam me up Scotty:slight_smile: )
Both the listening and frequent flags are false, therefore device doesn’t support FLiRS - this is the important thing.
For sure it is not a ZWave Plus feature that requires all devices to support FLiRS - it’s down to individual devices. Most battery devices won’t use it at the power drain is higher, and therefore battery life will be lower. It’s also not necessary for most devices.
Do you have any documents you can link on this? I can’t seem to find anything that defines FLiRS as separate from beaming.
Z-wave alliance only seems to list beaming as supported yes/no. I don’t see any mention of FLiRS even on lock devices.
The way I have understood it is that if a mains powered device supports beaming, it is capable of sending the wake signal. If a battery device supports beaming, it would support FLiRS.
I looked at a few different devices and only the door locks seem to have beaming = yes. Motion sensors and the like all say no.
I’m just trying to outline a reliable method of identifying capabilities of devices prior to purchasing. I feel like if z-wave alliance was going to go to all the trouble of building that database and FLiRS vs non-FLiRS was a valid datapoint… it would be listed.
FLiRS is the receive side, and beaming is the transmit side - the two a different parts of the same story. The frequently_listening flag in the node properties means it supports FLiRS (The FL in FLiRS being Frequently Listening).
As I already said there are also some new thermostats - eg the Spirit. Most sensor just use listening=false - ie the wakeup command class.
Although, you’d likely see an improvement in your network with an upgrade to a gen5 controller.
