New EZLO Linux Firmware pre-Alpha starting soon


We are a jittery bunch and easily spooked. I guess we are just passionate about our little Vera black boxes.

Glad to hear we can likely expect a local API.

The other major concern by many of us, is the 3rd party plugins situation though.


I am glad to be proven wrong and appreciate your intervention. It looks pretty good from what I can see. websocket, json, mDNS. A very important piece of the puzzle!



I know you are passionate about the work and time you’ve been invested in the Vera platform, and I’m always excited to have users like you to work with. We all want to make our products successfully.

We’re still discussing to see what is the best approach for the plugins.
We’ll definitely need to involve developers, but as we previously said (and as you can see) we are still building the core of the Ezlo Platform.

Just for everyone to rest assure, we’ll allow 3rd party plugins, NO plans to stop that - and moreover we want to give you all the tools you need to create the best apps for Home Automation - that’s why we need your feedback, to build this together. Please post as many ideas/requests/feedback in this post as possible and I’ll make sure to add them in the list.

Constructive is subjective. I was making it clear to the team what the definition of BETA is. Which I think was constructive given the name change by the team.

1 Like

I think if you’re setting yourself to believe that the entire catalog of plugins is going to run happily on the replacement firmware, you’re gonna have a bad time.

The engineering realities of that are pretty grim. Let me hit a few highlights:

  1. eZLO needs to do everything they need to do to advance the firmware, yet still make the legacy API work compatibly. This will inevitably lead to conflicting and irreconcilable requirements, and when they arise, the requirements of the new will win.
  2. Even if there are no conflicts, the chances of them getting it 100% right are slim, as the existing environment is the product of years of development and countless exceptions, nuances, and featurelets, many of which are likely undocumented except for their subtle manifestation in code. That’s not meant to be a slight on them or their effort, it’s just a reality. The system is so old, and so complex, that the idea that you can reproduce it with 100% compatibility in a new environment in a fraction of time is a fantasy. There will be mistakes made. There will be omissions. There will be unexpected side-effects.
  3. They are adding data to the system. If the legacy API does not return these new data elements, the plugins may run into scenarios where other actions they perform damage new system structures by removing data, or providing conflicting/incompatible data (unknowingly). It is also possible that the receipt of unexpected data may cause erroneous operation of the plugin, up to and including total failure.
  4. Unfortunately, many of the plugins in the current catalog and in common use today are… I’ve seen too many that operate more by accident than intent. The very shortcomings that the current environment ignores may not be ignored in the new environment.
  5. Not unreasonably, once the work is done, eZLO will assert that the result is the new reference specification for the legacy Luup API, and any failure of the plugin to operate on the compatibility API will likely be dismissed as the fault of the plugin (and rightly so). That means the community is still left with a non-working plugin, and in need of a community developer to fix it.
  6. Any discrepancy that is identified that they do agree to fix will likely require a turn of firmware, so time goes by while you’re waiting to get past that hurdle… so you can move along far enough to find the next one. Lather, rinse, repeat.
  7. As we all know, not all bugs stand up on day one and announce their presence. Sometimes they come much later (imagine something related to DST changes, seen only twice per year, or worse, only faulting when adjusting backward, so once per year). If everyone is out of the rapid turn cycle of pre-GA, like the previous bullet, new firmware required to fix, but now it’s going to take a lot longer, and in the meanwhile, you’re scr… without a functional plugin.
  8. It’s not going to stick around forever. The legacy Luup API will be deprecated the day it’s released, so anything that does operate on it is on borrowed time.

In addition, as a developer, I want access to all the best new stuff. So I have no incentive to stay on the old APIs, and not do whatever is needed, rewriting included (and expected), to get access to all the greatest things that this new firmware can offer. Anything else is just buying time, wasting time.

So, while I believe they may produce a compatible API, I think it’s optimistic to the point of being intellectually dishonest that everything is going to work and life will go on uninterrupted. I may be wrong, but I think the odds are far too long the other way.

Edit: we now have, in the API documentation just previewed, sufficient evidence of point #1: the structure of scenes in the new system is vastly complex (too much so, I think), and includes features with no analog in the legacy system. How will the legacy API present a complete picture of such data? What will an existing plugin do if presented with such unrecognized data?

