Z-Wave Range Issues

[macromark]

The leviton VRUSB (?) installer USB "stick", vrc0p and openzwave even with the prev gen USB controllers could set routing for years. E.g. from the vrc0p application note:
"



[SIZE=10pt]Routes (RO): [/SIZE][SIZE=10pt]To provide routing slaves with valid routes (when nodes can’t reach each other directly) “RO” command is used. Routing slave can have up to 5 nodes assign return routes. When adding new routes, it is recommended to delete all existing routes first. [/SIZE]
[SIZE=10pt]>RO2,0; delete all routes for the routing slave node 2. >RO2,10; setup up to 4 valid routes for node 2 to node 10. [/SIZE]
[SIZE=10pt]"[/SIZE]
So, nothing new here.

I think we are talking about 2 different things.  I'm not talking about the route setting that is automatically done by the controller. I'm referring to the new feature that allows the user to manually set the command route. In the example below, the Last Working Route shows the route to go through this path: nodes 1 > 5 > 64 > 15 (controller is node 1 and end node is 15). 

In our software, you can manually change the route to something else using the "Set Route" field.
 
In my system, the controller assigned a route to my lock that actually used a plug-in module in my shed... a crazy route!  I manually modified the route using nodes that were neighbors inside my home instead. That's what I'm referring to.  If you want to set the route (specifically), that's a new 500 series chip feature.

 

[rsw686]

I think we are talking about 2 different things.  I'm not talking about the route setting that is automatically done by the controller. I'm referring to the new feature that allows the user to manually set the command route. In the example below, the Last Working Route shows the route to go through this path: nodes 1 > 5 > 64 > 15 (controller is node 1 and end node is 15). 

 
Thanks for the screenshot. This is impressive that you can see this much detail on the device! If I purchase a Zee S2 and decide I need more capability can the Zee S2 act like a Z-Net to be used with the HS3 units?

 

[vc1234]

I think we are talking about 2 different things. I'm not talking about the route setting that is automatically done by the controller.

Not really.  The command I referenced can be executed manually and in fact I did when I tried to "fix" misbahiving locks, without any success though because as it turned out the problem was not related to routing at all.
 
The command is designed to be executed either by a human being or  piece of software through the vcr0p serial port.
 
Besides, I do not see much utility in the feature because how do you know that your manual route is better than the one assigned by the controller during route discovery/aka "healing" ?  You don't, you can only guess since you do not have any idea what the signal strength is at specific location and at specific time. Admittedly, there are some clearly crazy routes the controller may use, but usually there is an underlying reason for them being used.  In my case, the controller decided to use a less efficient route on several occasions when it was jamming itself with beaming packets.  A misguided decision, but what is not in this sorry excuse for a protocol ?
 
After several hours of using a less efficient route, the controller reverted to the old direct route, with a better signal strength, on its own without my needing to muck with manual routing.

 

[macromark]

Thanks for the screenshot. This is impressive that you can see this much detail on the device! If I purchase a Zee S2 and decide I need more capability can the Zee S2 act like a Z-Net to be used with the HS3 units?

The Zee S2 actually is an HS3 unit with HS3-Pi2 software embedded.  The Zee and Z-NET use the same internal Z-Wave module but have different motherboards (with different CPUs and RAM) and different embedded software... so they're not interchangeable.  

 

[macromark]

Not really.  The command I referenced can be executed manually 

Again, we're talking about different things. Your system allows you to manually tell the controller to redo a route. However, it's still the controller that's making all the decisions about the route.  Our system allows you to set the precise route you want. If you want to route to be 1 > 6 > 8 (for example), you can set that route. Now you can argue that that's not an improvement or that you don't see the value in doing that... that the controller always knows best or whatever... totally fine! I'm not going to argue with your opinion or your experience.  All I'm saying is that we provide the option and some folks might find it helpful.  
 
For my part, I have some peace of mind in that I've removed plug-in modules from all my node dependent routes. That way, the network doesn't get all "hinky" if one of the kids removes one to plug in their phone charger (yes, that happens!).

 

[rsw686]

For my part, I have some peace of mind in that I've removed plug-in modules from all my node dependent routes. That way, the network doesn't get all "hinky" if one of the kids removes one to plug in their phone charger (yes, that happens!).

 
That's exactly why I went with the Leviton outlets as repeaters. I finally got the garage outlet and lock working. I added a plug in module to the bathroom gfci outlet and it started working after a repair. This is slightly closer than the outlet across from the pantry. If it continues to work I'll just cut the wall open and add another outlet so I can have a permanent module. Still frustrating. HomeSeer does have a high cost of entry as the more I look at it the Zee S2 with the 5 plugin limit is going to be an issue. I also didn't realize you can't design touch screen for the iPad without HSTouch.

 

[macromark]

That's exactly why I went with the Leviton outlets as repeaters. I finally got the garage outlet and lock working. I added a plug in module to the bathroom gfci outlet and it started working after a repair. This is slightly closer than the outlet across from the pantry. If it continues to work I'll just cut the wall open and add another outlet so I can have a permanent module. Still frustrating. HomeSeer does have a high cost of entry as the more I look at it the Zee S2 with the 5 plugin limit is going to be an issue. I also didn't realize you can't design touch screen for the iPad without HSTouch.

If the 5-Plug-in limitation doesn't work for you and you want to keep the costs down, consider getting a license for HS3 instead. You'll be able to install that on the PC of your choice and the cost is currently 50% off through the end of May.
 
