Ezlo controllers Beta enrollment starts now

Just change it a local device. I have every device, Vera included, getting it from my synology nas. There’s a thread on how to do it in the forum, search for it.

Hopefully some of the very active plugin developers here will get all the help they need to create new versions of popular plugins as this will naturally aid the speed of adoption of the new kit (missing key apps can be a blocker for people to jump). Will things like hue be baked in? Being able to use our rfxcom will also be key as this gives us access to control not native (for somfy). Excited by the new hardware.


So this puts the “high end” controllers in the “pi zero/pi 2” performance range.

I think you are going to have problems in the market. Homeseer’s Zee2 is based on a Pi3B for $150 and they have a plugin library which EzLo will not for some time. Hubitat is less powerful but only $99 and has a host of SmartThings derived code, making it the obvious upgrade path for those users. ISY is the last hope of insteon users so they have a small, reliable base of support.

You will need a massive (by HA standards) marketing blitz and aggressive pricing to garner a second look.

To only look at the CPU power to evaluate the “performance” of a system is a shortsighted view in my opinion.

What makes up a system is the whole system that is made up of hardware and software both.

If i can’t turn a “light on” instantly using a 200MHz CPU…what the hell have I coded???

Here is the problem I see in the home automation world…
Its driven by people who want to sell hardware only…to these people software is merely a tool to sell their hardware…so they botch something together to give to users. They are not thinking about making the code efficient …just the opposite actually…they don’t make money unless you buy new hardware…so its in their interest for things to run slow so that you “upgrade” to a “more powerful CPU”…

Not sure if anyone here writes firmware or not…but for us, its crazy to think we need Gigahertz CPUs to do basic functionality of shuffling messages with minimum computation.

All of the users are lulled into thinking they need “bigger cpu”…because hardware providers need you to keep buying the latest!


where can we find the list of devices compatible with the new controllers?
will I have the same inclusion and use problems as my fibaro keyfob or my smart implant?

You’ll find them listed in weekly posts going back a month or more:
Newly Integrated Devices on Ezlo Platform 2020-April-15
Newly Integrated Devices on Ezlo Platform 2020-April-09

With the master list being maintained here.

1 Like

You release specs, you should expect people to look at the specs and discuss them.

That “200Mhz is enough” approach works for your RTOS solutions since after all ISY has been doing that for a decade. Of course, they have also discovered that 200Mhz isn’t enough for apps and web integrations which is why they introduced a separate Polygolot system, which can run on a Pi or an x86 system. Part of that is integration with external APIs which are not efficiently designed.

Your linux firmware solutions have the same challenges as every other linux HA system. You have to manage the OS, mesh network management, web server, local API, remote API, cloud services, plugins and of course make the automations feel near-instant.

Will your hardware handle the core automations? I expect so. Will you be able to support the cloud services, IP-based device support (Mqtt, tasmota, CHIP etc) and various plugins? Again, yes, although plugins will probably take a while.

How many of the above can be installed before you see slow downs? Ah, that’s the outstanding question. Homeseer adds an artificial limit on zee2 to ensure there is sufficient headroom, despite more powerful hardware. Hubitat is on comparable hardware and it has been found to bog down after a few dozen devices. Isy as already stated uses a 2-part solution of RTOS+Linux.

We will have to wait to see how your implementation performs relative to the other products, how your price point stacks up, and if you either entice sufficient 3rd party plugin developers or make a sufficient library of ezlo plugins.

Memory usage has nothing to do with CPU speed.
Its the way its architected, where they may have to load everything before they execute because they don’t do a proper memory management.
The system slow down will only happen when you run things in parallel.
So the question is: What will you be running in parallel that will slow down a 200MHz system? Put all 231 lights on at the same time? Seriously all I see in home automation is “bloated” software done by hardware people who know nothing about how to write software! (sorry to be blunt). And all the users are brainwashed by hardware people to demand the next big CPU…

and we do all that under 500Kilobytes in our RTOS! our webserver is 25KB if no SSL 31KB if SSL… All zwave stack hand crafted from scratch to be efficient and fast.
I really am amazed to see that people here claim they are technical people but totally ignore the OS and FW performance issues for CPU and only think CPU matters…

