In case anyone is contemplating the Z-Stick upgrade to gen5, here are my experiences of doing this:
First, the responsiveness of Z-wave in my system has increased after the transition. It used to take a long time, for example, to re-program a set of PIN codes for my door locks, now the command completes quickly. My success rate of z-wave commands seems higher.
Switching out the old controller for new at the computer was pretty easy. Just unplug the old one, plug in the other, then go to Interfaces>Z-Wave>Configure... and select "Connection type" of "Local" and serial port of "usbmodem31". Indigo is now ready to use the new controller.
Now comes what (for me) was the hardest and most tedious step:
All your z-wave devices that you previously had setup in Indigo are "orphaned" in that their z-wave node ID's are not yet set up in the new controller - they display grey'd-out in Indigo's device list. So you have to go device by device and pair your devices with the controller, then take the existing Indigo device and re-connect it to the z-wave node ID in the new controller. You have to do this for every z-wave device. You could in theory re-pair all of your z-wave devices, then fix the Indigo device definitions later, but I found it easier and less prone to confusion to do all the steps for one device before moving on to the next and would recommend this especially if you have multiple instances of the same type.
So for each device that was previously linked to your old controller, you have to do the following three steps: 1) "exclude" device (which basically means telling the device to discard its memory of the previous controller that it was linked to). 2) "include" the device with your new controller, which assigns a device to one (or more) z-wave node-id(s) in the new controller. 3) re-configure the existing device definition in Indigo to tell it to use the new z-wave node-id that you assigned in step 2.
Exclusion. Exclusion can be done either by the old z-stick controller or the new one. That is good if your old unit fails. For most of my devices I tried, it seemed that exclusion could only be done by bringing the controller and the device into close proximity with the controller. Naturally, this means either the device has to go to the controller (attached to computer) or the controller has to go to the device. If you left your z-stick attached to your computer, you can initiate exclusion mode from Indigo (Interfaces>Z-Wave> Start Exclusion Mode). You'll see a message in the log window indicating that the Exclusion mode was started. When exclusion of each device is successful, you'll see a log message saying that exclusion mode stopped.
If you have devices such as wall switches or other devices built-in to your walls or wired in to equipment, you're not going to want to have to remove and disconnect them to take them to your computer. Even if you could do that, there's also the question of how you can power these devices to deal with (e.g. for hard-wired devices like wall switches). For these cases, you can remove the z-stick from the computer and take it to the devices. See z-stick instructions for details, but basically pushing the z-stick button once puts it in Inclusion mode. Pushing and holding for two seconds engages exclusion mode.
After initiating exclusion mode on the controller (whether directly on the z-stick or via Indigo), you then have to tell the device to react to the controller's exclusion request. It was frustrating that across my z-wave device types, this was done in a different way for each type. For some units, there was a single, obvious external button and you just pushed it. For other units, there was a non-obvious technique requiring inserting of a paper clip to double-click a tiny hidden internal button. There's really nothing to say generally here other than that you should be prepared and download the owner's manual for devices to remind yourself the technique for each device you own. Each device type also had its own types of feedback for a button being pressed success or failure of exclusion, etc. Some devices showed a pattern of LED flashes when successful. This is helpful to know, because I found that there was less than 100% reliability for attempts at exclusion/inclusion generally. It seemed to take a few tries in a some cases for my devices. It could be just random transmission failures, but also some devices seemed like they really need to be close to the controller (e.g. less than a foot) before they will respond (this I guess is a type of security feature to make it harder for someone walking by to casually re-pair devices in your network). Again, there is no substitute for checking the manual.
Taking the z-stick to the devices is a handy shortcut, but my understanding is that this only works for unencrypted connections. I haven't experimented much with this, but I generally like the idea of using encryption to communicate between Indigo and devices. I presume that this might make it harder for someone to packet sniff my network and know that I just turned down my thermostat or use simple attacks to replay commands and usurp control of my devices. One situation where you can only use encrypted communication is for door locks, of which I have several. As you would expect, these are "built-in", i.e. somewhat intricately attached to and integrated with the doors of my house. So in these cases, I had no choice unfortunately but to remove the z-wave receiver part of the lock from the door and transport it to my computer where I performed the exclude, re-include process. This was a pain and is not something I would want to have to do again.
Inclusion. Notes here are basically the same as for Exclusion. Typically whatever button push or poke or whatever that you do on the device is the same for both. When adding lock devices, you MUST use the "Start Inclusion Mode with Encryption" command instead of regular inclusion. I was curious (but did not experiment) to see whether my other non-lock devices would also support inclusion with encryption - I may revisit this in the future. If you initiate inclusion from Indigo, you will see a message in the logs indicating the node-id (an integer, starting at 2 and increasing with each included device) - it may be useful to take note of this for the next step.
Reconfiguring Indigo Devices At this point, you have your existing "orphaned" Indigo device and you have a newly included z-wave device with a (potentially different) z-wave node-id waiting to be assigned. You want to edit the existing device in Indigo, then hit the "Define and Sync..." button. From here you'll get a z-wave dialog where you need to carefully select the node-ID from the list. The list will show the integer node ID and general type of all unassigned devices, so if you made note of the node-id of the newly added device in the inclusion step above, you're all set. Otherwise, there will be a generic z-wave device category listed for your device that you may or may not recognize as belonging to the device you are trying to configure. A final clue is that as far as I know, the most recently included device will always appear as the device with the largest integer node-ID (this is the main reason I recommend doing this one device at a time). Select the correct Node-ID. Hit "OK". Indigo will perform it's sync process, communicating with the device, configuring it, etc.
Other caveats, issues, and random notes:
My understanding is that some (newer?) devices support something called network-wide-inclusion where you can use the usual z-wave repeating function to convey the exclusion and inclusion commands between controller and device. I tried a few devices and it didn't seem to work for me, so I gave up trying after a few failures. There's also the chicken-egg problem that network-wide-inclusion can't really work if you don't have any devices in your network yet. Most of my built-in devices and experience are with Insteon, which has a completely different set of procedures, quirks, and caveats for its version of the "pairing" procedure. A key takeaway for me from this process is that I would check carefully whether the entire chain of {target device, z-stick, other mesh devices, Indigo} had full and reliable support for the network-wide inclusion feature (including encryption). I personally won't install any additional built-in/hardwired z-wave devices until I learn that this is better supported.
My experience with trying to use inclusion/exclusion remotely may have been a "bootstrapping" problem -- when I tried (and failed several times) it could have been because I had not yet added enough (or the right kind) of nodes to my network to act as repeaters to make this work. I'd like to hear others' experiences with this.
It is convenient that the Indigo device objects for all of your devices will exist throughout this process, thus any triggers and schedules you had set up previously that reference these devices should resume working after you're done.
At any point during the process of iterating through the 3-step process described above with each of your devices, you may want to "optimize" the Z-wave network. This is initiated from Indigo via Interfaces>Z-Wave >Optimize Z-Wave Network... I believe this basically reaches out from the controller, asks all nodes to respond, then those nodes ask all nodes that can hear them to respond, etc. and the result is that (ideally) a full tree is worked out such that the controller can reach every node, potentially via multiple "hops". The optimization process is slow and (for me) takes up to a couple of minutes. You want to do this when your devices are positioned where they are going to be used. This can sometimes fail to reach all nodes. It may also be that as you are going through and adding your devices one by one, there may even be intermediate stages along the way where some of your devices can't be reached. Presumably, by the time you get to the end of the process and add back the same set of nodes, your network should come back to full operation. I'm told gen5 z-stick range and power for transmitting are increased over the older version.
There are complexities in terms of devices that have multiple sub-devices or whatever you want to call them. For example, some of my z-wave multi sensors are represented in Indigo as 5 devices. These work easily in that once you configure the "base" device (in my case of a z-wave multi-sensor, it was the Indigo motion-sensor device), all of the other devices are fixed automatically. On the other hand, I have two Somfy z-wave bridge units (ZRTSI) and these are much more complex to deal with (each unit uses up to seventeen separate z-wave node-ID's) - a topic worthy of a separate post.
I think that some Z-Wave devices when they are excluded from a network reset themselves to factory default parameters. So for example, when I migrated a group of multi-sensors, I noticed that they showed up reporting temperatures in Celsius (not my preferred config and not what they were set for before the migration), and had all their sensitivity values and other parameters reset to their defaults. So you may need to either go into the "Edit Device Settings..." dialog off the edit window for the Indigo device OR use the Interfaces>Z-Wave>Modify Configuration Parameter... to set the device back to your preferred configuration. This can take some time if you have multiple devices, each with multiple parameters to be set.
My takeaways of things that could be better:
- Indigo should embrace a means of backing up configuration on a z-stick such that it can be copied or restored to another. Apparently software exists on Windows now <- existence proof.
- It would be good if Indigo could also make parameter settings for Z-wave devices "stick" such that they can be re-applied if/when needed (much the way Indigo lets you make Insteon links "persistent" in the current software).
- Indigodomo, Aeontec, and all other Z-wave vendors should ensure there is consistent and reliable support for network-wide inclusion - without this, there are obvious limits to the practicality of full home automation with Z-Wave.