We have some major issues I think. If all the plugins need rewriting that is a big problem.
Not all developers will want to do that and some have already expressed so. And what about the still working plugins but where the dev is no longer active or has left Vera for some other platform already. We just lose those I guess.
No local API would also be a big problem for many power users and its those guys who would recommend Vera / Ezlo to their friends and family and colleagues.
Moving away from LUA code? Another big problem we are all used to that language now.
It’s not our train set, but I can see a big rail crash if they aren’t very careful.
I would be happy to buy the top of the line most expensive flagship Ezlo hub product, if its decent and has a good Web brower GUI for setup / configuration and a fully customisable mobile dashboard app.
And it has better Zigbee device support and good / quicker Z-Wave device support for new products on the market.
Hell I’d even be willing to rebuild my entire mesh network and scene logic again from scratch, if the new Ezlo logic engine is as good as PLEG or Reactor and there is no migration path. A major undertaking BTW.
But I would have to seriously think twice if I lose my favourite plugins and we have a crippled Cloud Portal only API access or no API access at all.
I don’t see the point at all in these new low powered and spec Ezlo USB sticks and plugs. I want a box with some horsepower and enough storage for everything to run smoothly.
I just posted a pre-Alpha API documentationhere.
We’ll work to have the documentation on a website, but until we have that feel free to add feedback in the above post.
Just to make it clear, we have NO plans to close the Ezlo platform!
@cw-kid is right, we just said is not yet ready. This early pre-Alpha API documentation aims exactly this, to show you the progress we’re making, even if it’s in its very early stages.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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
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)
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.
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.
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.
and losing some of our beloved plug-ins.
