Announcement

Collapse
No announcement yet.

Pearls of Z-Wave Knowledge

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

  • Pearls of Z-Wave Knowledge

    • RARELY is it a good idea to erase your primary controller and re-load the configuration from backup, or even start from scratch and re-add all of your nodes to a network. The reason is that controllers in the network, including your HomeSeer interface, store information about which routes worked for getting Z-Wave frames to their destination. Also, optimizations cause route information to be updated/replaced, and routing nodes typically will save 4 of these routes and will try all 4 to get a frame to its destination, even if the destination is the HomeSeer primary controller. Erasing a controller and reloading it wipes out ALL of this information, and since it is information built-up over time, erasing it sets you back much more than it can help.
      -------------------------------------------------------------------
    • People almost always forget to update their handheld or in-wall static controllers (scene/zone controllers) when they add or remove a node to/from the network. These types of controllers do not update their routing information through optimization, and the only way they learn of new nodes is by replication - the process of having the primary controller send the network information to them. Whenever you add or remove a node from the network, update your handheld controllers by doing a replicate send to them, so they can now control the new nodes, and update your static controllers by repeating the "add to network" procedure for them - since they are already a part of the network, they will skip the add procedure and will go directly to the update replication so that they can learn about the nodes recently added or removed from the network.
      -------------------------------------------------------------------
    • When you add a new node to the network with your primary controller and then re-connect the controller to your HomeSeer computer and do an import, the controller is no longer near the new nodes, and in many cases no longer has direct communication capability with the new nodes. Thus, when HomeSeer interrogates the new nodes it will often fail, resulting in HomeSeer not seeing the node type for what it is, or creating less scene buttons than it should have, not creating proper child devices for technologies that the node uses, etc. This is all to be expected when you add a node that may be far from HomeSeer. The procedure to fix this is pretty straightforward. You can remove any/all of the child devices that were created in error. Then, go to whatever root device that HomeSeer created, even if it does not look right, and click the Optimize button. Do this several times so that a route is established between the HomeSeer controller and the new node. In some cases, it may be necessary to first optimize some of the nodes that are around the new node so that other nodes in the network are aware of it and can help route the optimization command from HomeSeer to the new node. Once you have had 2-3 successful optimizations of the new node, go to the properties for the (root) device and click "Rescan" - the child devices will likely be created properly now. You can then use your normal procedure for keeping your Z-Wave network routing healthy and further integrating the new node into your network - e.g. regular network optimizations or Z-Health.
      -------------------------------------------------------------------
    • A routing slave node, which is different from any other node that does not have "routing" in the node type, maintains 4 node numbers that it can send a frame to in order to get it to a destination node. For example, if you are trying to reach node 20, the routing node might have these 4 numbers: 32, 16, 10, 27. Each of these is a node that the routing slave will send a frame to that will in turn route that frame to node 20. For each node in the network, the routing slave maintains these 4 node numbers as a starting point. (That is an over simplification of what it stores, but it suits this purpose.) If a routing slave has not had 4 successful optimizations, then it may not have enough routes to try, and we simply do not have enough technical knowledge about Z-Wave to know what it will try to do. We do know, however, that having 4 good routes is a key element to having reliable communications. If you remove a node from the network, that node may have been used in a route for other nodes, even if they are seemingly too far away to be of use in the routing. Z-Wave nodes have NO idea of the layout of your home and do not communicate to nodes just on the same floor - it is a 3-dimensional communication model to them, and it could include nodes that are far away from the source and destination nodes. For this reason, we invented Z-Health - if you remove a node from the network, Z-Health will eventually get all of the nodes new routes that no longer include that removed node.
      -------------------------------------------------------------------
    • When HomeSeer sends a command to a node (such as "What is your current level?"), regardless of whether the node is a routing slave or not, HomeSeer's controller picks the route that it uses to reach the node, and the node will always respond with an "ACK" (acknowledgement) if it received the command, using the same route that HomeSeer used. However, in the case of a slave node, when sending the response to HomeSeer (such as "I am at level 75"), will choose its OWN route to get the response to HomeSeer. This is why, if the slave node does not have good routes, it is ENTIRELY possible for HomeSeer to successfully deliver a command to a node, while the node seemingly fails to respond to the command.
      -------------------------------------------------------------------
    • The "Magic" inside the Zensys' library that determines the route a controller will take to send a frame may remain a secret to all but Zensys employees, but what we DO know is that a static controller determines the route completely differently from that of a portable controller. There are HomeSeer controllers that use the static library, such as the Aeon Labs Z-Stick II or the original HomeSeer USB interface. Static controllers will not have the "Backup" and "Restore" network options on the manage Z-Wave controller page because they can only exchange network information with another controller through replication. Other types of static controllers include the in-wall zone and scene controllers such as those by Leviton and Cooper Wiring. A portable library controller is also called an "installer" library controller because as they name implies, it is designed such that it never knows where it is in the network, and is used typically in a handheld controller that you would use as an installer to add or remove nodes from the network. The installer library controllers, if they are your HomeSeer interface, have "Backup" and "Restore" network options because network information can be programmed into an installer library controller. Because there are differences in how an installer library controller and a static library controller send their information to a destination node, there is some speculation that the way you set up your Z-Wave network can affect the performance of the controller. Unfortunately, Zensys does not publish this information in case they modify how the library operates. However, one piece of information that should not change is that because an installer library controller does not know where it is at any given time, it will start with a low number Z-Wave node and work up the numbers in attempting to deliver a frame. (After trying direct communication first.) Thus, if you do not have any holes in your node numbers and the controller is node 1, in trying to reach node XX it will first try node 2, then node 3, then node 4, etc. For this reason, you should not add your nodes, when you are building a network from scratch, by adding all of the nodes near the controller first. That would leave all of the low numbered nodes near the controller, which would mean that those nodes likely could not reach the far away destination nodes, and that would force routing to take place much more often than necessary. Rather, add nodes (when creating a new network with an installer library controller) by jumping around the house to different locations. Add the first node as one a medium distance from the interface, the next one being far from the interface, the one after that being a close distance from the interface, and then perhaps return to a node a medium distance from the interface. Scatter it around so that if the controller has direct communications with node 2 and it is in the middle of the house where node 2 then has direct communications with most other nodes in the house, the controller may establish node 2 as its frequently used node for nodes it cannot reach directly, and that may limit the number of "hops" or routes to being only two. You should not rework your network if you remove node 2 or do anything to try to force this, but it should work to your advantage if nodes are added as described above so that you will not have any problems in the long run of using your network. Also note that while there are some good interfaces out there and an RS-232 port is not always convenient, the RF characteristics of the HomeSeer Z-Troller interface make it one of the better controllers for reaching nodes directly because of the way the antenna was designed in the unit.
      -------------------------------------------------------------------
    • When you add a new wall scene controller to your network, the first thing you do after adding it to your network and importing it into HomeSeer is to press a button, then go to the HomeSeer status page, click "Refresh", and expect to see the corresponding button device to be "On"... but it doesn't happen. Come on, you know you've done that. The thing is, the button's purpose in life is to send out a scene activation command. To do that, it has to be programmed with a scene, and that means assigning a scene ID to it and then programming the devices in the scene with the scene ID. Thus, even if you have no devices to add to the scene, you must go to the scene configuration for each button and at least click the "Save Scene" button at the bottom of the page. Besides assigning a Scene ID to the button, it also automatically* adds HomeSeer to the scene, and THAT is how HomeSeer will know when the scene has been activated and turned OFF. Now go ahead and do that, and THEN you can play with the buttons!
      * If the option "Prevent HomeSeer Associations" (available in 3 different places) is enabled, then HomeSeer is NOT automatically added to a scene.
      -------------------------------------------------------------------
    • RF is RF, and you might think it stands for Radio Frequency but in fact it stands for "Really Funny" in how it propagates through your home. Because Z-Wave already makes use of multiple routes, and because the simple act of putting a metal frying pan 6" farther left in a cupboard than normal can change an RF path, understand that a perfectly good operating network can completely change the next day to something horrendous. For this reason, you need to have lots of nodes available for routing alternatives, and you cannot rely on the inherent nature of Z-Wave to provide the alternative routes - frankly, it does a lousy job as it only updates routing information when a new node is added, and it only updates the nodes around the node newly added. Use HomeSeer's network optimization and Z-Health tools, along with plenty of Z-Wave nodes, to provide the most options for routing to take place when the simple presence of people or changes in the frying pans in your home can throw RF for a loop.
    Last edited by Rick Tinker; February 21st, 2011, 04:04 PM.
    Regards,

    Rick Tinker (a.k.a. "Tink")
Working...
X