Same here… But never tried a Restore.
I had some discussions about this with Aeon a while back and it was a little inconclusive, but they said
If the network key can never be changed, then this option can be ignored
I’m part of their gateway developers program (which is very nice!) and I’m hoping to be able to get information on their backup protocol so we can add it to the binding at some stage. Let’s see…
whats that?
It’s a program for gateway developers 
Z-Wave gateway program.
Aeon Labs has a dedicated integration program to assist gateway developers with samples and technical support for each of our products.
Hopefully this will help me to better support some of the Aeon devices that people are getting at the moment (eg the siren, doorbell, garage door opener…) and also give me an early version of new devices so I can try and test them before they hit the streets…
I will say one thing for Aeon - when it comes to technical support they are VERY good (IMHO)! 
.
wasnt sure if it meant Aeon is developing an own gateway
thanks for your insights 
Well, Sigma published some parts of Z-Wave protocol in August, so I hope, that OH Z-Wave binding will become more advanced and stable with that info.
Yes, this will help, but the backup of the stick is not related to what Sigma published - it’s an Aeon feature.
Hi all,
very happy to have found this thread … recently lost my zWave controller settings due to a stupid experiment with secondary controller - more than 55 devices lost 
- well done Patrik; now I rebuild the network and using the opportunity to try OH2 
- but fortunately I also upgrade to the new AEON stick and now did immediately take a backup (not all devices yet done; but to start from scratch again would really ruin my day).
=> Backup highly recommended if possible
But I do not dare to try a restore - too much work done yet; maybe someone just starting would dare to try (only one, or two devices included yet - and those not in a wall).
with kind regards,
Patrik
I have done multiple successful backups and restores. Actually I bought a second stick so I always have one as reserve. So after each backup I restore the data on the second stick and then let this one work. It always worked perfectly until now. The advantage with the second stick is that you can immediately test your backup an even immediately plug it in in case of failure of the other stick. As these devices are not that expensive this appears the safest solution to me instead of risking to lose the control of my home with nearly 100 devices…
Vossivossi, did you try to use both USB sticks at the same time in one network? I just wonder if hot redundancy would work like this.
I did not try that, but it does not seem to make sense to me. I can only connect one stick to openhab at a time (the one with the COM Port defined in the .cfg-File). What should the other stick do in this time?
I would expect that since the two sticks are effectively duplicates, they have the same node ID, and therefore could not be used on the network at the same time. Therefore hot redundancy in this way is not possible.
The other stick should be connected to other OH installation, for exampe on second PC. Since both sticks will have same node IDs they should be both able to control same network. Offcourse not at the same time, so one of the sticks should not send any commands, when it’s not active (aka hot redundancy). This has to be ensured by user. At the same time I see no problem if backup stick would always listen - in this way it can update sensor inputs automatically.
@chris, what would be collision if both sticks would have same id? For slave nodes it shouldn’t matter - they cannot recognize which stick sent a message. Same in other direction - both sticks will receive same message.
No - this won’t work as you will have two nodes with the same node ID. This can’t be a good thing.
It’s like having two computers with the same IP address - when you send a message, which one will answer? Both probably.
Of course they know which node sent a message - otherwise they would never know where to respond to.
In any case, a controller is not a slave node.
Both sticks MIGHT receive the same message - if they are right next to each other then there’s a reasonable chance this is true. However, both sticks will then respond which will cause confusion. Even worse is if one stick only receives the message (due to RF, it’s not guaranteed that both sticks will receive the same packets). Then you really have a mess…
Given both sticks would think they are the primary controller on the network, I think there would be a major mess.
I still have a hard time to follow your thoughts. So you assume to have 2 OH installations running at the same time on the same location? If both are firing the same rules at nearly the same time, what do you expect? How are you going to organize the “hot redundancy”? The 2nd stick and the 2nd installation should only take over if the first fails, correct?
- How do you get the information that installation1 failed and
- how do you trigger installation1 to shut down in this circumstances and installation 2 to activate?
I also think - like Chris - that this will not work.
Before we continue let’s discuss simple setup:
Imagine you have two cloned USB Z-wave sticks inserted in same PC and they shown as COM1 and COM2. Openhab communicates with one of them, for example on COM1 - let’s call this “active” USB stick. Another USB stick on COM2 - let’s call it “passive”, just sits there and does nothing, as Openhab does not communicate with it.
If something happens with active USB stick - for example it stopped reacting on COM commands, Openhab just failovers to passive stick, by changing the COM port to COM2. I know, that this is not realized yet, but sounds rather simple, isn’t it?
So now the questions:
- will passive USB stick disturb the z-wave network so much, that it can not be kept in such mode? The COM communication is off for it, so it should not issue any commands.
I do not know if it would disturb the communication. So far I only had one USB stick “on power” (in the plug) while the other one was just lying around. This does not do any harm (although these devices have a battery).
As the COM port for Z-Wave binding is defined in the openhab.cfg file the “hot plug function” would mean that openhab is modifying on its own the openhab.cfg file to another Com port if it detects that the controller fails (whatever the condition should be for this). Quite a connection of a lot of weird steps IMHO.
Normally the stick will work for years without any trouble. If however it should fail one day, well, then you will have to unplug the old one and plug in the backup stick. This is for me the absolutely accectable solution while towards my mind the theoretical discussion of a whatever “hot plug” function is not necessary.
I don’t want to discuss this now - this is just one possible implementation from many possible solutions.
For me it is not - what if it happens when I’m on vacation? In my case Z-wave controls pretty everything without any other control capability except cutting the protection circuit breakers. I don’t have any mechanical switch in my home.