Controller shift - How do you do it ?
-
So from memory, if you just create the dongle.restore.go file in /etc/cmh and reboot.....
But that is from memory
touch /etc/cmh/dongle.restore.go
Oh and obviously make sure your backup file is uploaded!
C
@catmanv2 said in Controller shift - How do you do it ?:
So from memory, if you just create the dongle.restore.go file in /etc/cmh and reboot.....
Hi @CatmanV2
That’s the bit I’m not sure about , so do I just create a blank file , with nothing in it and call it a
dongle.restore.go
?Also, just to confirm do I copy over the dongle back up file
dongle.4.5.dump.0
into /etc/cmh tooOnce both are in there (making sure the a-wave settings are set to the correct onboard zwave chip etc.) I can just do a reboot or luup.reload ?
-
I believe that's exactly it. Although if you create dongle.restore.go you'll need to reboot, not just luup.reload.
Clearly you might want to keep dongle.4.5.dump.0 as a copy somewhere, but I guess it depends on the current state of the Vera you are restoring to
C
-
Ok, i gave that a go, but sadly no luck..
FYI - The Veraplus (with external a-wave dongle), dongle dump files are already on the VeraSecure in the /etc/cmh folder - I assume they must have come over during the restore this morning.
On the VeraSecure I ssh’d on to it and run that file creation command -
touch /etc/cmh/dongle.restore.go
So, all file are in
/etc/cmh/
now..-rw-r--r-- 1 root root 16383 Sep 19 10:16 /etc/cmh/dongle.4.5.dump.0 -rw-r--r-- 1 root root 16383 Sep 2 03:00 /etc/cmh/dongle.4.5.dump.1 -rw-r--r-- 1 root root 16383 May 29 03:00 /etc/cmh/dongle.4.5.dump.2 -rw-r--r-- 1 root root 16383 Mar 15 2021 /etc/cmh/dongle.4.5.dump.3 -rw-r--r-- 1 root root 16383 Mar 11 2021 /etc/cmh/dongle.4.5.dump.4 -rw-r--r-- 1 root root 16383 Feb 27 2021 /etc/cmh/dongle.4.5.dump.5 -rw-r--r-- 1 root root 0 Sep 19 19:48 /etc/cmh/dongle.restore.go
I did the full reboot, a few luup.reloads too, but still the same now zwave devices are shown or being picked up.
Any ideas ?
-
Ok, found something in the Luaupnp logs, which suggests an invalid restore file ?? - interesting..
02 09/19/21 19:54:21.868 ZWave::Start reset 0 use45:1 minor:1 model:37 port:/dev/ttyS0 nodes:1 using_prefer: 1 prefer 0.0 ports:/dev/ttyS0 - /dev/ttyS0 <0x77212320> 02 09/19/21 19:54:21.868 ZWave::Start restoring dongle firmware <0x77212320> 03 09/19/21 19:54:21.869 JobHandler_LuaUPnP::m_bReloadCriticalOnly_set now 1 <0x77212320> 01 09/19/21 19:54:21.882 ZWJob_BackupDongle::FixupBufferVersion not a valid 4.5 backup: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff (<0x1b>[34;1m################<0x1b>[0m) <0x77212320> 01 09/19/21 19:54:21.883 ZWJob_BackupDongle::ZWJob_BackupDongle restore file invalid <0x77212320> 03 09/19/21 19:54:21.889 JobHandler_LuaUPnP::Reload: Dongle Restore Critical 1 m_bCriticalOnly 1 dirty data 1 running 0 <0x77212320> 04 09/19/21 19:54:22.257 <Job ID="1" Name="restore" Device="1" Created="2021-09-19 19:54:21" Started="2021-09-19 19:54:22" Completed="2021-09-19 19:54:22" Duration="0.386898000" Runtime="0.0" Status="Failed" LastNote="ERROR: Restore failed. Try again or contact tech support."/> <0x77212320> 02 09/19/21 19:54:22.258 JobHandler::PurgeCompletedJobs purge job#1 :restore dev:1 (0xbb88a0) P:5 S:2 Id: 1 restore status 2 <0x7603c520> 06 09/19/21 19:54:22.259 Device_Variable::m_szValue_set device: 2 service: urn:micasaverde-com:serviceId:ZigbeeNetwork1 variable: ComPort was: /dev/ttyXRUSB1 now: /dev/ttyXRUSB1 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x77212320>
-
-
Hummmmm, same error..
Does it matter that this is a 4.5 dump file, and the Vera secure is on zwave version 6.1 ?
02 09/19/21 20:42:35.508 ZWave::Start reset 0 use45:1 minor:1 model:37 port:/dev/ttyS0 nodes:1 using_prefer: 1 prefer 0.0 ports:/dev/ttyS0 - /dev/ttyS0 <0x77e96320> 02 09/19/21 20:42:35.521 ZWave::Start restoring dongle firmware <0x77e96320> 03 09/19/21 20:42:35.522 JobHandler_LuaUPnP::m_bReloadCriticalOnly_set now 1 <0x77e96320> 01 09/19/21 20:42:35.549 ZWJob_BackupDongle::FixupBufferVersion not a valid 4.5 backup: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff (<0x1b>[34;1m################<0x1b>[0m) <0x77e96320> 01 09/19/21 20:42:35.550 ZWJob_BackupDongle::ZWJob_BackupDongle restore file invalid <0x77e96320> 03 09/19/21 20:42:35.551 JobHandler_LuaUPnP::Reload: Dongle Restore Critical 1 m_bCriticalOnly 1 dirty data 1 running 0 <0x77e96320> 04 09/19/21 20:42:35.735 <Job ID="1" Name="restore" Device="1" Created="2021-09-19 20:42:35" Started="2021-09-19 20:42:35" Completed="2021-09-19 20:42:35" Duration="0.212538000" Runtime="0.0" Status="Failed" LastNote="ERROR: Restore failed. Try again or contact tech support."/> <0x77e96320>
-
So you're trying to shift from a Vera Plus to a Vera Secure running different zwave versions?
I honestly have no idea if that's going to work or not. Unless you have 100s of devices I'd probably start from scratch at this point, or wait for one of the experts!
C
-
So you're trying to shift from a Vera Plus to a Vera Secure running different zwave versions?
I honestly have no idea if that's going to work or not. Unless you have 100s of devices I'd probably start from scratch at this point, or wait for one of the experts!
C
@catmanv2 said in Controller shift - How do you do it ?:
So you're trying to shift from a Vera Plus to a Vera Secure running different zwave versions?
Yep, although I’m assuming it wouldn’t much different to someone upgrading from a vera3 or Vera lite to the newer plus or secures as they were different zwave versions..
Why are things never as straightforward as you want them to be
-
Sorry, just came back and am trying to catch up with all the posts... It looks like you manage to trigger the restore. The vera firmware is a bit idiotic in the sense that it will choose the target of the network restore as the one you have set in the UI when the vera UI starts (LuaUPnP). I don't think it works when downgrading from one stack version to a lower stack version but it does when going up. You should actually see a converted database file show up in the etc folder when it has to do a conversion. I have not tried upgrading from major versions however as my upgrades were always within stack version 6.x.
-
-
Thanks @rafale77
I’m always conscious something’s going to fail when I do any firmware upgrade, and while I have two UZB1 sticks (one v4 the other v5) I was wondering if I could upgrade the v5 first and then copy the data over/clone from the v4 one ?
To do the latter part, I came across this zwave cloner tool in another forum, have you seen it before ?
-
Looks like you should be going to 5.26 and then 5.27. These are already 6.xx stack versions though.