HSTouch Designer is a separately licensed tool. that also is 50% off through 5/31 (FYI). However, there are other interface options too. A plug-in is available for ImperiHome and lots of users have that too.

 

[vc1234]

Again, we're talking about different things. Your system allows you to manually tell the controller to redo a route. However, it's still the controller that's making all the decisions about the route.  Our system allows you to set the precise route you want. If you want to route to be 1 > 6 > 8 (for example), you can set that route. Now you can argue that that's not an improvement or that you don't see the value in doing that... that the controller always knows best or whatever... totally fine! I'm not going to argue with your opinion or your experience.  All I'm saying is that we provide the option and some folks might find it helpful.  
 
For my part, I have some peace of mind in that I've removed plug-in modules from all my node dependent routes. That way, the network doesn't get all "hinky" if one of the kids removes one to plug in their phone charger (yes, that happens!).

Your system most likely uses the same closed serial api as vrc0p or open zwave library do. Both systems can set "the precise route". E.g. openzwave:
 
---

bool Manager::AssignReturnRoute

(

uint32 const 

_homeId,

 

 

uint8 const 

_nodeId

 

)

 

 
Ask a Node to update its update its Return Route to the Controller This command will ask a Node to update its Return Route to the Controller.
-----
 
None of the system, including yours,  I believe, guarantees that the manual route will be used.  None of the system has access to an API call to show what the actual route taken is.  It's not surprising because Zensys (to my knowledge derived from publicly available sources) does not expose lower level PHY/MAC information including actual route being taken or any way to directly manipulate the routing tables.  All they give you is "Serial API" and to get access to that one has to sign an NDA.  The OZwave folks managed to reverse engineer the said API, but not the lower level stuff of what's actually going on on the wire or rather in the air.
 
I imagine one could force a controller to take a specific route by deleting the alternative routes, but if they are available you do not know which one will be chosen.

 

[macromark]

--
bool Manager::AssignReturnRoute ( uint32 const  _homeId,     uint8 const  _nodeId   )    
Ask a Node to update its update its Return Route to the Controller This command will ask a Node to update its Return Route to the Controller.
-----

To clarify, our "Full Optimize" feature performs this function and that's been in our software for many years.  That's not what I'm talking about!  I'm talking about assigning the outbound command route. This is a new capability that was added with the 500 series controllers.
 
If anyone wants to see this feature in action, here's a brief video:  https://youtu.be/umxghoNfwwE

 

[ddennerline]

To get more than one of lock working reliably, you definitely need many supporting devices. I have noticed the range for locks is much shorter than 20-30 feet that is typical for light switches. I suspect much higher latency along with multiple round-trips improves odds of packet-loss. In my network, locks are the biggest hassle. I don’t have same issue with lights – even when I turn off a large number of lights using a group command.
 
It would be interesting to find out if the new "green box" Vizia+ (latest ZW firmware) devices do transmit at higher power.
 
I don’t think it’s fair to compare RA to Z-Wave because RA uses a much lower frequency, the network topology is hub-n-spoke (not mesh), physical packet sizes are smaller, and the number of supported device classes is smaller (http://www.lutron.com/TechnicalDocumentLibrary/367-2130_RF%20Whitepaper.pdf). The designers of Z-Wave made a good number of tradeoffs to support wide variety of devices.
 
I do agree that due to closed nature of Z-Wave/Sigma diagnosing problems is much harder without any type diagnostic/debugging toolkit. I think the SDR radio sniffing is very cool. I have used the diagnostic tools in the RFIT, but they only tell you something is not working. The don’t tell you why it’s happening or how to fix the problem.

 

[vc1234]

To get more than one of lock working reliably, you definitely need many supporting devices. I have noticed the range for locks is much shorter than 20-30 feet that is typical for light switches. I suspect much higher latency along with multiple round-trips improves odds of packet-loss. In my network, locks are the biggest hassle. I don’t have same issue with lights – even when I turn off a large number of lights using a group command.

 
I have two Yale locks. One is located approximately 25' from a vrc0p with the signal traversing two drywalls at an angle.  The communication between the lock and the controller is always direct without any intermediary re-trasmitter node. Other than the hiccup with incorrect association, the lock has *never* failed to open/close/communicate its status to Elk since I installed it.
 
The other lock is about 30' from the controller with the signal traversing one drywall.  The controller does use a re-transmitter node to communicate to the lock.  Occasionally, I observe a direct path of communication between the lock and the controller.  The signal from the lock does appear to be somewhat weaker than that from a nearby thermostat placed in the same vertical plane about 2' higher from the lock (-80-82dbm vs 75-76dbm). I have not experienced any issues whatsoever with the second lock either.
 
Re.latency.  In my network, the usual delay does not exceed roughly 1 sec -- that's how much time the "beaming" phase takes.
 

It would be interesting to find out if the new "green box" Vizia+ (latest ZW firmware) devices do transmit at higher power.

 
If they are based on a gen5 chip, they may, but of course you want both sides of the communication path to be gen5 devices, or at least the controller.
 
RadioRa2 uses 431/437Mhz which theoretically should provide 2x longer range than 908.Mhz (see the Friis formula). I am currently experimenting with BLE, mainly  trying to get a bunch of temp/humidity readings, but I don't hold my hopes too high for obvious reasons wrt the range, especially indoors.