Backup/restore ZWave network information

I am looking at a number of opensource home automation systems and OpenHAB is looking like may be the one I will settle with. However I have a few questions. The main one I want to deal with here is how OpenHAB users go about backing up and restoring the ZWave network information from the USB controller chip in case of loss of that chip (eg. should the hardware fail). I feel this probably is fairly important to save on time on having to rebuild the network in such an event.

Looking around OpenHAB does not seem to have a backup/restore feature for the ZWave controller chip. In fact most of the opensource solutions seem to be lacking here (IE. Open-ZWave also is lacking backup/restore). So do people use other software, if so what, or do people just generally not backup their ZWave controller chip?

Now for a little bit of what I have found and the question of whether backup/restore could be added to the ZWave addon of OpenHAB.

The only opensource option I found which seems to contain backup/restore of the ZWave controller chip itself is fhem. If I understand the information in the fhem documentation about ZWDongle is correct, then it is just copying the NVRam into a file and restore would be copying it back. From what I know the bin file it creates will be specific to that model of chip, may be even the firmware version on the chip. So how good is this approach?

However I notice that Aeotec ZStick5 is listed as having backup/restore feature and they have a Windows only tool for doing this. I do have a ZStick5 and my guess is that it is doing something similar to fhem and just copying the NVRam to memory. Comparing the .bin files from the Aeotec tool and fhem suggest may be they are.

So why don’t I just use the Aeotec ZStick5 and use their software? In short it feels slightly wrong to have something so large plugged into a small single board computer and also having to disconnect it and connect to a Windows PC to perform a backup is not great. Well for one reason and another, when I found a ZWave .me UZB1 on sale at a very cheap price, I decided I would get one. I do prefer the smaller size and the lack of the button is not really a big problem. Also it looks like the UZB1 backup/restore may be a bit more sophisticated having the ZMERestore (0xf3) command. When using Z-Way to perform a backup the file created is a bunch of XML files and no binary image, so the restore feature must be setting the actual values. The only problem is that backup and restore through Z-Way is assuming that you use Z-Way for managing the network (IE. backup only saves devices showing in Z-Way) and that means buying a license. I guess in the event of replacing the ZWave controller chip it would mean a new Z-Way license would also need purchasing as the license is stored in the chip, so more expense. Also being closed source ensuring I have the correct libraries installed which it links to is a task I would prefer not to have (IE. they do not provide packages for my preferred Linux distribution). In short Z-Way is software I think I would prefer not to use.

Whilst this ZMERestore function is specific to ZWave .me products, my thought is that at least it should be more portable between different ZWave .me products and/or firmware versions. How might I go about finding out the serial API for this function so that may be I could look at developing a tool or addon to use it. A bit of searching the internet found the following document for the ZWave .me ZStickC particularly look at annex A. Whilst not being the UZB1 possibly gives a hint as to the function and suggests my thought about setting the information rather than just creating an image is correct, the change frequency function is the same for the UZB1. Unfortunately the UZB1 manual does not contain such information.


Network backup and restore is something that will be added in the medium term (probably a couple of months). I have the information on how to achieve this functionality.


Thanks for the answer. I look forward to backup/restore in the ZWave
plugin. I do have some background with software development, so let me
know how I can help, very willing to do some testing.

Out of interest, what approach do you plan to take? Just copying the
chip memory into a file or the more advanced restore possible with the UZB1. I did read some things on the HomeSeer forum where it
seems like people were able to use HomeSeer to back up one brand of
ZWave stick and restore on the UZB1. That discussion though shows that
the restore function on the UZB1 changed around firmware 5.02 of the UZB1.

I don’t know what the ZWave me device does, so I can’t comment on that. However the intention would be to make it useful and provide a restore as well! As I understand it should be possible to restore to any stick, but I’ve not looked into the detail just yet.

1 Like

This may be what you are looking for. this backs up the config/address/etc. of the Aeon z-wave gateway/stick. Basically clones the stick in case of physical/electronic failure. Restore the image to your newly acquired replacement and all the memory/eeprom bits, etc are restored.

I’m not sure I can integrate that into the binding though (nor would I want to). As said, this is a feature that will be added in the medium term…

