I agree @parkerc, it is great job @alangraph , can you give us more detail about the process? And if it is possible anybody tell us about the pinout the “j6”?
The connector is labeled JM5. Left most pin is GND, next connect to RX, next NA and last connect to TX.
The connection parameter i use using putty are 115200,8,n,1
Remeber to make the connection after the vera has power. And use a 3.3v ttl adapter.
After you establish connection you can use the console to find what is the problem with the unit. In my case it was a problem when updating to the 240 openwrt, i fixed it giving the unit manual access to internet using ipconfig, as the network connection was not established using DHCP. After that upgrade the unit continue to make the upgrade.
The important part is to gain access to the unit and been able to send commands to it.
Thanks @alangraph
It looks like the VeraSecure is built a little differently, to the Plus, see photos, this seems to be the only accessible 4 pin connector I can see.
Is it safe to assume that our shared connection with a ‘4’ on represents the TX and the one with a ‘J’ and a triangle marker is the GND?
I think you can try and use this connector and test if it work (I will go ahead and try it). I suppose your assuption about the pins is ok. In any case you can test with a tester if the “J” pin gives you 0V so it is gnd make test to find for Rx and Tx until you get a connection. Your the vera is bricked so no harm can come of making tests on it.
Thanks again, agreed I’ve got nothing to lose 
While I’ve got you, I’ve just looked at the usb to ttl cable I have, and it had this info with it…
USB to TTL serial converter cable
Length : 1m
Chip : PL2303TA
Connections : Red +5V, Black GND, Green TXD, White RXD
Warning, this is a TTL (i.e. 5V) device. Connecting this device to standard RS232 connections WILL destroy it and void the warranty
You mentioned yours was 3.3v ?
Is that voltage provided by the usb or off the board itself.?
I use a 3.3V, as the veraplus have 3.3V on those terminals, i don’t know if the 5v will work or if it can break it.
the one i have is almost identical to this one (same chip and lauyot):
As you can see the adaptor have a 3.3 or 5v selector I use the 3.3V with no problem. Maybe you can order one of those as is not very much to spend to try to recover the unit.
Thanks again, to avoid doing any unnecessary damage, I’ve just ordered the one you linked to (hope you’re on commission:-) )
My secure is bricked here is the screenshoot. I have G550-35-1.7.4061.bin file (factory bin) and mt7621s_Luup_ui7-1.7.5187-en-mios.squashfs. Is there anybody who have idea about it? How can I recover it? I cannot install firmware from that interface but I have ssh access. Is there anybody help?
Just noticed, your photo/diagram did not show the 3.3v connection. I was going to assume I just needed to connect it into the blank one, but you said ‘NA’ - so I wanted to confirm just in case
Do I only need to use the 3 wires , or did you connect the 3v power wire to something else ?
I only used 3 wires, i didn’t conect the 3v wire to anything.
1 Like
OMG! It worked!
I thought for sure my VeraPlus was toast after I tried to install the latest beta. It seemed completely bricked, and factory reset wasn’t doing anything.
But I found your post… and I just happened to have a USB FTDI widget handy… so I figured I’d give your solution a try. Got it all wired up, started PuTTY with settings at at 115,200/8/n/1, powered up VeraPlus, but just got garbage. Luckily I’ve seen this all before in ye olde days when I ran a BBS with a telephone line and modem, so I knew what I was looking at. I cycled through baud rates starting at 9600 and working my way up, and finally got a good connection and a root prompt into openWRT at 57,600bps.
Next step was trying to figure out why the VeraPlus got stuck. ‘ifconfig -a’ showed My WAN interface was DHCP-configured to 192.168.1.2; and I could ping my default gateway of 192.168.1.1 – but could not route any traffic through it. Then I noticed that eth0.1 was configured to 192.168.1.1 – so there was an IP address collision, and eth0.1 was acting as a packet sink for anything having a destination other than localhost.
I used ‘ifconfig eth0.1 down’ to stop that… and then ‘ip route add default via 192.168.1.1 dev eth0’ to repair the default route. After that, I could ping nodes on my network and resolve DNS… and within a few seconds the system began the upgrade script – I didn’t even have to start it… it just took off on its own. After another 5 minutes or so, Vera’s web interface came back online, and – so far – she seems happy. Amazing!
THANK YOU for your post!!
Great news @kapstaad
To help me and others, can we just walk through those steps 1 by 1 again, and if you have any photos of your usb to tty connectivity that will help.
Putty settings - adjust baud rate if needed
57,600 / 8 / n / 1
Check your Vera’s network configuration with the following command
ifconfig -a
This will list everything network related, but it’s not clear exactly what to look for and do
- By My WAN, I assumes that’s ‘br-wan’ to see what it’s all set to. FYI - I only seem to have 192.168.x.x. IP addresses in that particular section…
- While your DHCP is set to work 192.168.1.x , could others may see something different, e.g my dhcp is e…g 192.168.102.x, or do we think 192.168.1.2 is what it defaults to?
- I don’t actually have a eth0.1 in my list, but I do have an eth0.2 - do we assume that’s the same thing ?
- What does the following command actually do ?
ifconfig eth0.1 down
And then you seem to add a routing default ?
ip route add default via 192.168.0.254 dev eth0
Which would that be for others, e.g. for me is that my ‘broadcast’ address of 192.168.102.255?
Sorry for all the questions …
Sorry for the brevity (and a couple of errors, now edited). Resolving the “bricking” debacle ate up much of my day, and everything else got very compressed… you know how it goes 
So, I’ll try again with some error corrections and clarification:
The ‘ifconfig -a’ command just shows all the network interfaces on the Vera device, what addresses they have assigned to them (if any), and whether they are UP (active) or not. I don’t recollect all of them… there were half-a-dozen or so. But I do recollect that the br-wan interface was correctly configured to the DHCP address I assigned to this Vera (using dnsmasq on a RasPi).
The problem was a collision on the eth0.1 virtual interface with the DEFAULT ROUTE on my network.
The default route is where all packets not destined for the local subnet will be sent; the “gateway router”. On my network, that happens to be 192.168.1.1 – which is a pretty standard setup, but turns out to have poor consequences during a Vera upgrade.
So no, it is not your broadcast address, which is always the .255 address of your subnet. It is usually the .1 address… but not always. The quick way to find out is to look at your own computer’s network configuration (how you do that is platform specific), and find your default gateway; chances are, that’s also the one Vera wants.
If the DHCP address given to your machine is 192.168.102.x, there’s a good chance that 192.168.102.1 is your default gateway – and that you won’t experience the same issue, because Vera doesn’t try to configure itself to that address when it restarts during an upgrade 
The main thing to grasp is that eth0.1 was (re-?)configured during the restart process, by defaults within Vera and/or OpenWRT, to 192.168.1.1. Because that’s also the default gateway on my local private network, that’s where all packets destined for not-in-my-network addresses would be sent. You know. Like any requests for downloading files over a network connection, or resolving DNS. Those were all being sent back to my own Vera, which of course, had no idea what to do with them, so it just discarded them.
The ‘ifconfig -a’ just shows all the networking endpoints inside the Vera. Checking it showed me that 1. the WAN address was correctly assigned by DHCP; and 2. there was another interface, eth0.1, which was configured with my default gateway address and acting to “sink” all outward-bound packets.
To resolve this I used ‘ifconfig eth0.1 down’ which basically turned off the eth0.1 interface, preventing it from handling any more packets; and then I used ‘ip route add default via 192.168.1.1 dev eth0’ (note that’s a different address from the one I posted earlier, since edited. I was in a hurry, for some reason…)
That told OpenWRT how to reach the Internet… which got the update process rolling again, without any further intervention from me… and shortly thereafter, I got my VeraPlus back, fully intact.
Sorry, I didn’t get any screencaps from PuTTY. If there’s something specific you want to see, I can hook up the FTDI adapter again, and grab them… but it is a pretty standard *nix ash shell prompt, and acts just like a VT100 serial terminal. You have access to the root filesystem and a limited set of commands, and other than that, its just *nix networking 101 stuff. Use ‘ifconfig -a’ to reveal the problem and ‘ifconfig xxx.x down’ turn off the problem interface; and the ‘ip route’ (or ‘route’, they are both installed) command to reset the default gateway for the main ethernet interface.
Hope that was clearer/more helpful!
Awesome, thanks @kapstaad
I’m going to be trying to recover my Vera Secure at the weekend, so all of this is helpful.
I’m not sure I follow this part.
Running ifconfig -a on my other Vera, I see the following for eth0.2, which does not show my default gateway IP (which for me is 192.168.102.1) listed , or am I missing something ?
eth0.2 Link encap:Ethernet HWaddr E0:60:66:09:26:BB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:22306600 errors:0 dropped:26038 overruns:0 frame:0
TX packets:12325454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:10834006485 (10.0 GiB) TX bytes:2482122843 (2.3 GiB)
Or is that ultimately the issue?
In that for some reason Vera will create an additional interface , which In turn can create the routing issue/conflict?
Which is why to fix it and progress, you had to shut it down ?
Yes! Exactly that.
You were looking at your interfaces from inside a fully-booted Vera. But when Vera is in recovery or update mode, the Vera “overlay” isn’t “up” yet; the machine is in a bare-bones, almost factory-reset condition.
It first boots OpenWRT, sets up the main WAN address per DHCP, then adds a hardcoded ‘backup’ address (192.168.1.1) to a virtual interface (eth0.1), to which you should be able connect if there are problems, and the Vera customization scripts are supposed to take it from there – which won’t happen if your network’s default gateway uses the same IP as the ‘backup’ address.
I suppose if I still had a laptop with an ethernet port, I could have used a crossover ethernet cable (or two regular cables and a hub/switch), forced my laptop to use 192.168.1.2/255, and connected to the Vera; I would probably have been able to SSH into it at that point via that ‘backup’ 192.168.1.1 address. But Vera still wouldn’t have been able to get outside the local network (which at that point would only be my laptop and Vera), so it would not have helped to get Vera back online.
In this situation, one either has to reconfigure their entire network to use a different subnet, or reconfigure the default gateway to use some other address than 192.168.1.1… or take the approach I did, which seems like the easier path: just force Vera to drop the “backup” interface via ‘ifconfig eth0.1 down’. Of course, that will only work from the serial console (3V3 FTDI + 3x wires connected to J1,2&4), not from an ethernet-connected session (which would be connected to 192.168.1.1, so killing eth0.1 would end the SSH session).
In retrospect, it might not even have been necessary to add a default route; the WAN interface is getting that from DHCP, so the route is probably already there. Just stopping the backup interface from stealing all the outbound traffic might be sufficient. Next time I brick my VeraPlus, I’ll test that hypothesis 
Good luck with your resurrection attempt!
im glad @kapstaad that the method worked for you. I have also tried whit several baud rates to work, i suppose dependieng on the firmware actually instaled on the unit it can change.
My problem was similar for the ip config. So i suponse the units lost connection and if you can make it accesible to the internet it will countinue with the update process.
That certainly seems to have been the case for me. Again: a big THANK YOU for your post!
I’ve finally connected to my VeraSecure via USB TTY and with the baud rate at 57600, putty it’s showing various activity.
[ 249.812000] led off GPIO_LED_ZIGBEE
[ 249.964000]
[ 249.964000] led off GPIO_LED_LPRF
[ 250.084000]
[ 250.084000] led off GPIO_LED_SERVICE
[ 250.204000]
[ 250.204000] led off GPIO_LED_3G
[ 250.884000] led blink GPIO_LED_WIFI
[ 251.028000] led blink GPIO_LED_BLUETOOTH
[ 257.876000]
[ 257.876000] led off GPIO_LED_ZIGBEE
[ 259.872000]
[ 259.872000] led off GPIO_LED_SERVICE
[ 259.924000]
[ 259.924000] led off GPIO_LED_LPRF
[ 261.128000]
[ 261.128000] led off GPIO_LED_ZIGBEE
[ 261.248000]
[ 261.248000] led off GPIO_LED_LPRF
[ 261.368000]
[ 261.368000] led off GPIO_LED_SERVICE
[ 261.488000]
[ 261.488000] led off GPIO_LED_3G
[ 268.896000]
[ 268.896000] led off GPIO_LED_ZIGBEE
[ 270.896000]
[ 270.896000] led off GPIO_LED_SERVICE
[ 270.960000]
[ 270.960000] led off GPIO_LED_LPRF
[ 272.152000]
[ 272.152000] led off GPIO_LED_ZIGBEE
[ 272.272000]
[ 272.272000] led off GPIO_LED_LPRF
[ 272.392000]
[ 272.392000] led off GPIO_LED_SERVICE
[ 272.508000]
[ 272.508000] led off GPIO_LED_3G
[ 279.952000]
[ 279.952000] led off GPIO_LED_ZIGBEE
[ 281.980000]
[ 281.980000] led off GPIO_LED_SERVICE
[ 282.036000]
[ 282.036000] led off GPIO_LED_LPRF
[ 283.216000]
[ 283.216000] led off GPIO_LED_ZIGBEE
[ 283.336000]
[ 283.336000] led off GPIO_LED_LPRF
[ 283.456000]
Unfortunately the screen keeps on updating with log information to allow me to see anything very easily, plus it will reboot every now and then - but I’ve typed in ifconfig -a and that only lists 4 interfaces (eth0, gre0, gretap0, lo)
eth0 Link encap:Ethernet HWaddr 78:94:B4:F7:85:AC
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:1281 (1.2 KiB)
Interrupt:3
gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-D0-33-00-00-00-00-00-00-00-00
NOARP MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
gretap0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MULTICAST MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
LOOPBACK MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
None of which have an IP address assigned, so I’m guessing my issue is that I can’t get an IP?
If i type reboot I can see it cycle through everything again, but it still does not pick up an IP address, but it does report some interesting things, see extracts below… e.g.
STANDALONE_LOAD_ADDR is 0xa1200000
..
******************************************
Uboot StandAlone Entry
******************************************
Please choose the operation:
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
9: Load Boot Loader code then write to Flash via TFTP. 0
******************************************
Uboot StandAlone Entry
******************************************
Flash Sector Number : 522.
***************************************************
Sercomm Boot Version 3.00.1
***************************************************
Entering Firmware : Everything is OK.
=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image2 Header Magic Number --> Failed
Image1 Header Checksum --> OK
Image1 Data Checksum --> .........................OK
Image1: OK Image2: Broken
..Done!
=================================================
..kernel addr :0xbc140000
flash base: 0xbc000000, kernel addr :0xbc140000, bootloader size: 0x80000, config size 0x80000, fac size : 0x40000
..Erasing NAND Flash...
.Writing to NAND Flash...
done
3: System Boot system code via Flash.
## Booting image at bc140000 ...
Image Name: OpenWrt Linux-3.10.14
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 1580859 Bytes = 1.5 MB
Load Address: 82001000
Entry Point: 82001000
......................... Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 82001000) ...
## Giving linux memsize in MB, 256
Starting kernel ...
Also after doing a quick search in the file system,
root@MiOS_5510000:/ ls
1 lib proc sys
bin mios rom tmp
dev mios_constants.sh root usr
etc mnt sbin var
foo overlay storage www
where under storage, I found this…
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
Other than the above, I can’t see anything specific to what the cause might be - any ideas ?..
Hi all
Anyone have any thoughts on what to do, no IP, but I could plug in a usb stick if that helps ?
Hi everyone. I had Vera edge in a cyclic reboot. I saw the forum section and decided to try to connect via UART TTL. After connecting, the console appeared with a constant reboot. After the tenth attempt, I managed to insert the command “reboot config” into the console line and the magic happened, the web interface loaded. And the controller was factory-configured.