ControlThink Forums

That seems to have done the trick.  I'm getting pretty good at rebuilding my network from scratch, and that is what I did.  This time I did the whole thing, including resetting the dongle, with ThinkEssentials.

I ran the optimization utility from the bat cave (I wanted to believe you Chris, but rebuilding the network isn't so fun that I was willing to risk the HA22 adding itself to the routes), and while it was running I ran upstairs to keep the CA9000 PIR and HRDS1 door/window sensor awake.  After the optimization I re-added the RZC0P, which is attached to my system controller, and then I used the PC SDK to add the RZC0P to everybody else's association group.

The HRDS1 is now working more consistently than it ever has.  The PIR is dead.  I think it might have slept through the most important part of the optimization.

Question:  If I want to focus the optimization on the PIR without the risk of losing my route to the HRDS1 can I pull the batteries out of the HRDS1 and re-run the optimization with just the PIR?  Or will the optimization then assume that the HRDS1 is dead and remove its route?

Wait; never mind.  I just walked into the other room, and the PIR triggered its event.  The CA9000 must take 10 or 15 minutes to regroup after the add/optimize/associate ordeal.

Now that it appears that ThinkEssentials (and perhaps the Leviton RZCPG) is the only way to do sensor routing, I have a few requests (and maybe this is what ThinkEssentials Pro is all about):

1. I want to see my routes, and maybe even the quality of each hop.
2. I want to see what routes get beamed to my sensor when I add associations.
3. I want ThinkEssentials to do the associations for me (the utility I wrote using the PC SDK is kinda klunky)
   
4. I want to be able to manually tweak a route, especially if a sensor goes to sleep and misses out on the optimization
5. I want to be able to focus the optimization on a single sensor without the risk of losing known-good routes to other sensors.

If this is what ThinkEssentials Pro is all about, please sign me up!

Thanks for all of your help Chris and for the great tools.

Now if these sensors will just stay connected to the network over night... 

By the way, the "Bat Cave" is a 20-foot long concrete vault under the front porch.  My wife calls it the "fruit room."  Other folks might call it a tornado shelter or in NYC, a fallout shelter (are you sure you want to move?).  I think if you have a Z-Wave node in the bat cave, it might be a routing end point, but never a "hop."

garylm,

We're working on an update to ThinkEssentials Pro which will address at least three of your five requests.  At least one will also be included in an update to the Standard Edition, but the Pro edition is going to gain more and more power :)

Chris

Another question:

If I add a device to a sensor's association group (and at the same time the SDK sets the return route to the associated device), then that sensor knows how to route messages, generated by an event in the real world, back to the associated device.  Such messages are not in response to any query from a controller.

If a controller queries that same sensor, and the controller is not necessarily in that sensor's association group, and as a consequence, the sensor does not have a cached return route to the controller, how does the sensor know how to route responses back to the controller that originated the query, especially if "hops" are required?

Is there a difference in how sensors route messages generated unilaterally and messages generated in response to a controller query?

If a query from a controller to a sensor requires "hops" to get to that sensor, is each hop recorded and added to the trasmitted packet, and then that hop record used when the response to the query navigates its way back to the originating controller?  If so, it shouldn't make a difference If that originating controller is also found in the target sensor's association group, along with a return route to the associated device; it should use the hop record from the query, not the association return route.

I'm really struggling with one of my door/window sensors.  I thought I was getting poor response because there was too much metal nearby, but today after moving the sensor away from the metal and re-optimizing the network, it's still working no better.  This sensor has two line-of-sight wired devices, which should be routing my sensor's messages.

I've got another door/window sensor in the garage that works flawlessly, with only one line-of-sight wired device, and several hops back to the controller.  Strangely, when I take my troubled sensor out to the garage, it also works flawlessly without re-optimizing and without resetting the return route table.

When running the optimization using ThinkEssentials Pro, I can click on "more information" and the node numbers will be displayed as the network is scanned.   I never see the node numbers for any of the battery-powered binary routing sensors.

I'm curious to know if the battery-powered devices are included in the optimization routine.  When an association is set and return routes are stored on the battery-powered device,  we are limited to four or five valid routes.  How does the SDK decide which of the many valid routes to hand over to the sensor?  Shouldn't that subset of valid routes include line-of-sight devices or devices that picked up the strongest signal from the sensor during the optimization?  The wired device in the garage should certainly not be in my troubled sensor's routing table.  It's about as far away from the sensor as I could get when the network was optimized.

If I had to guess based on my observations, I would guess that sensors are not involved in the network optimization.  And the subset of valid return routes handed over to the sensor is just the first four routes of many whose endpoint is the associated controller.  If you are lucky, your sensor can actually hit one of the nodes in the routing subset.

It's all a mystery to me.

It would be nice if there was a tool to hand-enter on a sensor, line-of-sight routes that are sure to be valid.

Because motion sensors turn off their radios when not communicating, there's no easy way to rediscover their neighbors during the procedure.  That's why they're currently left out of the optimize operation.

Please note that the optimize/repair feature currently only optimizes the topology map inside the USB stick.  To copy the updated map to controllers, re-add them to the network (press "Add Device" in ThinkEssentials or use ZWaveController.AddDevice()).  To update the routes in the sensors, simply re-add the target devices to the sensor's association group.  Or for good measure, clear out the target device's association groups and re-assign.

Chris 

Chris Walker:

...the optimize/repair feature currently only optimizes the topology map inside the USB stick...

To update the routes in the sensors, simply re-add the target devices to the sensor's association group.  Or for good measure, clear out the target device's association groups and re-assign.

I suppose that for each associated device there is a finite number of return routes that can be stored in the sensor.  If the USB stick doesn't know who the sensor's neighbors are, then it's just going to pass a list of hard-wired nodes that are able to route to the associated device, without regard to whether any of those nodes are neighbors of my sensor.  If the sensor has finite storage for return routes, and if the one good neighbor route is at the bottom of the list, then the sensor may not be able to store that one good route.

I guess the answer to my problem is to rebuild my network from scratch, starting with a small subset of nodes that are line-of-sight to my sensors.  And then run the optimization routine with just those nodes in order to keep the routing table small that will be passed to the sensors when I add devices to their association groups.  After the association groups have been built, then I can add all the other devices, re-optimize the network, and re-add the main controller, being careful to never mess with the associations on my sensors again.

I'll give it a try.

And this would be the drill every time I add a new sensor to the network.  There's got to be a better way. 

garylm,

We're working on some advanced functionality in this area; stay tuned...

Chris

Chris Walker:

Because motion sensors turn off their radios when not communicating, there's no easy way to rediscover their neighbors during the procedure.  That's why they're currently left out of the optimize operation.

From the Z-Wave Node Type Overview and Network Installation Guide 2007-03-20:

In the following example we want to associate the Static Controller with the Routing Slave 3. In the
example it is assumed that the Static Controller can only reach Routing Slave 1 and Routing Slave 2
directly. Also for the Routing Slave 3 it is assumed that it is able to reach Routing Slave 1 and Routing
Slave 2 directly, but not the Static Controller.

The Association is done as described in the previous example, by first moving the Portable Controller
within range of the Static Controller, and then activating the static route initiator on the Portable
Controller and the associate initiator on the Static Controller. Secondly the Portable Controller is moved
closer to Routing Slave 3. When the associate initiator on the Portable Controller and the initiator on
slave 3 have been activated, the Portable Controller will calculate routes from Routing Slave 3 to the
Static Controller. In this example the Portable Controller will come up with two alternative routes. The first
route is to reach the Static Controller through Routing Slave 1. The second route is to reach the Static
Controller through Routing Slave 2.

When they say "the Portable Controller is moved closer to Routing Slave" do they mean that the portable controller is then acting in the place of the routing slave for purposes of route calculation, or do they mean that the portable controller has to be close to the routing slave in order to hand off the return route to the slave?

So I would put my ThinkStick close to the door/window sensor, then I would tell ThinkEssentials that I want to calculate the route from the door/window sensor node back to the static system controller node in the basement wiring closet.  The ThinkStick then acts as the door/window sensor node and finds the strongest signal path back to the static controller.  I then add the static controller to the door/window sensor's association group and transfer the return route that I just calculated to the door/window sensor.

How are the hundreds of pro installers out there doing this?  We haven't heard a peep out of them about any troubles assigning return routes to sensors.  Are they using some other tool?  Does the ZTroller do this?

garylm,

It doesn't matter where you're located.  The description there refers to how portable controllers know which two devices to link to each other: you go next to each one and press its "program" button.

In the case of software, and in particular with the SDK, using the ZWaveDevice.Groups functionality does the exact, exact same thing.

Chris

I'm thinking that if I knew more about how return routes are stored and used on the routing slave devices, I might be able to change the way that I'm setting up and optimizing my network to make these battery-powered devices more reliable.  It's probably proprietary information, but I'll ask anyway.

Does the return route back to the associated static controller, which is stored on the battery-powered device, comprise a table, with a table entry for each of several parallel routes between the static controller and every other device in the network? 

Between any two nodes, if multiples paths are possible, do multiple table entries between those two nodes appear in the routing table?

Do the individual "hops" between any two nodes also appear in the routing table?

Does the battery-powered device care about the hops connecting his neighbor back to the static controller?

Do the routing hops appear in some sort of message header generated by the battery-powered device, telling everyone on the return path where to send the message next?

If the battery-powered device doen't know about the hops but only the destination, can the intermediate devices in the route figure out where to send the messages?

If nodes appear in the battery-powered device's routing table that are not neighbors of the battery-powered device, how does the battery-powered device know to avoid those out-of-sight nodes?

If hops are part of the routing table on a battery-powered device, what is the maximum number of hops allowed for a single route?

If parallel routes are part of the routing table, what is the maximum number of parallel routes allowed in the table?

If unused, non-neighbors are part of the routing table, what is the maximum number of total routes allowed in the table?

How will the battery-powered device respond when we overflow its routing table?  Will it store as many routes as it can?  If none of those routes includes a neighbor device, what will be the observed behavior? 

Moving away from the term "routing table," what we have in Z-Wave is a topology map.  Basically, this map knows which devices were in direct range of other devices when they were added to the network (or the network was rediscovered).

Controllers typically get a full copy of this topology map--which gives them the ability to try potentially dozens of routes to reach a target device.  Slaves (i.e. generally motion sensors and simpler devices) instead get a list of a few potential routes to reach their linked target devices.

In the end, the best answer to solving a puzzle like the one you're looking at is to analyze what is really going on in the network and then finding a way to solve it in code so that the problem is solved in many homes.  Of course, you can play with setting up your network with just devices you want in the potential routes, setting up the links (associations) and then adding in the rest--which may yield the best results for you today.

Does that help?

Chris

Thanks Chris,

That mostly helps.  But it also leads to another question:

Slaves (i.e. generally motion sensors and simpler devices) instead get a list of a few potential routes to reach their linked target devices.

Could you offer any clues as to how this trimmed map is generated and what I might do to improve the chances that there will be good neighbors on that map?

Last night I went extreme, and I didn't notice any improvement.  I stripped my network down to nothing, then added the static controller, three sensors, and a line-of-sight wired device for each sensor.  Then I moved the static controller close to the first wired device, covered the other two wired devices with aluminum foil and ran wires from the foil to the ground on AC outlets.  Then I re-optimized my network, hoping that the only node that could see the static controller would be the node without the foil.  Then I added the static controller to the association group of the sensor within line-of-sight to the node without the foil.  I repeated this process for the other two sensors, moving the static controller around, covering the unwanted nodes with foil, and re-optimizing the network each time before creating the association.  I guess when I moved the static controller back to the wiring closet and re-optimized the network with all devices added and uncovered, that the maps on the sensors were no longer valid.

That document that I cited in this morning's post gave me an idea about how to trim the map that gets transferred to the sensor:  hang the ThinkStick where the sensor is, and have ThinkEssentials validate the trimmed map before setting the sensor's association group.  Go through as many iterations as necessary of trimming the map and evaluating signal quality with the ThinkStick standing in the sensor's shoes.

It looks like my sensors might finally be stable.  I built the network with the just the sensors and the essential, line-of-sight nodes.  I then ran the optimize routine, with the system controller (RZC0P) in its final resting place, and then transferred the map from the ThinkStick by re-adding the RZCOP to the network.  At first I tried setting the associations using the SDK and ThinkStick, but the messaging from the sensors was intermittent.  I then tried clearing and resetting the return routes using the RZC0P's >RO command.  This did the trick.  It kinda makes sense that if the RZC0P is the target device for the association, and the RZC0P is already talking to the sensor (sending >RO commands and receiving responses), that the RZC0P would be able to select a suitable subset of the map to load onto the sensor.

Maybe the RZC0P isn't really that smart.  Maybe I just got lucky.

Perhaps if I had hung the ThinkStick next to the RZC0P when I set the association using the SDK, perhaps the ThinkStick would have been aware of the live route it was using while setting the association, and generated the map subset based on that awareness.

My CA9000 and one of my two HRDS1s suddenly stopped communicating with the RZC0P today.  Thinking that maybe I had a brownout, and one of the wired Leviton routing nodes lost its map, I used ThinkEssentials and the ThinkStick to re-add those key routing nodes (without deleting them - the node IDs remain the same).  I re-added the devices one at a time and checked to see if sensor messaging resumed.  Finally I re-added the RZCOP.  Still no improvement.

The HRDS1 that stopped communicating runs on batteries, which I checked and found to be good.  The CA9000 uses a wall wart.  So it is unlikely that the two sensors went bad at the same time due to a power issue.  I haven't plugged the ThinkStick in or run ThinkEssentials for a few days.  So there's no chance that my ControlThink stuff could have sent bad routes to the sensors.

Paranoid thoughts popped into my mind that my Z-Wave sensors somehow automatically purge their return route maps every two weeks or that the RZC0P had sent bad routes to the sensors on its own (my software doesn't know about the RZC0P's RO command, so there is no way that my software told the RZC0P to send bad return routing maps to the sensors).

Thinking that I should try bouncing some commands off the sensors using a serial terminal, I unplugged the RZC0P and brought it upstairs within sight of my sensors.  I checked the sensors' association groups, and they were still intact.  Also, the RZC0P received every event message from the sensors. I was at a loss to explain this behavior.  I returned the RZC0P to its place downstairs in the wiring closet and plugged it back in.  Right away my controller started getting sensor events again.

So it wasn't a sensor or routing node problem at all.  Unplugging the RZC0P and plugging it back in seemed to do the trick.  Perhaps I need to put the RZC0P on a UPS.

Now someone please tell me why my other HRDS1 didn't stop communicating with the RZC0P.

Yeah, I know this isn't an RZC0P forum.  Same parent company though.