You guys have been used to software written by hardware people for far too long…

Parallelism comes in the collisions. Can you monitor that Hue hub over local IP, do your system maintenance, handle a scene edit while triggering an event based on internet weather reports,run that data logging app the user installed and update the two wall tablets?

If you get the prioritizing right, probably close enough to keep the user happy. But getting that prioritization right is a big if. Can you tell a non-time sensitive data logging app from a plugin that controls a web-based light? How far behind can your tablet refresh lag before it irritates users? Can you delay the system maintenance task or will it cause other issues later?

As for hardware vs software, your web server may use that little ram if you aren’t caching any icons, which pushes the load to your storage. Does more ram make lazy coders or does the search for a mythical efficiency come at the expense of flash life? Tech weenies can argue about ram footprint vs flash life for days, weeks if you add in engineering expenses for optimizing code.

Users will want to know “will this slow down when I add the Kasa plugin?” “If I access a camera remotely, will the lights still respond quickly to the voice assistant?” “If I add this data logger, does the device thrash when six automations trigger at the same time?” “When I have 40 devices does the app make that comprehensible or does the UI go all squirrely from the javascript loop?”
“How long will it take to get support for (new hot thing)?”

I am the skeptical HA curmudgeon who’s going to look at competitors and say “There are four engineering teams who have failed to produce infinite punch and pie, what trade off are you making?”

ou, as CEO/owner, are the corporate cheerleader so you’ll say “Relax, its gonna be awesome! Punch and pie for all!”"

I expect some punch and some pie but not for all. Or, if for all, then for a price that doesn’t make sense. You expect to prove me wrong.

When your products come out we will see if you did give punch and pie for all at a price worth buying.

Until then, I will look at the data in official posts and compare it to your competitors because I don’t have a product to test.

(Semi-off topic: I worked with a programmer who wrote assembly modules for a C based real-time telecom billing system. It was hyper fast…until the SGI hardware it ran on was EOL and it had to be moved to x86.
My point is optimization targets specific use cases. These days the $ cost of more powerful hardware vs opportunity cost of not supporting a wider range of use cases is not an automatic pass.)

Thank you

will the plus plus version also be available in test version?

at least you agree that CPU power alone is not an indication of the overall system performance. Glad someone understands that.

Beta development task.
I have used V1s, still have three V3s running, and three Vera Plus.
Went from UI5 to UI7.
If anyone drops out would be happy to get in on the Beta testing.
I’m retired SVP from Cellular and Cable cos.
Ham radio
Crestron programmer but limiting to my personal, two friends and remote for two remaining systems my Nephew’s Home automation company has (they went full Control 4) all comp by the way as a hobby.
Installed and maintain the three(3) Vera 3 for friends, still in-service; I want them to be changed out.
Installed and maintain the converted three(3) Vera 3s to Vera Plus, still in-service.


@jerrywolfer looking forward to working with you on this beta!
thank you for taking part.

Looking forward for them in the mail!

1 Like


@melih, is it possible to migrate from Vera to Ezlo easily (with a backup file or so), or do I have to exclude and include every device - device by device?
Have a nice day!

A bunch of us Vera users have asked the same thing over the past few weeks, only to learn the answer is a hard “No!” There will be no migration path from Vera controllers over to ezlo hardware. :sob:

You’d have to exclude and then re-include every device manually.

However, future firmware revisions on both the Vera and ezlo platforms will (from all accounts) be known as “ezlo firmware” so there’s at least a chance your existing setup may one day “live on a Vera running ezlo firmware” – in which case, let’s hope your Z-Wave and Zigbee devices all make it through that process intact.

1 Like

You can’t have it all… New hardware, new type of firmware, and hopefully a lot more stable compared to the old firmware/hardware. That is worth a full day of reconfiguring everything for me… Maybe migration comes later, can’t blame them, let’s first give them time to make a stable base, migration is less important for me than a good stable base.


at least we leave on a clean installation

What about the option to shift controller, won’t this save the exclude/include ?

1 Like