Announcement

Collapse
No announcement yet.

Network Optimization Best Practices for Z-Wave+ Networks 11/12/18

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Network Optimization Best Practices for Z-Wave+ Networks 11/12/18

    Z-Wave is a mesh network, that means that nodes assist each other with routing commands to other nodes. For this to operate properly, the controller must know which nodes are in contact with other nodes. This information is obtained through a process called "Neighbor Discovery". When a device is added to the network the controller instructs the node to perform this process. The node then reports all the nodes that are in direct range of the added device. The controller then builds its own table of "routes" which are the possible routes it could use the reach the node. Normally, you do not have to be concerned with this process as its automatic. However, if you add and remove many devices, this information can become stale and the controller could develop many bad routes.

    Routing prior to Z-Wave +

    Prior to Z-Wave+, having accurate routes was more important. The routes were only obtained by this neighbor discovery process. HomeSeer has the ability to manually start a network wide discovery which would update all the neighbor information. HomeSeer also had a feature named "Z-Health" which ran the discovery automatically. This feature has been removed. With Z-Wave+ a new feature was added to the Z-Wave protocol called an "explorer frame". If the controller cannot reach a device it sends out an explorer frame that will discover a route to the destination. This allows the controller to find new routes on the fly. Because of this, performing a manual optimization is normally not necessary and hence one of the reasons the Z-Health feature was removed.

    Issues with Optimizing

    When a network is large, say over 60 nodes, optimizing the entire network can be problematic. The process takes a very long time. Z-Wave cannot do normal functions during this process. The controller can sometimes get into a bad state requiring it to be restarted. When too many routes are discovered the controller has a hard time finding the best one. It can sometimes pick a route that is not the best and can sometimes fail.

    For these larger networks its best to NOT do a full optimize. After some internal testing, the following process has fixed many networks by removing excessive routes:
    1. Clear all routes. To do this, from the Z-Wave plugin back up your Z-Wave interface, then restore it. This erases the interface which removes all the nodes and routes. Then do a restore which restores all the nodes. Restart the plugin and ensure that you can still control nodes that are close to the controller.
    2. At this point the controller has NO routes and will only use direct communication. Run a node connectivity test and see if it can reach all your nodes. If so, you are done, you do not need to optimize anything.
    3. If you get some failures on the connectivity test, find a Z-Wave+ node that is in the center of your home, maybe a wall switch. Optimize just that node. That node will then become a repeater for any node that is out of range of the controller. Picking a Z-Wave+ node ensures that this node routes at the fastest speed possible.
    4. Run the connectivity test again. If it passes, you are done, if it fails, pick another node to optimize. Repeat until you have good connectivity.
    Some notes:
    • Z-Wave devices are available in 3 different speeds, 9.6Kbps, 40Kbps, 100Kbps. If your network has mixed speed devices try to not optimize non 100K devices. There are some bugs in some of the older Z-Wave firmware where it will attempt to route at the wrong speed. Not using slower speed devices in routing will remove this possibility.
    • If routing is kept to 100K devices you be assured that your network will run as fast as possible. Imagine if an older 9.6K device was in the center of your network and used in most routing. This would slow down the entire network.
    • If you have ALL Z-Wave+ devices your network it should "self heal" in that the explorer frame should find all the needed routes and you should not have to optimize any nodes. However, its rare to have a network that is 100% Z-Wave+.
    • A single device may be optimized from the Z-Wave tab in the root device properties.
    • How can you tell if a node is Z-Wave+? From the Z-Wave plugin menu in HomeSeer select "Node Information". Find the version section for the node and look at the ZDK version #. If it starts with "6", like 6.81, then its a Z-Wave+ node. Also, check the speed, it its 100K, its most likely Z-Wave+.
    website | buy now | support | youtube

  • #2
    In the event we do need to optimize a single node, are we still required to do 4 optimizes? Or is that leftover from the old z-wave days?
    HS3Pro Running on a Raspberry Pi3
    64 Z-Wave Nodes, 168 Events, 280 Devices
    UPB modules via OMNI plugin/panel
    Plugins: Z-Wave, BLRF, OMNI, HSTouch, weatherXML, EasyTrigger
    HSTouch Clients: 3 Android, 1 Joggler

    Comment


    • #3
      Per #2, what about battery operated devices that do not wake for the test? Should we run to each one and optimize each battery device or just leave them alone?

      Comment


      • #4
        When optimizing a single node, you only need to do it once. The neighbors it finds should not change unless some are on the fringe. The 4 optimize rule was for optimizing the entire network. This is because if you do it once it may not reach all of the nodes until it has some routes. So I would say to never do a full optimize, I never do it. Just optimize a few nodes as needed, but only once.

        Originally posted by rmasonjr View Post
        In the event we do need to optimize a single node, are we still required to do 4 optimizes? Or is that leftover from the old z-wave days?
        website | buy now | support | youtube

        Comment


        • #5
          If they are Z-Wave+ they should find their own route back to the controller. If they are older and are not reporting, then yes, wake them up and optimize full. Battery devices are not smart enough to find a route so the controller actually programs 4 possible routes into the device. So get all non-battery devices working first, then deal with battery devices. The ensures the controller can assign the best routes.

          Originally posted by Integraoligist View Post
          Per #2, what about battery operated devices that do not wake for the test? Should we run to each one and optimize each battery device or just leave them alone?
          website | buy now | support | youtube

          Comment


          • #6
            1. - Regarding Z-Seer, the Z-Seer documentation states the Z-Wave protocol allows for a command to "lock" all routes on a network. This would theoretically allow a user to build all routes manually and have them stay that way. How can a HomeSeer user issue the command to lock the z-wave network?

            2 - Regarding S2 security. S2 devices are issued an S0 key at inclusion in order to facilitate backwards compatibility. But what is the situation when a controller needs to route commands for an S2 node through an S0 node? Ie controller is direct to an S0 node, and the S0 node provides the hop to an S2 node. Can the S0 node relay the command, or is it not possible because it does not have an S2 key? Or is the routing information/frame unencrypted, and only the command portion encrypted?

            3 - Similar question, but in an S2 unauthenticated, authenticated, access control situation. Can an S2 unauthenticated node relay/route a command for an S2 authenticated node? Can an S2 authenticated node relay for an S2 access control node?


            Thank you for this write up and information, it's changed how I'll manage my z-wave network.

            Comment


            • #7
              The command to lock the routes could be added to Z-Seer, not sure that its a good idea. You could easily lock some bad routes so it might go more harm than good for many users. Maybe add it as an advanced feature.

              Routing is done independently of the security. S0 and S2 are only used in controlling the end node hardware.

              Originally posted by Fellhahn View Post
              1. - Regarding Z-Seer, the Z-Seer documentation states the Z-Wave protocol allows for a command to "lock" all routes on a network. This would theoretically allow a user to build all routes manually and have them stay that way. How can a HomeSeer user issue the command to lock the z-wave network?

              2 - Regarding S2 security. S2 devices are issued an S0 key at inclusion in order to facilitate backwards compatibility. But what is the situation when a controller needs to route commands for an S2 node through an S0 node? Ie controller is direct to an S0 node, and the S0 node provides the hop to an S2 node. Can the S0 node relay the command, or is it not possible because it does not have an S2 key? Or is the routing information/frame unencrypted, and only the command portion encrypted?

              3 - Similar question, but in an S2 unauthenticated, authenticated, access control situation. Can an S2 unauthenticated node relay/route a command for an S2 authenticated node? Can an S2 authenticated node relay for an S2 access control node?


              Thank you for this write up and information, it's changed how I'll manage my z-wave network.
              website | buy now | support | youtube

              Comment


              • #8
                Originally posted by rjh View Post
                The command to lock the routes could be added to Z-Seer, not sure that its a good idea. You could easily lock some bad routes so it might go more harm than good for many users. Maybe add it as an advanced feature.

                Routing is done independently of the security. S0 and S2 are only used in controlling the end node hardware.


                Thanks for clearing that up.

                Adding the 'lock routes' to Z-Seer certainly seems like a more fail-safe option than placing it in HS3 itself. Anyone who's already using Z-Seer is likely paying close attention to z-wave operations and not just mucking around.

                For what it's worth (I know I'm only one voice and this would cost time), I would appreciate the addition of this function if possible.

                Comment


                • #9
                  Also while I've potentially got your attention, any chance you're able to answer my other Z-Seer query ('D-' vs 'U-' hops) posted here?

                  Comment


                  • #10
                    Thank you so much for this , I had lots of issues and I was doing lots of optimizations , did what you suggested and got no errors from the first connectivity test , will keep testing for a week

                    Comment


                    • #11
                      So I preformed the procedure above. Did the Connectivity Test, and there are 2 Zwave+ devices that are not talking which are the furthest away from the Stick+
                      I then chose the closest communicating + device, did a Full Optimize... rand the Connectivity Test again, boom, sees both of the devices! However, I can only communicate with them 1 time... then they lose connectivity again. Example, one is a Dimmer, I was able to turn the lights ON, and that was it... not able to dim or turn off after the first communication.

                      I then went back to the Connectivity Test... and both of the 2 devices are not communicating anymore. I then go back to the + devices that I Full Optimized... and would not optimize anymore. I did Test Connectivity and that works... tried Full Optimize again... nope.

                      I tried turning off the plugin then back on... I Restarted the Interface (Zwave+Stick)... tried to Full Optimize again, and that did'nt do it either.

                      I ran the full Connectivity test again a few times, and now it's erratic with random devices not wanting to communicate... one's that did, dont anymore... run it again and they do. No idea why.


                      I then preformed the Backup/Restore procedure again. Then the Connectivity test... all nodes are working except those 2 again. I went to the + device again to Optimize, nope... I try Full Optimze too... nope. So I have no idea WTF is going on.

                      Thoughts?


                      Comment


                      • #12
                        Originally posted by Integraoligist View Post
                        So I preformed the procedure above. Did the Connectivity Test, and there are 2 Zwave+ devices that are not talking which are the furthest away from the Stick+
                        I then chose the closest communicating + device, did a Full Optimize... rand the Connectivity Test again, boom, sees both of the devices! However, I can only communicate with them 1 time... then they lose connectivity again. Example, one is a Dimmer, I was able to turn the lights ON, and that was it... not able to dim or turn off after the first communication.

                        I then went back to the Connectivity Test... and both of the 2 devices are not communicating anymore. I then go back to the + devices that I Full Optimized... and would not optimize anymore. I did Test Connectivity and that works... tried Full Optimize again... nope.

                        I tried turning off the plugin then back on... I Restarted the Interface (Zwave+Stick)... tried to Full Optimize again, and that did'nt do it either.

                        I ran the full Connectivity test again a few times, and now it's erratic with random devices not wanting to communicate... one's that did, dont anymore... run it again and they do. No idea why.


                        I then preformed the Backup/Restore procedure again. Then the Connectivity test... all nodes are working except those 2 again. I went to the + device again to Optimize, nope... I try Full Optimze too... nope. So I have no idea WTF is going on.

                        Thoughts?

                        Sine the two recent Z-Wave plugin updates I'm getting similar reliability problems with mains powered Z-Wave+ devices. I did a connectivity test before seeing this thread and most of my outlying devices were failing. I'm going through doing single device connectivity testing and full optimisations and the devices can be contacted via that route.

                        With regard to the backup/restore guidance, I have backup up the interfave OK but cant find an oprion to restore. Is it the option to "Erase this interface and create a new network"?

                        Dave

                        Comment


                        • #13
                          Originally posted by Fatlab View Post

                          With regard to the backup/restore guidance, I have backup up the interfave OK but cant find an oprion to restore. Is it the option to "Erase this interface and create a new network"?

                          Dave
                          It's in the z-wave plugin actions just below backup.

                          Click image for larger version

