I will give a brief overview on the first post when I have a moment.
Any chance of getting that write up? Iāve acquired an edge acting exactly as you described your plus acting.
My apologies, Iāve been really busy with the day job and other personal projects.
From what I read/recall a long time ago, there are easier ways to revive some of the older platforms it seemed like the plus was difficult one. You may find information out there as to how to recover your device without this risky method.
I donāt know if the edge is remotely similar to the plus, but here is what worked (general overview), FYI this is risky and can kill your device:
- Find the serial port on the board (if it has an exposed one).
- Determine the pinouts.
- Connect to it using the correct voltages.
- You may need to play around to find the serial port settings (baud rate etc)
- Once there you can interrupt the boot process to do recovery/reflash.
1 Like
did a video on this a while back its easy
Video: Recover Bricked Vera plus - General Discussions - Ezlo Community same way as the vera lite u just need to request the bin firmware file
I have followed the steps of @richie.digital with the bin provided by Vera support (witch where very helpflull), but didnt fix de problem. So i went with the @Majimus aproach and succed to unbrick de VeraPlus.
The four pins from left to right for making a direct serial ttl conecction are 1-GND, 2-Connect RX from serial, 3 -NA, 4 - TX pin.
I used a USB to TTL adaptor (make sure is 3.3V) $5.
The vera must be connected to power before connect the pins to the board or it wont power up.
After that i use PUTTY to make a serial connect with parameters 115200,8,n,1.
After that magic occur and i have acces to the VeraPlus console as with SSH.
To fix the unit i mannually configure the network connection using ipconfig and running mannually the update sh.
It was looping in a OpenWRT update process, but with the console ouptut you have debug info.
Thanks to @Majimus to this post as i was able to unbrick my vera using a 5 buck usb adapter.
One word of advice donāt update the vera if you current firmware is more than a 2 years old. Go the slow road and update each consecutive firmware one by one using using the Custom firmware URL.
1 Like
Great job, @alangraph
Iāve got a bricked VeraSecure, that I couldnāt throw out - Iād like to try and resuscitate. Opening it up I can see a 4 pin connector on the board, which has what looks like āJ6ā on the further left, and ā4 ā on the furthest right
How does that map to your 1-GND, 2-Connect RX from serial, 3 -NA, 4 - TX pin.? I have a USB to TTY cable on standby 
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 ?