please guy, send me a pm with your mail address.
I hate forums where links are expired and this would certainly happen, if I used some sort of upload service.
What filetypes are attachable btw?
Cheers
Wilhelm
Network Shift Between Z-Wave Controllers
- Umtauscher offline
-
- Posts: 566
- Joined: Oct 03, 2014
- Location: Cologne, Germany
Re: Network Shift Between Z-Wave Controllers
- jay (support) offline
- Site Admin
-
- Posts: 18212
- Joined: Mar 19, 2008
- Location: Austin, Texas
Re: Network Shift Between Z-Wave Controllers
Umtauscher wrote:today I succeeded with transfering my complete network to a Aetec Gen5 stick without rebuilding my complete network.
I have made a howto to document how I did it.
It's a pdf but I cannot attach it. So ask and I'll send it to you..
You can always put it in the Contribution Library...
- Umtauscher offline
-
- Posts: 566
- Joined: Oct 03, 2014
- Location: Cologne, Germany
Re: Network Shift Between Z-Wave Controllers
Thanks, done.
(you don't make it easy, do you?)
To the others:
It will be in the misc. section when it is accepted. Sigh
I can't post a link now, sorry
(you don't make it easy, do you?)
To the others:
It will be in the misc. section when it is accepted. Sigh
I can't post a link now, sorry
- jay (support) offline
- Site Admin
-
- Posts: 18212
- Joined: Mar 19, 2008
- Location: Austin, Texas
Re: Network Shift Between Z-Wave Controllers
Umtauscher wrote:Thanks, done.
(you don't make it easy, do you?)
No, we spend extra time just to make things harder for you.
Umtauscher wrote:To the others:
It will be in the misc. section when it is accepted. Sigh
I can't post a link now, sorry
Approved. I zipped it up to save a little space on our servers and added useful information about what's required in the Installation section.
- dduff617 offline
- Posts: 659
- Joined: Jul 05, 2006
- Location: Massachusetts, USA
Re: Network Shift Between Z-Wave Controllers
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:
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.
- jay (support) offline
- Site Admin
-
- Posts: 18212
- Joined: Mar 19, 2008
- Location: Austin, Texas
Re: Network Shift Between Z-Wave Controllers
dduff617 wrote:
- 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.
We would love nothing better. But as we've mentioned several times on the forums, Aeotec won't release the details to us that are needed to implement this functionality. Without their cooperation (and other vendors as well) there's not a lot we can do.
dduff617 wrote:
- 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).
This is actually a large amount of work. We'll have to weigh the tradeoffs since implementing this functionality would require that we put off other things. We know that moving sticks is painful, but given the relative infrequency of having to do it, does it actually take precedence over added device support, new features, etc.
dduff617 wrote:
- 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.
Indigo Domotics can do absolutely nothing about this. NWI is part of the Z-Wave spec and we have no control over that other than implement NWI as specified by the spec (and, unfortunately, deal on a case-by-case basis devices that interpret the spec differently than other vendors). Believe me, we would absolutely LOVE for every device to behave exactly as all others of their class do.
- dduff617 offline
- Posts: 659
- Joined: Jul 05, 2006
- Location: Massachusetts, USA
Re: Network Shift Between Z-Wave Controllers
jay (support) wrote:dduff617 wrote:
- 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.
Indigo Domotics can do absolutely nothing about this. NWI is part of the Z-Wave spec and we have no control over that other than implement NWI as specified by the spec (and, unfortunately, deal on a case-by-case basis devices that interpret the spec differently than other vendors). Believe me, we would absolutely LOVE for every device to behave exactly as all others of their class do.
Ok, that's good to know. I sort of assumed you guys had gone as far as you could by including "Start Inclusion Mode" and friends in the Interfaces menu. This recent migration was my first time using those commands extensively.
One useful thing I discovered just now is that at the Z-Wave Alliance website, where they list products and their details, including Z-Wave certifications, you can select "Products", then select your region, you can use the "advanced search" feature to filter for products "Supporting Network Wide Inclusion and Explorer Frame". So for example, I am encouraged that I can find lots of door locks, thermostats etc. that all support NWI. The only drawback is that there is a skew between things listed as being Z-Wave certified vs. things that are actually available to buy today. By default, the product database shows products in order of reverse certification date (most recent first). It seems that (with some exceptions) you often have to search for things certified 6-12+ months ago before you start hitting things that you can actually buy. For US/North America, for example, see: https://products.z-wavealliance.org/Sea ... =on&order=
Another thing I wonder about is what role the repeater devices in the network play in terms of network-wide-inclusion support. That is, if Z-Stick Gen5 supports NWI (which I believe it does) and some new product I'm adding supports NWI, is that sufficient? Or do I need for the repeater devices in my z-mesh to support it as well?
- jay (support) offline
- Site Admin
-
- Posts: 18212
- Joined: Mar 19, 2008
- Location: Austin, Texas
Re: Network Shift Between Z-Wave Controllers
FYI, all of the Z-Wave interfaces on the Interfaces list support NWI. The majority (if not all) of new Z-Wave devices support NWI AFAIK - it's mainly the older ones that are hit-or-miss. I don't believe that routing devices have to support NWI (I think they ignore the contents of the packets being sent and just route them appropriately), but I could be wrong about that.
- jay (support) offline
- Site Admin
-
- Posts: 18212
- Joined: Mar 19, 2008
- Location: Austin, Texas
Re: Network Shift Between Z-Wave Controllers
I'm curious - did you find the Replacing your Z-Wave Controller section of the docs before you started your replacement?
- howartp offline
- Posts: 4559
- Joined: Jan 09, 2014
- Location: West Yorkshire, UK
Re: Network Shift Between Z-Wave Controllers
jay (support) wrote:dduff617 wrote:
- 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).
This is actually a large amount of work. We'll have to weigh the tradeoffs since implementing this functionality would require that we put off other things. We know that moving sticks is painful, but given the relative infrequency of having to do it, does it actually take precedence over added device support, new features, etc.
Dduff617, you’ve lost me here.
Could you elaborate on wanting parameters to stick?
“Such that they can be re-applied when needed” - they can, by editing the device and hitting OK as you’ve mentioned.
Sent from my iPhone using Tapatalk Pro
- Umtauscher offline
-
- Posts: 566
- Joined: Oct 03, 2014
- Location: Cologne, Germany
Re: Network Shift Between Z-Wave Controllers
I think what he means is, that all device after the exclusion and inclusion process "forget" the previously configured parameters.
In my experience that's true. That is why I didn't want to rebuild my network. I am heavily using associations and would have to redefine them all.
I have updated my howto:
http://www.indigodomo.com/library/411/
@Jay
I think there are many HA software products which are able to initiate a backup of the stick themselves. I cannot see why your firm might not be able to accomplish this.
( Razberry, OpenHAB, Domoticz and others can do it)
BTW the UZB backup is compatible to the Gen5 so I think the command is built into the firmware...
Cheers
Wilhelm
In my experience that's true. That is why I didn't want to rebuild my network. I am heavily using associations and would have to redefine them all.
I have updated my howto:
http://www.indigodomo.com/library/411/
@Jay
I think there are many HA software products which are able to initiate a backup of the stick themselves. I cannot see why your firm might not be able to accomplish this.
( Razberry, OpenHAB, Domoticz and others can do it)
BTW the UZB backup is compatible to the Gen5 so I think the command is built into the firmware...
Cheers
Wilhelm
- howartp offline
- Posts: 4559
- Joined: Jan 09, 2014
- Location: West Yorkshire, UK
Re: Network Shift Between Z-Wave Controllers
Umtauscher wrote:I think what he means is, that all device after the exclusion and inclusion process "forget" the previously configured parameters.
In my experience that's true. That is why I didn't want to rebuild my network. I am heavily using associations and would have to redefine them all.
Oh, I thought Indigo did know what values were set for params and reapplied them.
In that case, a simple parameter backup plugin should sort that out. I’ll have a think...
Peter
Sent from my iPhone using Tapatalk Pro
- Umtauscher offline
-
- Posts: 566
- Joined: Oct 03, 2014
- Location: Cologne, Germany
Re: Network Shift Between Z-Wave Controllers
Maybe it doesn't happen with all devices.... I don't know.
Cheers
Wilhelm
Cheers
Wilhelm
- DaveL17 offline
-
- Posts: 6751
- Joined: Aug 20, 2013
- Location: Chicago, IL, USA
Re: Network Shift Between Z-Wave Controllers
Umtauscher wrote:@Jay
I think there are many HA software products which are able to initiate a backup of the stick themselves. I cannot see why your firm might not be able to accomplish this.
( Razberry, OpenHAB, Domoticz and others can do it)
BTW the UZB backup is compatible to the Gen5 so I think the command is built into the firmware...
Cheers
Wilhelm
This issue has been discussed in the forums before.
Unless something has changed, Aeotec will not grant Indigo Domotics access to the protocols necessary to be able to accomplish this. Without access, there is nothing that Matt and Jay can do. If other products are able to backup the Z-Stick they have either been granted access by Aeotec, or are doing things that they shouldn't be doing.
I came here to drink milk and kick ass....and I've just finished my milk.
[My Plugins] - [My Forums]
- Umtauscher offline
-
- Posts: 566
- Joined: Oct 03, 2014
- Location: Cologne, Germany
Re: Network Shift Between Z-Wave Controllers
and shouldn't be doing that why exactly?
Who is online
Users browsing this forum: No registered users and 4 guests