Name:	Capture.PNG
Views:	583
Size:	48.0 KB
ID:	1263210
                          -Wade

                          Comment


                          • #14
                            This may not be the correct place to post this question. I apologize in advance if it should be posted elsewhere.

                            I was reading the post about zwave network optimization. This question is specifically about the part about determining the firmware version and being zwave+ or not.

                            I have 4 nodes that are not zwave+. One is an everspring motion detector that I am not concerned about. 2 are Schlage BE 468 zwave deadbolts and my Trane XR524 Z-Wave Thermostat. All are working fine so it might be a why are you trying to fix something that is not broken situation. I was wondering if there were firmware upgrades for these units that would upgrade them to zwave+.

                            I have been to both the Schlage and the Trane websites and could find nothing regarding firmware.

                            First if anyone knows of firmware for these units, where do you get it from and then how do you install it? If it not available, do I really need to be concerned about it? If I don't need to be concerned about it now, when would I and why would I want to spend the money to upgrade them to something that is the latest zwave standard?

                            thanks in advance for any response and insite.
                            Chuck

                            Comment


                            • #15
                              Originally posted by cfrudolphy View Post
                              This may not be the correct place to post this question. I apologize in advance if it should be posted elsewhere.

                              I was reading the post about zwave network optimization. This question is specifically about the part about determining the firmware version and being zwave+ or not.

                              I have 4 nodes that are not zwave+. One is an everspring motion detector that I am not concerned about. 2 are Schlage BE 468 zwave deadbolts and my Trane XR524 Z-Wave Thermostat. All are working fine so it might be a why are you trying to fix something that is not broken situation. I was wondering if there were firmware upgrades for these units that would upgrade them to zwave+.

                              I have been to both the Schlage and the Trane websites and could find nothing regarding firmware.

                              First if anyone knows of firmware for these units, where do you get it from and then how do you install it? If it not available, do I really need to be concerned about it? If I don't need to be concerned about it now, when would I and why would I want to spend the money to upgrade them to something that is the latest zwave standard?

                              thanks in advance for any response and insite.
                              Chuck
                              There’s no way to upgrade them as it involves both hardware and firmware. For battery powered devices, that do not participate in routing packets, I can’t see any value in replacing them if they are still working fine.
                              HS 3.0.0.548: 1965 Devices 1146 Events
                              Z-Wave 3.0.1.262: 122 Nodes on one Z-Net

                              Comment

                              Working...
                              X