Beta software is, by a definition going back nearly 60 years, feature complete. Those features may not work in all cases but they are believed to partially work.
Either the entire plan is to ditch a ton of functionality or this is so not a beta. This is so far away from end-user ready code that it’s almost malicious to be called a beta. I wouldn’t even call this an alpha for the stated feature set.
I am not even sure who has such a simplistic set up that they could attempt to use this as a functioning system. I know of no one who didn’t either install plugins to provide some core functionality or had written luup scripts to process logic. Most people had both, plus things like pleg/reactor/altui. Vera was too limited without extensions.
If you want to say that luup is so burdened with legacy code and you just have to put it out of its misery, ok, that sucks, but I dont know I would be surprised. But the replacement framework should be up and mostly working for a developer pre-release that comes before an end user beta.
I really can’t think of a way to express how incredulous I am in a non-insulting fashion.
Perhaps the team at EZLO is misunderstanding the definition of BETA. I did a search on the INTERNET and found this:
A pre-release of software that is given out to a large group of users to try under real conditions. Beta versions have gone through alpha testing inhouse and are generally fairly close in look, feel and function to the final product; however, design changes often occur as a result.
I am not too hung up on the beta or alpha name… I am more concerned about the content as I expressed in my 2 longer posts above. I actually appreciate the sharing of the progress.
The problem at this point as I said is that I don’t know what to do and what to test from your release.
The one fundamental area which is broken on the current vera firmware is the zwave network management and this would be the one thing I would want to test. But in order to do that, I need to be able to migrate or at least add a device with the new firmware to my network and command it with a local API. Some of the behaviors I am seeing from the current vera are so shockingly absurd that I am very afraid to commit any more time if your new platform relies on the same zwave management.
I can sense that there is resistance from your management to have a public local API and I know that it is a very strong business oriented temptation. It is your choice at the end but one which will set you on a very different course and I would like to encourage you to learn from what has already happen on the market. Look at the logitech Harmony hub. They tried to shut down their local API and ended up with a tide of public ranting. Look at Hubitat… they ended up adding a local API as well through a plugin. Even Amazon is opening their echo with an API. Only google/nest don’t do it and personally, it is the main reason why I banned their products from my home. Not allowing developers to interact with your platform and allowing to integrate into other platforms is IMHO, a huge mistake condemning you to overcome a handicap through other means to even exist on the market. It also goes completely against what melih has committed in terms of “offline mode”. Meaning localized only control. For me it is a deal breaker. I will absolutely not stick around if you decide to keep it private. I have been burned too many times now to trust any company with my home automation without my ability to control it without their participation.
Read between the lines and observe behavior. It’s pretty obvious that an API exists but that it has been kept private. How else would the firmware communicate with the cloud and with the mobile apps? So the fact that it was designed to be private to begin with, means… that’s the intent. Why would you want to spend the resources to develop two of them? It is pretty obvious to me that the default position is not to have a public API and to attempt to control everything from their cloud. This is why the cloud and mobile app infrastructure is being built first. Once it is solid and proven, users may not feel the need for other platforms to come and control it. It is a very apple like strategy (recommend to read Steve Job’s biography if you haven’t). It is a strategy and one I would have considered but would have decided against. I don’t think melih is insane. There is a strategy behind how the firmware is being developed. I don’t think this is random. It is a matter now for us, users, to decide what to do about it when it pans out.
Not our train set, though, is it? I suspect @rafale77’s analysis is correct, and I, for one, will be watching carefully.
If my stickiness to Ezlo / Vera is broken, then Ezlo becomes another player to consider, no more, no less.
I’m looking now to wonder why I should upgrade to 7.31. All my devices are supported. Everything works. Most of the time. None of the issues that I experience are fixed by upgrading (that I am aware of) There are no devices that I am aware of that I want to buy which are supported in 7.31 but not in 7.29 and finally, there seems to be at least one regression in it (not that I have power monitoring requirements)
Not having a local public APi is a crazy idea and would be suicide for Ezlo.
It would kill 3rd party app development and power users being able to do funky stuff.
Imperihome app for example has a remote and local access to Vera.
I have used the local API to add custom commands in to the Yatse remote app for Kodi, so I can control some Vera devices and scenes from that app.
What about the Java HA bridge software that uses the local Vera API.
What about the many other apps and programs that use the local API and all those various configurations users have setup themselves on their own Lan to control Vera.
No local Http APi then I’d be out I think and looking else where.
Agree. I can’t see a way I would be willing to move to the new linux distro due to the Plug-In issues. If the old plug-ins don’t work and have to be re-written, I am better off moving to an automation platform with plug-in continuity for their latest release.
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.
