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.
did a video on this a while back its easy
Video: Recover Bricked Vera plus 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.
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
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.
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.
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
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 ?