Vera PushOver notification with image

[cubs2b23]

I might try the whole thing again. I just did a restore because at some point after I thought that none of it worked all my devices names were reset and all sitting in 'No Room'. Of course this was after I had switched the port back to the default Vera device. So something was happening maybe just at a snail's pace? Also how do I check the Vera's SDK version?

[cubs2b23]

No go on the second attempt. So what are my other options if I don’t want to exclude/include everything?

[rafale77]

Sorry for not responding sooner, I was busy with work today. The SDK version of the vera should be shown in the advanced page under the z-wave submenu. You should see something like 6.1 or 6.01. which is the version of the serial API corresponding to 6.71. The point is to downgrade the firmware of the uzb to a version old enough that the vera can support. Not much more you can do on the vera.

https://www.silabs.com/documents/public/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf

https://www.silabs.com/documents/public/release-notes/SRN14615-6.82.01.pdf

[cubs2b23]

Just to update: I decided to bite the bullet and just manually move everything over from Vera to Z-way. Still a couple of outstanding devices to transition. It went mostly smooth. I have a couple of devices that aren't responding as they did with the Vera network. Shouldn't be an issue of coverage.

[powisquare]

@rafale77 said in (Problem) Migration Z-Wave NW from Vera to UZB1 dongle:

wow... so it did recognize the UZB just fine and can read the network ID from it. It is purely about triggering the recovery from your backup to the Uzb dongle then. I am a bit surprised that it didn't work.
So the "/etc/cmh/dongle.restore" file never got replaced?... I wonder if the script has changed. Unfortunately I wiped my vera from anything mios so I can't test with this firmware. The nuclear option would be to edit the user-data.json from a backup and recover from it.... You are sure you have all your dongle files in the etc/cmh folder right?

extract from my own old posting:

Just for documentation purpose, I also found how to restore only the onboard zwave dongle:
-move your desired dongle file (example: “dongle.6.1.dump.0”) to /etc/cmh,
-rename it “dongle.restore”,
-run Stop_cmh.sh
-run Start_cmh.sh
-run Reboot

Running into the same issue with dongle.restore not getting replaced. Version shows 6.2 in Zwave settings on vera and firmware is 1.7.599 (V7.0.8 June 2015). Would you recommend renaming the dongle file and trying the above or trying a different vera firmware?

[rafale77]

You can try to rename it to dongle.restore.go but the number of reports that this no longer works makes me very suspiscious. I don't know if it is another of the ezlo kamikaze moves to make migrations harder or if there is some new incompatibilities from the uzb firmwares.
It could be that you will have to downgrade the uzb firmware to make the zwave SDK compatible as the vera restore tool may be balking out at translating to unknown SDKs.

[powisquare]

Something worked!! Believe I set fw on 1.7.1040 then factory reset. Copied over the dongle renamed to dongle.restore.go and then tried your steps with a manual reboot. Devices didn't appear in vera but the dongle lit up blue for a second so something was going on. As I resigned myself to setting up from scratch I found 32 devices copied over to UZB in zway. Huge thanks - light at the end of the tunnel. Any way of telling which device is which, an id maybe the same on vera and zway?

[rafale77]

Awesome news! The altid on the vera are technically the lower level zwave node IDs so they should match the altid (if I remember correctly as my memory of the vera is fading). The z-way bridge on openLuup however will add a pre-fix (2 digits) to the node ID and suffix (1 digit) corresponding respectively to the parents controller index and child device index.

[Hansel]

I’m having this same issue unfortunately (but with a gen5 aeotec stick). I’ll give it another try tomorrow when I get a chance, but it was basically the same issue of the restore file not changing to restore.go after a luup reload.

[Hansel]

Ok, so. Reloading the luup engine doesn't remove the dongle.restore or turn in into dongle.restore.go, but rebooting the vera seems to. I checked the logs and I see this:

ZWJob_BackupDongle::FindFileToRestore found 12 files using /etc/cmh/dongle.6.1.dump.0 timestamp 1630736238 / 2021-09-04 16:17:18 version 6.1 md5 30586bc3340164f7dccfb39ca218dda1 <0x77f00320>
01 09/06/21 11:53:40.943 ZWJob_BackupDongle::FixupBufferVersion don't know how to validate since there's no zensys in the firmware <0x77f00320>
01 09/06/21 11:53:40.943 ZWJob_BackupDongle::FixupBufferVersion don't know how to convert from 6.1 to 3.95 <0x77f00320>
01 09/06/21 11:53:40.944 ZWJob_BackupDongle::ZWJob_BackupDongle restore file invalid <0x77f00320>
10 09/06/21 11:53:40.944 FileUtils::DelFile /etc/cmh/dongle.restore.go <0x77f00320>

