Upgrade to veraPlus - Userguides disappeared

Vera Controllers, Services & Devices Vera Controllers & Cameras
#1

Last year there were userguides in the getvera-costumerportal for upgrading veraEdge etc. to veraPlus, eg:
https://support.getvera.com/customer/en/portal/articles/1840689-intro-upgrading-your-controller
https://support.getvera.com/customer/en/portal/articles/2345058-to-veraplus-verasecure-from-veraedge?b_id=712

Now they are disappeared: These webpages report: “This article doesn’t have a translation for English”.
Is there a problem with upgrades or is it a bug in the portal?

#2

Yeah, I stumbled on the same :o
You can always use the mighty Google Caches to make the articles visible :wink:

[url=https://webcache.googleusercontent.com/search?q=cache:agBGxktVXdYJ:https://support.getvera.com/customer/en/portal/articles/1840689-intro-upgrading-your-controller+&cd=1&hl=nl&ct=clnk&gl=be]https://webcache.googleusercontent.com/search?q=cache:agBGxktVXdYJ:https://support.getvera.com/customer/en/portal/articles/1840689-intro-upgrading-your-controller+&cd=1&hl=nl&ct=clnk&gl=be[/url]

[url=https://webcache.googleusercontent.com/search?q=cache:LuB7YzOu4icJ:https://support.getvera.com/customer/en/portal/articles/2345058-to-veraplus-verasecure-from-veraedge%3Fb_id%3D712+&cd=1&hl=nl&ct=clnk&gl=be]https://webcache.googleusercontent.com/search?q=cache:LuB7YzOu4icJ:https://support.getvera.com/customer/en/portal/articles/2345058-to-veraplus-verasecure-from-veraedge%3Fb_id%3D712+&cd=1&hl=nl&ct=clnk&gl=be[/url]

#3

They have been replaced by these two documents.

https://support.getvera.com/customer/en/portal/articles/2946226-upgrade-vera-legacy-controllers-from-ui5-to-ui7-firmware?b_id=712

https://support.getvera.com/customer/portal/articles/2942693-how-to-migrate-to-verasecure-veraedge-or-veraplus

With the new Z-Wave firmware versions on the new platforms, there is no need for the additional steps described in the old documents. If you’re looking for something specific please let me know.

1 Like
#4

Getting Security errors on those links. Might want to fix that.

#5

Me too,

#6

Yep, certificate errors. It seems the certificates are expired as of today:

support.getvera.com uses an invalid security certificate.

The certificate expired on Tuesday, December 18, 2018, 15:24:28. The current time is December 19, 2018, 11:27 AM.

Error code: SEC_ERROR_EXPIRED_CERTIFICATE

#7

Thanks, guys, we’re on this. I’ll keep you posted

#8

Support pages back, up!

Thanks

#9

@Sorin, Given no more firmware upgrades will be available for Vera 3, I’m trying to perform this procedure to move from a Vera 3 to VeraPlus. My VeraPlus has an external Australian AEOTEC ZStick. Having restored the backup, my devices are all visible but the Z-Wave port is set back to standard (expected, as restored from my Vera3). As soon as I change the Z-wave Settings “Port” to /dev/ttyACM0 all my Z-wave devices disappear.

#11

@Reliance, if your Z-wave Stick does not have devices included, when you switch the port to its path Vera will read that path and since empty your devices will go poof as they belong to a different “path”.

You will have to add your devices on the Stick if you want to control them with the Stick or add them to Vera if you wish to control them through Vera.

Since the two Controllers use different z-wave chips you can’t merge them and have one of them control devices from another.

If this is not the case, please give me more info as I may be a clown with a Yellow Suit sometimes.

aye-bye!

#12

@ionut.s has it right. You probably recovered from a backup from the vera3 which did not have the external stick. Correct? If so, the recovery process will have the zwave data written back into the onboard zwave stick. In order to change the behavior, I have two proposal as to how to do it:

  1. Is simple but would require you to reconfigure all of your devices because… upon luup reload with your empty zwave stick, the vera (quite stupidly without user approval) wipes out all of your zwave device data.
    A. The process is as follows: after you have recovered from your backup, switch to your external USB stick port. It should be where you are now with all your devices wiped. Very quickly after this restore and making sure that you have not backed up your zwave network yet go to B.
    B. SSH into your new vera plus and send these 3 commands:

Stop_cmh.sh
touch /etc/cmh/dongle.restore
Start_cmh.sh

C. After you get back to your vera, you may need to reload luup once more. You will then get all your devices back without names and all unconfigured.

  1. A better way to do this is to decompress your backup file on a different system and edit your /etc/cmh/user_data.json file. I think I would prefer CS to do this for you but just in case you want to do it yourself:
    A. Decompress your backup file with tar. (Almost any zip decompress tool can do that)
    B. Go into the etc/cmh folder and pickup that user_data.json.lzo file and decompress it. If your computer does not have the tool to do it, you may need to send it back into the vera and ssh into the folder where you dropped that file and run

pluto-lzo d user_data.json.lzo user_data.json

C. Use a text editor to edit that file and look for ttyS0 which you will replace with ttyACM0
D. Compress that edited file back where you have the pluto tool with

pluto-lzo c user_data.json user_data.json.lzo

D. Place the newly edited lzo file back into the etc/cmh folder of your backup folder and compress the backup back into the original tar file. (Very easy to do with Linux but other tools on windows and mac will do it too)
E. Now restore your vera from this new backup file making sure your USB dongle is plugged in.

#13

Now, to be honest, I would not do this even if it has the chance to work properl. Depends on how many devices we talking here. If around 20…it’s not worth the trouble, if over…debatable.

But, the solutions are great, if you are keen to play around with the box and its mysteries, there you have it, some simple yet funny steps (funny as it might behave differently each time you try it).

#14

:smiley:

@ionut.s

As you can see I have tinkered at the OS level quite a bit. For me it has works very consistently… as long as the luup engine is stopped. My suggestion would be to make this a little easier by giving the choice to change the zwave port during the restore process…

#15

I don’t want to insult anybody here, but you know; There is a difference between knowing the path and walking the path.

“Doing stuff” requires knowing exactly what you’re doing, not because it may not work, but because it could go bad and you may have no way to explain what you did so it could be fixed fast and efficient.

I may be crossing a few lines here, but it happened so many times in the past that I am pointing this out just as a “Hey, sup”.

Regardless, let’s be optimistic here, the chances are quite high as the process is well explained and not that hard all together.

~noOffense

1 Like
#16

No offense taken. And appreciate your input. I honestly would have rather not have had to go tinker and investigate, reading every bash scripts of the vera. The only reason why I have done so is because of the instability (luup reloads), the uncontrollable cloud server bondings, unpredictability and the excessive automation/lack of user control of the device/radio configuration and what I have later discovered incredibly poor flash partitioning. I learned a lot about linux and openWRT, Much more than I ever wanted to know. I have made numerous suggestions and requests to CS and was either ignored or was met with powerlessness. My post above is to offer a solution to a problem. Though I would still recommend to go to CS, the answer of: “just restart from scratch” is just not acceptable to me and never will be. The zwave stack was specifically designed against having to do this and the vera is particularly difficult to deal with for inclusions and configurations which has also encouraged me and many others to look elsewhere. I am here to help the community. I don’t pretend to know everything but have tried, observed and tested a lot of migration (I owned 6 veras over the years), failure and recovery scenarios and am just sharing one of them.

#17

Actually, I didn’t mean that to you, but others that do not have the same knowledge and abilities to search and investigate.

I like it when people do things their own way, but I dislike it when people copy-paste without know “what does this button do”.

This is why I said “no offence”, to everybody else trying out things without knowing a bit about it, but claiming that it failed or did not work. Not all things go as planned or explained as things differ with each setup.

Sorry for the confusion.

#18

Thanks @rafale77. I’ve been trying to follow path 2 but have got stumped when I get to the pluto-lzo -d user_data.json.lzo step. I’ve been uploading user_data.json.lzo from the decompressed backup on my windows machine using Apps / Develop Apps / Luup Files / Upload which gives me a user_data.json.lzo.lzo file on the Vera. When I enter the command pluto-lzo -d user_data.json.lzo.lzo I get a Segmentation Fault.

I’ve logged a support ticket and sent a copy of the backup file with the hope they can do the substitution of ttyS0 to ttyACM0 for me.

#19

I now understand where you are coming from.
One big disclaimer for those who want to do this:

Please make sure you are comfortable enough with editing files and SSH before you start doing this. This may not brick your vera but may crash your luup engine if you don’t do this right. (Typo, wrong file location etc…). So it will never be unrecoverable but know that the support team may have a hard time helping you if there is a problem. To make things safer, I can’t recommend extrooting the vera enough.

I may actually write a bash script to do all of this at some point to make it easier if I get the time to do it but in my mind I still want to request the mios dev team to look at creating a pop up window to enter the serial port to which you want to restore your zwave network backup instead of just defaulting to what is in the user_data.json.

#20

Ok That is because you are not uploading the file back on the vera correctly. Using the UI will recompress the file a second time… and will put it in the wrong folder. If you want to do it this way then after editing the decompressed file, do not compress it again, instead Upload it through the UI. The problem is your luup engine at that point is supposed to be down so you should not be able to do it to begin with but I guess if you managed to catch your data file before the engine overwrote it, it does not matter.
Once you have it uploaded through the UI, SSH into the vera and run this one line at a time:

Stop_cmh.sh
mv /etc/cmh-ludl/user_data.json.lzo /etc/cmh
Start_cmh.sh

Don’t hesitate to PM me if you get stuck.

1 Like
#21

I’m butting in totally off topic but . . .
Love the phrase

Chris

1 Like