This topic is aimed at starting the discussion to use our collective intelligence in an attempt to come up hopefully with a solution to migrating a network you may have on Vera FW(Firmware) to the brand new EZLO Firmware.
Starting with some very broad brush ideas:
Use Ezlo as a “secondary controller” on your Vera…
Pros:
Cons:
Please help by responding with your ideas as well as Pros and Cons of each…(We will then collect them all and present them on this post and hopefully will guide the discussions)
From a lay perspective, it is unclear what the barrier is for simply translating one controller’s network to another one, especially since currently, backups from one Vera unit can be restored to a new Vera unit. They probably imagine that one’s network simply consists of a set of configuration files, and that files can be copied, etc.
I think therefore it needs to be enunciated what is the technical hurdle involved in restoring such a backup directly to a ezlo unit. (Architecture? Encryption keys? OS? Incompatible data format? Licensing?) Only then will it begin to make sense that a user might be faced with excluding and including their entire network of devices.
Otherwise, the appearance will be that the company is simply not trying hard enough, since consumers are accustomed to seeing direct upgrade paths from one operating system (e.g. DOS) to another (Windows) - tangibly “different” in every sense, yet somehow preserving the entire userspace - as a matter of routine.
It’s not just the devices. The ecosystem that each of us has built is devices + automation + logic + history (Probably not a complete list, and maybe some overlap)
I think the question is 'How (or even can) can the entirety be migrated onto the new FW (hardware agnostic)
Two out of four (hardware and logic, say) may be enough for some. Others may need three or four out of four. For me, I’d need the first three to stop me from looking around. Not because I don’t want Ezlo, specifically, but because the amount of work that will be required will be about the same to migrate to ANother platform vs Ezlo. So look to see which one’s the best.
In a simplictic view…i was looking at this as 2 problems
1-how a controller sees and controls all the devices in the network (eg: secondary controller in the zwave zigbee can now see and control all the devices…thats task 1)
2-how all the rules/scenes etc can be exported to the new controller…
We are hoping we(community) can re-write the popular plugins in the ezlo fw…(so no migration involved but the rules/logic within those plugins).
Perhaps I am naïve, but it would seem to me that these should have been issues under consideration at the very start of designing a new system, rather than at the end?
I don’t want to get into “you should have done this and that” discussion here…
When designing a system if you have legacy requirements built into your new design, it will make your new system a very different architecture vs not having it as a requirement. Having these extra requirements would have increased the timescales and costs of the development. We choose a clean slate approach to make sure the new FW was free off any issues and future looking. (if you wish to discuss this further you can send me a PM or create a new topic pls).
OK, that’s fine, it wasn’t meant that way. I was really asking whether you HAD considered that. It’s just that I don’t call keeping your existing customers a legacy issue. Enough said.
If the Ezlo hub could be a secondary controller to a Vera primary we can test the new platform with our existing devices.
Eventually I would slowly move my Z-Wave devices to a Ezlo hub and my logic etc and have the Ezlo become the primary hub and then retire the Vera hub etc.
That’s roughly where my thinking is too but I think a potentially bigger issue will be non-native device migration because many of the devices exposed through Vera plugins will take a while for the developers to port/rewrite for the ezlo firmware (if they even do in some cases). Harmony Hub, Broadlink, MyQ, etc. come to mind. Ideally, we would be able to bridge legacy Vera devices to the ezlo until they are supported on ezlo.
As for scenes, they are easy to port from one controller to the other, provided “all” ezlo and vera devices are exposed/bridged (triggers and actions) on ezlo and the ezlo offers similar scene constructs/semantics. My most complicated scenes are in Reactor because they are easier to express with Reactor so if Reactor were available…
Personally, during migration, I’d want my primary focus and time investment during migration to be ezlo because it offers better zwave/zigbee device support including S2 (proven by Atom and ezlo Linux firmware that I have used), new devices can be added without a firmware release, etc. So, if I could rip the bandaid off without loosing legacy Vera device support, that is what I would do.
Net, net, the Vera firmware is static, bugs and all, so I would want to move native devices and scenes to ezlo as quickly as possible with a bridging solution for non-native Vera devices. This will help flush out issues on the ezlo platform and the developers will be able to respond to much more quickly than they ever could on Vera. I’m hoping the end result is a more capable and stable automation solution sooner.
Hi all
you know the Vera platform and the latest Vera FW. You master this solution, you know how it works to integrate zwave, zigbee, bluetooth and IP devices, it necessarily stores this information (id, node, etc.) somewhere, as well as the encryption key used; I do not know how to do it because I am not an IT expert but why not recover this information to rewrite it in the new Ezlo controller, or as an emulator of Vera? Or maybe integrate Vera as an IP device?
Another question: will it be done locally or via a cloud?
I personally hate cloud systems, I prefer an independent and local system
I find the concept of an emulated “Vera mode” intriguing. That’s precisely how Microsoft weaned users away from DOS and onto Windows, though it took them over 10 years to accomplish.
Also, PLEASE ADD A FORMAL BUG TRACKING / BETA TESTING ENVIRONMENT (and use it!), in order to communicate, categorize, monitor and share resolution of active issues.
GitHub, ZenDesk and BugZilla come to mind but I defer to our developer community members to recommend best long-term solution.
yes I suspect that it will not be simple, and that it will require a lot of time. But as indicated above Ezlo has the equipment and the skills.
another track the possibility of transferring the role and the configuration to another controller. I managed to do it from Vera to Jeedom and from Jeedom to Vera a couple of years ago for zwave devices.
My opinion is that best way to go is if you can add vera as a slave to ezlo and this needs to be done immediately because:
That way even the beta testing can be done on a production system where your old setup is intact or partially intact you have to move some devices for testing, disable the automation on vera make new on ezlo so you can play around on a more robust system and not testing only with couple of devices
More people will be wiling to move to ezlo as a production system because devices from plugins like DSC, Paradox, Switchboard, HTTP Switch etc… can be included in ezlo unit at least at the moment this is possible with two vera units as master and slave. Not sure about Reactor.
Big part of plugins is not maintained anymore but still functioning pretty well like Paradox for example which i’m using and i will not move to ezlo without this plugin and i’m sure that it will not be ported because the developer is not maintaining the plugin. I will stay on vera or move to Home Assistant or control4 which i have already interconnected with vera and i use vera as primary. That way i will keep my vera for some plugins that will not be available on Ezlo and are essential for me and believe for a lot of people here also.
It is my impression that this is the place to state my hopes for migration or inclusion. My vera plus is my third vera controller starting with the lite. Most of my success was built on the availability of user written apps which were typically free and somewhat happily maintained. As vera became less and less stable and more and more user developers were dropping their support due to firmware, or apple IOS changes, or other outside changes forcing more and more uncompensated effort to maintain, I minimized my system needs and stopped all enhancement.
So, at this time, I could live with what I have as long as the mobile app was able to continue to talk to whatever servers it needs to provide remoteness, and the controller is able to talk to the servers to exchange whatever they are exchanging now. My primary dependence right now is security. I depend on motion detectors to keep me informed of my surroundings by alerts and emails, and I would horribly miss my interface into my ademco alarm system whose app hasn’t needed an update in years. I could probably replace my significant PLEG usage with something similar assuming a programming language would be included. Reactor?
For me, I think I would be pretty satisfied if I could buy a new controller, have my vera be a slave or something where it would continue to work as it is, and allow me to migrate/develop onto the new platform if and when I was interested and able to learn from others.
I understand the need at some point to be able to just cut off the legacy support. But, if Ezlo just says to start over or even to have to redo all of my devices and their programming at the same time, I might just see if I can further minimize my needs to the level of Siri or Alexa.
It’s for that exact reason that I (personally) wouldn’t even attempt to migrate from Vera to ezlo firmware at my place. I relish the thought of a clean slate to be honest because I still kind of view my Vera/zwave network as held together by extremely thin and fraying 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
Personally, what would be good, would be to be able to migrate physical devices from vera to ezlo, as some of mine are embeded, and at the far end of the garden, so not the easiest to unpaid, disconnect from mains power, and then re-add to ezlo.
I’m happy to work on reactor setups to use these devices, as it gives me chance to review the original setup and consider making improvements, but moving the actual devices is the problem.
Hello
I suppose that the plugins will not be available quickly, is it possible to integrate a system of creation of conditions AND OR by block of the kind as on the zipabox or the homecenter fibaro in order to find the a system a little more free
What about trading logistics complexity against code complexity?
Here is the idea:
Provide a “rent” option for a new Ezlo device. It could be a real renting, or a commercial offer such as try it out for 3 month, and after 3 month either the user sends it back (and then only a small “processing” fee is kept) or the user keeps it (and is then charged full price)
This way, the user have a few weeks with both the old Vera and the new Ezlo devices, and can progressively migrate devices (possibly manually), without loosing all the automations/devices at once.
From this point, we have two possibilities:
** The user can install the Ezlo FW on the Vera, and then I’m assuming that the “transfer” from the Ezlo device to the “Ezloified” Vera can be relatively simple. The user can then send back the Ezlo device.
** The user decides that finally, he will keep the Ezlo device and retire the Vera.