Edit 2: This raises the additional issue that the current Luup API encompasses not just the functions and values/tables found under the luup global in Lua, but also includes the luup requests that are possible, as many data elements in the system are not accessible except by self-querying the Vera over HTTP. The prototype API documentation uses WebSockets, which is a more complex interface and ill-suited to single query-response, so we already have (a) a gap in the new API (no generic HTTP/HTTPS interface–hopefully they’ll address that), and (b) the uncertainty of whether the “compatibility” API as yet discussed includes the ability to make “old school” luup requests at all–if not, many plugins are DOA.


So we are likely screwed :joy: and losing some of our beloved plug-ins.

I also just posted about single line HTTP commands on the new thread.

1 Like

the exchanges are super interesting, I say immediately I am not a developer, I do not understand much in the operation of a code. The question that comes to me after this reading is: on the new system why not integrate the functionality of the most used plugins directly into the capabilities of the system and API? there would be no need to re-develop or modify the old plugins with the risk that it would not work since they would already be included as functionalities with the latest languages

Start your plugin list now!

I agree some 3rd party plugins should just be part of the core system and functionality.

But which plugins?

The plugins that are important to me, you may never use and vice versa.

My number 1 plugin would be the Harmony remote control plugin and also the Imperihome app plugin and Philips Hue plugin.

But if Ezlo build a dashboard app with the same functionality as Imperihome then I won’t need that.

PLEG I can’t live without now, but again maybe Ezlos new logic engine will make it obsolete.

However there are more plugins I use today.

a small list:
-System Monitor
-HouseModes Plugin
-Ping Sensor
-RGB Controller
-UPnP Event Proxy
-Combination Switch
-Day or Night
-Virtual ON/OFF Switches
-Variable Container

1 Like

Did I miss something yesterday? :wink:


No, you did not. We’re delaying the release to this Thursday 27th of February, to coordinate with the other deliverables as well (like the mobile apps) :innocent:


Perfect - thanks for the update. :clap:

1 Like

This is looking very interesting - I agree with the concerns raised by our estemed 3rd party devs regarding the lack of a local UI. Making the mobile UI before the Local UI is indeed ar$e-about!

That said, I’ve put my hand up to try it on my spare Edge and Im happy to move a couple of non-critical z-wave devices over to it to test with.

I would like to see a way to add the Edge to my existing z-wave network as a second z-wave controller - the current Vera method of connecting 2 controllers over the internet is beyond stupid imo and defeats the purpose of having multiple local z-wave controllers! Sure route some traffic locally over IP between the 2 controllers but make them operate as active-active redundant controllers as the z-wave spec intended!

EDIT: Btw, is the new platform based around the state-engine concept? Imo this is one of the major strengths of Home Assistant.

100% agreed! I too want to see an ability to “group all my controllers” …I should be able to create different groups of controllers if I want to, or get them all operating as one group.

1 Like


Is the ability to add the Linux-Edge to an existing Z-wave network as a secondary controller a current function? This would make testing much much easier.

what i have in mind is you can add “any” ezlo controllers together into a group.

1 Like

So thinking about this feature, honestly this is quite brilliant! I have some Belkin gear and some Brunt Blind motor’s that don’t work with Vera and are unlikely to ever have plugins written, so I drive these through only through Alexa.

Being able to use my Amazon Alexa system as an integration layer for these is a stroke of genius. Nice work guys. :clap:


Thank you!
Ezlo can now control “everything” literally! You can also have “cross control” eg: Siri controlling Alexa etc happening too! (Imagine a scene that has both ezlo and alexa components run by Siri shortcuts! Now Siri is controlling Alexa!)

We have much more innovation coming…much much more! This is only the start!

1 Like

Ezlo VOI seems great, but I hope this is not what you meant when you stated you aim to integrate every device on the market?


There are lots of possibilities that come from the Ezlo VOI feature and we are actively working on extending the list of possibilities and making them easier to understand and use, by our end-users.

For example, per your earlier post:

Until we roll out the “group all my controllers” features, you can use Ezlo VOI to as a temporary workaround, to group all controllers you have. You can even group your main controller that still runs the old firmware and is linked to the old cloud to your Vera Edge running the alpha version of the new Linux Firmware.

You need to have the old platform Vera skill enabled, then you can use Ezlo VOI and create a scene in your Vera Edge running the new Linux Firmware, where the VOI command is “Run scene X” or “Turn on light X”.

Using VOI, you can even control smartthings controllers from Ezlo and everything connected to them. You can group any controllers!