So I assume from that it doesn't recognise the file as valid so it just deletes it. I assume the 6.1 to 3.95 complaint is the version (the Vera version on the Z-Wave Settings page was 6.1, and the Aeotec stick version on that page is Version: 3.95 L:1).

No idea if any of that is useful for troubleshooting?

[rafale77]

I can't remember whether I tried with the aeotec stick and I usually recommend avoiding this specific stick because it is very quirky. It's firmware is not upgradable and is stuck on a very old version of zwave stack. I think indeed that the problem stems from the large gap in zwave stack version which the vera tool may not support anymore.

[Hansel]

No worries, I've ordered a UZB just to see

[a-lurker]

@rafale77

I've just had a go at writing a dongle.dump file to an AeoTec USB stick on an old Vera 3. The stick actually came with the Vera as its prime ZWave interface..

A question for rafale77: when you were doing these stick writes; about how many ZWave physical devices were being copied across roughly. A handful, less than twenty, forty, eighty or more?

The reason I ask is that; I have somewhere around forty devices - noting most are dual relays so in the Vera UI there are lot more devices represented ie three widgets for every dual relay. When I do a ZWave backup in the Vera UI it takes tens of minutes to finish. I thinking the reverse is true. ie it will take ten of minutes to load up the USB stick and to get Vera to absorb all the changes?

Just for the readers: in the Vera 3: in the script restore.sh located in /www/cgi-bin/cmh --> /mios/www/cgi-bin/cmh/ you will see the creation of "dongle.restore" emulated by rafale77's method:

	if [ "$FORM_dongle" == "1" ]; then
		# LuaUPnP will restore the Z-Wave backup file if it finds the 'dongle.restore.go' file.
		# To prevent LuaUPnP from restoring a dongle backup until the next boot,
		# we'll save the file as 'dongle.restore', and the 'Start_cmh.sh' script will rename it to 'dongle.restore.go'.
		log "Create $MIOS_CONF_PATH/dongle.restore"
		touch "$MIOS_CONF_PATH/dongle.restore" 2>>$log_file
	fi

And in the script Start_cmh.sh located in /mios/usr/bin/ you will see the renaming of "dongle.restore" to "dongle.restore.go" as described in rafale77's method:

# to prevent LuaUPnP from restoring a dongle backup until the next boot, 
# the web ui saves .restore and LU looks for .go
mv /etc/cmh/dongle.restore /etc/cmh/dongle.restore.go || /bin/true

I can't find the code that looks for "dongle.restore.go" or the code that decides which dongle file to load from - some of examples of dump files found:

"dongle.dump" or "dongle.3.20.dump.X" or "dongle.2.78.dump.X" files or "dongle.6.1.dump.X"

So it may be that a huge mount of patience is required between Vera reboots to give time (eg half an hour) for everything to come into play. Need to play around further, after having achieved some partial initial success.

[htcheng]

Hi Everyone, After pulling my hair out trying to migrate from Vera to a UZB-7 stick and getting numerous errors and no meaningful support from Vera/Ezlo support, I found this post that describes a way to shift the primary controller to the new stick from Vera - you will need two Zwave USB sticks to do this. Controller A as referenced below is the target stick that you want to make primary - I reset this stick, included it as a secondary controller from Vera and confirmed it worked in Home Assistant (and then backed it up), before performing the steps below:

Dec 29, 2022

Shift Primary Z Wave Control to Secondary Stick?

Ok, so I figured out a method which works, although it requires two USB controllers. Controller A will become the primary controller in the end, and controller B will be used as an intermediary. Plug both USB controllers into a PC, run two instances of the PC Controller software, and configure...

1. Back up Vera (including Zwave)and NVM from all of the Z-wave sticks that you are using.
2. Install Simplicity Studio from Silicon Labs - you need to register and it's Windows only...
3. Follow instructions here but swapping the Vera for where it says Hubitat - https://community.hubitat.com/t/shift-primary-z-wave-control-to-secondary-stick/108467/7
4. When bon refers to "press" buttons, he/she is referring to the Sil Labs ZWave PC Controller Tools under "Network Management"
5. Once you finish the transfer from Controller B to Controller A, you can then wipe the Vera and reset the Z-wave and include it as a secondary controller if you want (or not)
6. Battery-operated and a few exotic devices don't completely transfer over but you can exclude/reinclude them after you've shifted the primary over to the USB Stick

Hope this helps someone out there - it took me a week of trial and error and researching before finding this method and it does work!

NB. You need to be patient though and wait for commands in ZWave PC Controller to run their course - If the process doesn't work, restore backups from BEFORE you tried to shift and replace and reboot/clear out caches before re-attempting the shift and replace

[a-lurker]

@htcheng Out of interest what type of Vera are we talking about here? Ditto what sticks were you using?