Ideas about how to Migrate Vera FW to Ezlo FW


IMO, the cost of the controller and replacement of the controller is not an issue. The Athom sells for $30,-, heck let the Plus cost $100,- I am fine with that as that price also covered everything needed to have Vera/Ezlo keep the environment up and new releases coming. For me compatible means swapping out the controller, restoring a backup and up and running again. Many of us have done that as far back as from the Vera 1 all the way to Plus or Secure. That path has stopped though. The Ezlo firmware is totally different firmware with totally different internals. It looks nothing like the old thing. Basically we go from MS-Dos to Linux, and from one big code blob to micro services.

I have not figured out a migration path yet. Can you move Z-wave devices over without needing to excluding and including, I do not think so, but I am no Z-wave protocol expert. So maybe Ezlo can come up with a way as this is what most of us really want of our next controller. Can it be done when installing the Linux firmware on an Vera Edge/Plus/Secure? Maybe as the z-wave chip has the details, it would be great and Ezlo would need to add it to the Linux FW.

As for plugins. Well, they need to be completely rewritten as they are build for the MS-Dos blob and will not fit the Linux micro services architecture. That will prove a challenge as not all plugin authors are still around or would want to maintain two versions of their plugins (I dropped UI5 versions although people still ask for it).

One option I see if that you can include a Vera in the Mesh of controllers you can have with the Ezlo FW. Then users can gradually migrate, both plugins as they become available on Ezlo FW, as devices when they need replacing anyway, or as budget allows.

However, it is like Corona lock-down unwind. It will be baby steps, will take its time, and I have no idea when the first big rock concert will be I can go to again. There is a promise of a vaccine, but when, and for me? No one can tell (if they do, don’t trust them). And i do not like it one bit.

Cheers Rene


For me, Zwave network migration is a blocker. I’m ok with doing scripts from scratch, but I can’t migrate more than 70 devices because many of them are inside appliance or hidden somewhere behind furnitures, etc.
I truly hope we can join a network as secondary and then promote to primary controller, at least. Ideal path will be a backup from Vera and restore of devices into eZlo.
I guess I’m not alone in this request…


So, guys, was I wrong in my earlier assumption that a user’s setup could be backed from Vera Plus A to a replacement Vera Plus B??

I’ve asked this in one form or another on various occasions, but never heard a definitive answer. THANKS!

  • Libra

no, you’re not. You can backup your config and restore to a brand new device and have all your scenes, devices and so on restored. it’s the main advantage of Vera, imho.

So, please riddle me this… why is that option simply not viable for moving a given setup over to ezlo hardware? What am I missing?

Hi @LibraSun,

The Vera Firmware’s and controllers where backward compatible, most of the time for most of the devices. So there you can take a backup of one controller and restore it one an other, and for most part take off where you left.

The new Ezlo RTOS and Linux based are a complete redesign and will not be able to take a backup from the Vera firmware for the reasons i mentioned (MS-Dos vs Linux etc.). Maybe an option can be developed to keep the Z-wave devices if you install the Linux FW on an Vera Edge/Plus, as you will be able to install the new FW on the Vera line of controllers (I have a Beta test version of that running). Then once you are on the new firmware backup and restore should at one timel work between Linux controllers again. I think is a must for me actually as it is critical when a controller brakes down as we all know, but right now that is not there yet.

Cheers Rene


Where are we with the ideas proposed and what is feasible?

1 Like

No answer ???

In order to expedite and facilitate development on ezlo firmware by this Community, it would be extremely helpful to have an official SDK^^ that is both FREE and full-featured (driver/editor/compiler/debugger, etc.), changelogs for each firmware release, as well as a full set of documentation for each device. (I don’t even see User Manual links on the sales/support site.)

Oddly, I’ve received no response at all to earlier pleas for ezlo to implement and maintain a formal wiki (to preserve institutional knowledge), better communication with beta testers (to streamline and guide the revision process) and a buganizer system (to gracefully handle bug reports), so it’s hard to gauge how much emphasis the company places on efficiency and product improvement.

Are any of these priorities, and if so, what kind of timeline are we looking at here??

^^NOTE: With Vera, users were without proper programming tools for several years, until homebrew products like this and this came out. I doubt any of us would wish to wander in the dark that long again.


