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?
Adding my EUR0.02 in here.
A backup-restore solution here for the USB dongle would be worthwhile to fill the mitigation strategy void for a dongle failure.
“To lose a simple z-wave dongle config may be regarded as a misfortune; to lose a complex z-wave config looks like carelessness.”
I missed this message earlier, but as I have said elsewhere, this is planned. In the meantime, there is nothing to stop you using other tools to avoid being “careless”
To be fair, because I’ve been bit by it twice, its not careless to lose a complex Z-wave config when HABmin has the hard reset link in relatively small text immediately above the link to trigger exclusions on the network, and no confirmation dialog. With a mouse, catching the wrong link is careless, but lots of people use touchscreens, and you just need a slight mis-read by the browser and your network is gone.
Backup/restore would be a lifesaver when that happens – I’ve wasted a dozen hours now recovering from it.
Of course, a confirmation dialog might be easier …
I just nuked my entire z-wave network because of this. It’s a horrible and unacceptable design to have a hard reset option with no confirmation. I am LIVID right now. I now have to go around to every single device, un-enroll every device, re-enroll every device, redo the thing name for every device, and redo every single item in every item file to match the new device numbers. This is going to be HOURS of work that should never be happening.
You may use the old id when adding your controller.
Hard resetting the Z-Stick wipes everything. When enrolling devices, they are enrolled in acending order with new device numbers. There is no way to make them be enrolled with the same device number.
I thought you were speaking about the controller id, sorry.
Do you have any news about backup/restore plans or maybe roadmap update?
I’ll throw my tuppence in here - backup and restore is critical functionality to have long-term. Right now I have 14 z-wave things and 109 items. In the event of the loss/destruction of my z-wave controller, I face having to rediscover all 14 things and reassociate their 129 items. As it stands, I lost my openHAB server in January when the SSD corrupted itself, but luckily the controller retained its configuration, and I had a backup of the /etc/openhab2 directory. As a result my recover time was ~3hrs, while it I had lost my z-wave controller I’d have had to climb a ladder to access some of my z-wave devices such as PIR’s.
So, in the interest of usability/functionality, I’d like to see backup & restore as a feature-add on openHAB please.
I’d be willing to assist with the testing as I do have two controller keys. There’s my value-add.
Anything new here?
I have over 80 Zwave things and I just recently accidentally deleted the ZWave Controller in HABmin while I wanted to delete another item.
As I did not know better, I had to re-add the controller and it got a new controller ID. In addition all things popped up my inbox a second time while I had to forcefully delete my already existing things.
By the way, is there a way to change the controller ID. I am using a ZMEERAZ2 Z-Wave.Me RaZberry 2.
If you´re using text config files, (or items files)… All you need to do is to exhange the controller ID in the the channel with the new controller ID, whenever you have a new controller ID. It´s very fast done when using items files and having all things in one file. Just a fast copy/replace, and you´re up running again in seconds.
You can also setup your controller using config file. It´s a bit tricky, cause it´s not descriped, but it works… Then you wont have to do anything, if you re-add the controller as you have already named/ID the controller in the config file.
I use the first option but has also used the second. I had to dump the second option because I ran into troubble with the serial driver. But before the mess with the serial driver, it worked perfectly.
Thank you for the fast reply.
Yes, I did a fast replace in my item files as the node IDs where still the same. The problem was more on the things side. I use my own naming convention also for the things to maintain the overview over 80 things. So I had to manually add the things from the inbox, name them and delete the old things.
But okay, no re-including at least.
For the controller I am using the discovery as stated as best practice in the documentation of the binding.
Next time I would try the manual steps, but hopefully there is no next time.
More important, how can I create a backup of my ZWave network so that I can recover my ZWave stick if the stick is broken?
I read the this may be possible with a Z-Way software but I do not know how.
You can do it with the “Z-Wave PC Controller”, free (as in beer) software from Silicon Labs. You can download it from them directly by jumping through a ton of hoops, or you can get it right here.
See this thread too, we were just discussing this exact thing.
Yes, you can use the same controller id as before when adding the controller as a Thing.
So if doing this there is no need to edit anything in your config.
just seen that the ZMESerialUpdater is also able to backup and restore zwave.me devices such as Razberry2 and UZB1.
./ZMESerialUpdater serialapi_ripnvm -d /dev/ttyACM0 backup.bin
./ZMESerialUpdater serialapi_restorenvm -d /dev/ttyACM0 backup.bin
Script which disables Z-Wave binding, takes a backup and starts binding again:
#!/bin/bash destination='/backup/' apiurl='http://localhost:8080/rest/things/zwave%3Aserial_zstick%3Azwave1' prefix='ZWAVE' retention='+13' file=$prefix-$(date '+%Y%m%d_%H%M%S').bin if [ -d $destination -a ! -f $destination$file ]; then find $destination -maxdepth 1 -type f -name $prefix-*_*.bin -ctime $retention -delete curl -sX PUT --header 'Content-Type: application/json' --header 'Accept: application/json' -d 'false' $apiurl'/enable' >/dev/null port=$(curl -X GET --header 'Accept: application/json' $apiurl 2>/dev/null | jq -r '.configuration.port') sleep 5 ./ZMESerialUpdater serialapi_ripnvm -d $port $destination$file curl -sX PUT --header 'Content-Type: application/json' --header 'Accept: application/json' -d 'true' $apiurl'/enable' > /dev/null fi
Maybe it is a solution to make controller backups at your own for example with cron.
Can anybody say if there were also topology information backuped and restored?
I spent a long time reading here and there forums to finally get my UZB1 Zwave stick backup & restore working …
Lots of people just struggle with this so I decided to create a small application that you can find here:
Please let me some comments on my web site under the tool download section, I will be pleased to read them and answer to your questions.