Recover an ‘assumed bricked’ Vera Secure
-
tgz files are very easy to decompress. I think it stands for tar-gzip. You can just untar it. (it's a standard linux tool)
tar -xzf ***.tgz
These decompress automatically on macOS.
You will likely find a few files including the user-data.json. I wrote a script back in the old times to manually backup and recover these files and I think one such automated script is in the vera firmware. It should help you move the files to the right folders. Unfortunately it's been a long while since I last tinkered with the vera.
-
You can put the file up on your Vera using scp (or a tool like WinSCP if you are starting from Windows). I would put it into
/storage
for the time being. Then run this:tar -C /tmp -x -v -z -f /storage/backup-file-full-name-here.tgz
This will de-tar the backup file into
/tmp
, in a subdirectory calledetc
(so full path is/tmp/etc/
). You'll find several subdirectories within that (cmh
,cmh-lu
, and so on). You can copy the files you think you need one at a time, just make sure you copy them to the right place. -
I finally got around to connecting my PC to the VeraSecure via usb tty, to see what I could do - and I’ve posted some photos on the Vera forum - https://community.ezlo.com/t/can-the-veraplus-be-unbricked/204485/42
Currently I can’t seem to get a network connection, no IP address being provided to allow me to connect to anything, such as a tftp server, but..
Based on what I’ve posted, looking in the root of Vera, I have the following under storage, is this of any potential use ?
root@MiOS_5510000:/storage# ls -l drwxr-xr-x 2 root root 0 Jun 17 2018 cmh-backup drwxr-xr-x 5 root root 0 Jun 17 2018 cmh-firmware
cmh-backup was empty, but in cmh-firmware, i can see the following
drwxr-xr-x 2 root root 0 May 22 2018 1.7.3062 drwxr-xr-x 2 root root 0 Jun 17 2018 1.7.3535 drwxr-xr-x 2 root root 0 Jan 1 00:00 1.7.3832 -rw-r--r-- 1 root root 156 May 22 2018 error.log -rw-r--r-- 1 root root 162 Jun 17 2018 latest_firmware.conf
Within the error.log, it seems to only say...
2018-05-22_15:12:38 - ERROR: Failed to copy MiOS Squashfs MD5SUM into jffs2 partition 2018-05-22_15:12:38 - ERROR: Mismatched md5sum of new Firmware Script
-
Hi all,
Can anyone think of anything I should try to reinstall/restore the firmware?
As I don’t have access to it via an IP address on the network, I potentially could plug in a USB key to transfer or run any files ?
-
Hi @therealdb - yep and they finally got back to me..
It seems according to their records, the controller I picked up 2nd hand was declared defective and replaced a while back. And when this happens, and the hardware is not returned, a call is sent to the unit to deactivate it and it gets permanently banned from their servers. This means the controller will not connect anymore so it won’t pick up an updates and they are not allowed/able to provide support...
As I have command like access to it, I’m wondering what I can still do with it.
Any ideas anyone ?
-
That makes sense. One thing you can do with it is to not use it as a vera anymore and "nuke" it... Turning it into a zwave and zigbee radio host for another controller (homeseer, home assistant, domoticz). It is very likely that it was bricked due to a flash memory failure which is a sign that it would not have run reliably with any vera firmware anyway. You can look up my nuke vera script here:
I have run this way for quite sometime using the vera's zigbee hardware as a zigbee stick for home assistant's ZHA component and the same can be done with zwave using any other controller software.
-
Theoretically yes but I wouldn't know why. It has limited storage space which is poorly partitioned, runs on a very old version of openWRT OS and the CPU is weak. It would take you to recompile the controller to MIPs from source. Really not worth the trouble IMHO when computing power has become as cheap as it has.
-