Hi @LibraSun,

As you know we started to share in the community the APIs we have so far, as well as the API testing tool. We’re working on presenting everything in our official website.
User Manuals are actually a set of articles that explain the features, see here an example for Ezlo Atom.

what type of information you want in the formal wiki?I’m assuming is different than what we’re doing in the support knowledge base.
Buganizer system - this is a great idea, I’ll circle this idea internally and come up with a proposal.

Yes, we’re working on the above items as we advance also with the features, especially on the API part, but I cannot promise you a date. Until we’ll have everything in the official pages we are trying to accommodate via answers and posts in the community.


Thanks for the insights, and the links. Until today, I was actually unaware that there was a Knowledge Base! Most tech companies (MS, Logitech, LG, etc.) require someone in Support to chime in on every new thread, pointing to a FAQ or at least making suggestions. (Of course, I realize the Vera controllers generally don’t lend themselves to step-by-step solutions, but still some – arguably large – subset of issues surely must.)

My feedback re: “wiki” and “buganizer” was strongly based on seeing customers (old and new) arrive here daily in the Forum with basic “How To” questions, often the same ones over and over again. Perhaps now I’ll have a better chance of linking them to the proper place for problem resolution. Anything’s better than keeping track of 1000 disparate workarounds in our heads!

Aside from some small corner of the Forum (which seems to keep moving?!), we don’t even have a formal place to submit Feature Requests; so these wind up ensconced and hidden in lengthy, often unrelated threads.

My other recommendations stem from MCV never having gotten around to publishing an “official” SDK – the sine qua non of all robust platforms – despite having 8 years in which to attempt it.

I just don’t want to see ezlo go down a similar road, asking its most avid customers and devotees to do all the heavy lifting. Our time (if the Forum is any indicator) could be spent doing much better things than fielding “Getting Started Guide” and “Troubleshooting”-level FAQs.

So again, thanks!

  • Libra

I’d also like to see a proper system for submitting bug reports with tracking and for submitting new feature requests.

Things get buried and lost in the forum threads.


A big move between different architectures means a fresh start for me, but I can understand why others with lots of logic and plugins wouldn’t want to deal with that if possible (this is why I use homeassistant for all that stuff).
It’s cool that you’re attempting it, but please don’t compromise the new firmware to make the old janky mess fit


It’s for that exact reason that I (personally) wouldn’t even attempt to migrate from Vera to ezlo firmware at my place.

For me, Zwave network migration is a blocker. I’m ok with doing scripts from scratch, but I can’t migrate more than 70 devices because many of them are inside appliance or hidden somewhere behind furnitures, etc.
I truly hope we can join a network as secondary and then promote to primary controller, at least. Ideal path will be a backup from Vera and restore of devices into eZlo.

I’m in the same boat. More than 70+ devices and some in some places where I hardly can get hold of without a lot of effort (not ideal, but during installation in a house from 1880-ish, there was no other way). There are also devices I can not get to without having an electrician on hand (building regulations here in Norway).

Doing a completely new installation of all my devices will be a very big job and expensive so a network migration is a showstopper for me too. If that will not be possible its quite a lot cheaper for me to switch to a controller which will let me do so.

Though; I am happy to re-include a handful of devices and recreate all my scenes on a new controller.

Just got the email advertising the new Ezlo Plus and Secure. First place I ventured after looking at the Ezlo product was here. Does this mean there’s no migration path for simple upgrades from Vera MiOS to EzloOS?

Not possible at the moment. This is work in progress.

That’s a show stopper for me. I have some custom devices and plugins running, like Pool Control for Jandy through Autelis, Reactor, Harmony Hub, Emby, Garage Control and Rachio to name a few. Do you have a catalog of available plugins and compatible devices? No need to drop $200 to bork a running system with a new one.


It would seem to me the best place to start would be device migration. I would assume all of the information required, wrt devices, for the new system would be available on the old system. Is it not possible to create an app that translates backup file data to an importable (to Ezlo) device file?

1 Like

I agree, that is why we are building it so that you current Vera can co-operate with New Ezlo under one account. We don’t have any plans to drop support for old Vera in the short or medium term.