From what I understand of the ZWave me stick you send a command to
restore/set the home ID and whether the stick is the primary or
secondary controller, then you send further commands setting the number
of nodes in the network and the device type for each node of the
network. That is what the document for ZStickC says, the UZB1 may have
additional things to restore but I am not sure.

Is that the sort of approach you are going to take or will it be more of
the copy the stick memory to a file and on restore just copy it back.

Well sort of. I do prefer it as a small focussed tool over the ZWave .me
insistance of backup/restore can only be done through Z-Way, but the
Aeotec tool also has some issues.

Ideally I would prefer to use the ZWave .me UZB1, the smaller size
certainly seems better when plugged in an ODROID XU4, the Aeotec ZStick5
is as long as the ODROID. Also in event of needing to replace the UZB1
is cheaper.

My second reason is that from what I can tell that tool simply makes a
clone of the stick’s memory. That image file would probably only work
for the same model stick and also may require the same firmware version
due to different memory layouts. May be the UZB1 could have its memory
cloned with that tool, but one would need to be careful about firmware
versions when restoring as UZB1 has had more than one firmware version
released. Both ZStick5 and UZB1 have the same size memory (256k) and I
think reading/writing the memory is fairly standard, just don’t try and
use anything like set the LED settings in that tool.

The final issue is with that tool being Windows only. It would mean
stopping OpenHAB on the ODROID, disconnecting the stick and connecting
it to a Windows PC when ever I want to do a backup or restore. Why
should everything else OpenHAB controls be offline just because of a
ZWave task? Having backup/restore in OpenHAB would be very nice and

1 Like

No - the backup/restore function restores at memory level - not individual function level.

Yes - it will be a memory copy - this is how the API works so there’s limited option really.

It should work for ALL zwave sticks since they are fundamentally all the same.

As said earlier, this will be added in the medium term. There is other restructuring required to allow this sort of functionality to be added first.

1 Like

I agree that probably copying the memory can be done the same way on
different ZWave sticks, but I was not certain whether a backup made
using one stick could be restored to another model (eg. if I backed up
my Aeotech ZStick5 could I use that backup file to restore to the ZME UZB1).

I guess my reason for thinking that it would not be possible is that may
be different manufacturers may lay out the memory differently. They
might lay out the standard stuff the same way (home ID, node
information, etc), but might the custom extensions cause an issue. As an
example for the ZME UZB1 the Z-Way license is stored in the chip, the
operating frequency of the chip can be changed to different regions,
etc, the Aeotec does not have these and instead has the LED which can be
turned on and off.

Also according to the FHEM documentation, the size of memory may differ
depending on the chip and fhem requires the user to specify the memory
size. A backup from a stick with 256k memory (eg. the UZB1) could not be
restored to a chip with less.

Cloning the chip memory will definitely be better than nothing and also
better than having to disconnect the stick to backup using the Aeotec
tool on a Windows PC. I just wanted to get an idea of what the
limitations might be.

Most devices use the same firmware, and the core data (home id, nodes, routes etc) is managed by the libraries, so should be consistent as far as I can tell (unless a manufacturer has really gone out of their way to screw with things). Devices have external memory for applications, so yes, the memory size can vary.

Hi @chris. I know you’re busy with the new dev branch binding, but was wondering if you had had any further thoughts on the backup/restore functionality?

Thanks again for all your tremendous work!

No, I’ve not progressed this at the moment. This requires a “bit” of restructuring of the binding before I can implement this - primarily due to the fact that this function can’t be released as open source.

Understand. Thanks for the quick reply.

Hi Chris,

time flies by…

Something new on this topic?
Can I help anyhow?

Good work and thank you for everything you do for the community!!!
It is much appreciated by me.


1 Like

Hi Chris,

I also would like to know if there is some progress in that topic?
I just read your very good deep dive presentation about zwave and the OH2 binding in which you also have backup and restore on the roadmap.

I’m very keen to know when it will be available…

No - there is currently no progress. This can not be implemented as open source code, so requires some restructuring of the binding to allow for closed source code to be used.

I may have missed something here - but can you shed any details / background on why this won’t be able to be open source?

The information required to implement this is not publicly available. It is only available to ZWave developers who have signed the non-disclosure agreement with Sigma.


any plan to implement this piece in the next few months? Or too much work to be done?