will it include fixes so inovelli red and black switches work correctly?
or fixes so HomeSeer Leak Sensor HS-LS100+ are supported?
I completely forgot about this announcement because I was on vacation when it was first made, and that’s a good thing because my reaction at the time would have made my mother ashamed of me. I think I’m now ready with a more measured response (and trust me, this is the more measured response). Clearly, all herein is my opinion, worth every penny the reader has paid for it, but I’ll tell you at this point, I’m battle-weary, and tired of varnishing things.
This isn’t Beta in any real engineering sense of the word. Beta typically implies feature-completeness. Near-readiness to ship, in fact. If you’re still promising major new subsystems of the product to be added, you’re not even alpha, and your process is broken.
What is described by this announcement, taken in sum with the capabilities of its predecessor, will make my Vera Edge as functional as my Atom. My Atom is amazing to look at, but not much else. It’s a really cute little white brick, for my purposes, and as far as I can tell, it has no short-term prospects of being otherwise. So I don’t need new firmware to take my larger, currently-more-functional piece of hardware and turn into a big Atom… a larger brick.
While I can appreciate (but not confirm) that the architecture of this new firmware may be a substantial leap forward, functionally as compared to current firmware it is anything but. The existing user community knows this and has been saying this. Prospective users will figure it out quickly, and never return, particularly when cheap hardware gives them little incentive to just chuck it and cut their losses. You guys have pretty much one shot at getting a killer product on launch, and you’re still short. Your reputation and the long-term health of the product hangs in the balance. Beta? Again, no.
Tell me, right now, how on this new beta firmware I’m going to be able to do the following (without Alexa or Google Home):
- Randomly turn on and off selected lights in my home between sunset and 11pm when I’m away;
- Turn off the lights in a room if no motion has been sensed there for 30 minutes;
- If my garage door has been left open for 30 minutes but the kitchen door is locked, send me a notification every 15 minutes until the garage door is closed;
- Probe my home router to see if my Internet connection is up or down; if down, for more than one hour, power-cycle the router;
- If the lights are on in my kitchen, run my hot water recirculation pump for 5 minutes every 15 minutes, unless a leak has been detected under the kitchen sink or the water heater itself;
- If there is no activity in any part of the basement for two hours, turn off all the basement zones in the whole-house audio system.
These are all current automations in my own home, facilitated not just by Reactor but a number of plugins. They are not crazy complicated or conceptually outlandish, but nor are they now or ever have been in the past within the native configuration capabilities of any firmware, old or new, unassisted by plugins or (Lua) scripts. My Gawd, we were all celebrating a few months ago when Atom could turn on and off a single light on a fixed schedule reliably, and that took multiple cycles of firmware to get right.
This is a new capability? For “beta”? No. Not beta. In fact, IMO no firmware should have ever left engineering without this capability to begin with. It’s not a feature, it’s a requirement for entry into the space.
I’m a half-century old, and I have the eyes to prove it. Tell me how I’m going to configure and manage my 150+ devices on a screen larger than my phone?
I don’t mean in any way to belittle the effort of engineering here. I’m sure there’s a lot of work that’s gone into what you guys have done. I know there has. And I’m sure what engineering has done is artful. But I am becoming increasingly concerned whether the vision engineering is being asked to fulfill is right, or ever going to get right, at least in a meaningful timeframe. And the cycles between announcements/updates/releases are too long. Announcements like this that parade out “patent-pending” PrettyName™ marketing feature-itis to great fanfare, and yet offer no substantive progress on (or even visible evidence of) core issues and features that we, the installed base, have been vocally and repeatedly asking for (insisting upon, really)… but it’s in beta!!!.. this is just tone deaf. I don’t know how else to say it.
I need Tylenol.
21 Likes
Ohh come on Patrick, you forgot the return of local processing! (ducking down to dodge the bottle of tylenol I imagine you throwing at me).
This is indeed not beta. Merely a stepping stone the devs are sharing with us. But as I thought more about it, it is indeed impossible for me to test or validate to anything useful. The vera edge is much better put to use by disabling all the mios stuff in the firmware and turning it into a zwave radio over IP for another (open source or even homeseer) platform using ser2net.
What concerns me above all is, like many have expressed here, the complete lack of thought about migration which of course has for prerequisite everything you mentioned.
Start from the communication stack, then command queue, then local interface API, then logic layer, then automation layer with plugins, add to that a GUI… these are foundational. We instead have a cloud driven thing with mobile app. It is all backwards. For example the Mobile app could be easily built upon a very good GUI and be just a mobile webserver version of the GUI. Many problems with the current vera are in the foundations: The stack, the command queue… this is what needs to be improved. The current UI and mobile app can use some improvements but they are completely secondary and not breaking the system. The cloud implementation is not the most stable but can be bypassed. So… why all this work on recreating what doesn’t need fixing and not much if anything is being done on what is really needed?
My PM to edward with the verbose logs for an “old” but deal breaking problem on the vera has gone out without even a receipt acknowledgement. Go back and reread all the “going away” threads. If there is one common problem driving people away, that would be it. It is the luup reload/random delays/erratic behavior of the zwave stack on which I have spent months troubleshooting and decreasing.
You want to start fresh? Ok then deliver on the most basic pre-existing capabilities which are what I listed as foundational. Short of that, there isn’t much for us to do but to go look elsewhere… and I am on the fence already leaning the other side.
Oxycontin anyone?
10 Likes
Hello,
It seems obvious to me that you are going away from lua. If so what language will it be? Or will there be any?
We continue work with Lua. But API and approaches were reviewed. It’s completely new plugins engine. Atom and new Linux firmware use the same Z-Wave plugin now.
So, first beta will be only devices and scenes, no code? How are we suppose to test this in a real world scenario? (I’m ok with plug-ins not been ready, but no code makes automations practically impossible to achieve. No local api means no integrations to other platforms).
Yes. Lua and Local Access API will not be available in first release.
Transfer of key plugins to the new firmware is critical.
I agree with you. Now main target is finishing main functionality of controller. After that we are going to come back to exist popular plugins. But they cannot be used as is now.
As is a Http APi we can use to send commands to Vera from other devices on our Lan.
We have WebSocket local API. But It is private for now.
Hello, this is then very bad news for me, I will not be able to use this beta until I get a data model for device & actions and an API to programmatically control the unit. I would advocate that the API should be offered even before the UI. I would have imagined you would have a engineering life cycle that follows : first , design a data model, second an API and then the presentation layers ( mobile, desktop etc )
Publishing of API requires providing developing tools and infrastructure for external developers. We don’t have it. Sorry, but we are not ready for this now.
@rigpapa
Thank you for your feedback. Yes. We don’t have functionality as you described right now. It will be possible to do in own plugins but API is not ready yet for publishing. Atom and Linux firmware use the same plugins inside and functionality almost the same, but you can add more devices and scenes. Also it works faster in a few times.
@rafale77
I hope that you remain on our side. It’s hard to solve all exist issues in old firmware and save old API and plugins. It was difficult decision but if we want to have more stable firmware with flexible API for implementing own plugins on all UI platform that we have to re-implement it.
2 Likes
I appreciate your commitment for sure, but please understand that we’re advanced users and scripting and local access api are a mandatory requirements for us to begin testing this firmware. websockets is ok, but please offer http as well, this will make integrations easier.
I don’t mind writing my plugins from scratch, but the previous features are what I need in order to stay on your future platform. As you can see in this thread, I’m not alone.
2 Likes
Hi @rigpapa,
Thank you for your time and effort to give a detailed answer here. We captured all of your scene examples in this post. We are aiming with the new firmware for our scene capabilities to cover all of the scenes created by all of our users so far. So if you have any more automations it would be great if you can share them with us under this new post: Scenes capabilities for the new Ezlo Platform - General Discussions - Ezlo Community
Thanks a lot
Mehmet
Hi,
My thoughts. I am not sure I would be willing to write all my plugins from scratch. It has been a huge effort and several other platforms have similar plugins now. If I need to start from scratch I’d probably go for a proven (and documented) platform now rather that going through all the trial and error time wasters again on something new. Luckily there is openLuup I can still run them on. And I do realize that a JS based back-end can be much more powerful, but I like Lua.
I read you have a websocket interface. That is much better for chatty situations like a GUI (or openLuup Vera bridge), however not so simple to integrate with without a significant coding. The power of Vera is that I can do a simple local http request to get a variables value or initiate an action. I would strongly advice not to drop that capability. (and no, a cloud based VOI or so is not an alternative)
I know of an other platform (Homey) they dropped the web GUI and that did not go well with the user community. All complaining they had to do complex actions on too tiny screens. An alternative was quickly build, so opportunities for ALTUI 2.0 I guess.
Cheers Rene
4 Likes
Hi,
if you’re willing to send out test units for us to test with, I’ll sign up to test, but I’m based in the UK, so guess that rules me out.
Thanks
Tony
Hi
We don’t yet have the EU-version of the Ezlo controllers, however you can test the Linux firmware on a Vera Edge (EU version) without a problem. Do you have one?
Ioana
Hi,
unfortunately I don’t have a spare one 
Thank you for your response @andryist,
Trust that I would rather stay if I could but I am not seeing a good path to this happening:
- Because the vera was so buggy and limited I have built all my automation which is a tremendous amount, into openluup. It has essentially neutered the vera to the point of being a device controller for zwave and zigbee with an API. It is down to the most fundamental functionality of the hub. I am not the only one in this case.
- Even being just that it is not that good and crashes and burns on a regular basis. Basic things like handling a command queue, handling S0 security NONCE, leaks memory, and device inclusion for some specific devices is broken. (And yes they are officially supported) As a result I am having to use a secondary zwave controller on my network from another supplier to do certain things and this is the slippery slope… That secondary is much more stable and is a very good candidate to replace the vera, at least for zwave.
So it comes down to this. I want to help you test and I want to stay but for as many others have
told you here, we need the very basic functions of a hub to work and be accessible:
- Full Zwave stack support
- A local open API to which I can plug into in order to test automation (from Openluup)
- Complete and absolute independence from internet connection and mobile app for both functionality and setup. (That means need for a local GUI)
This is the bare minimum core functionality for any home control hub. The base of the base. The rock bottom requirements. These 3 are what make or break the platform.
It is bad enough if you are not going to support lua and plugin migration but if you cannot even support being a simple local device controller, the firmware can’t be tested or be useful for anything else.
The fact that you are building the firmware backwards gives me no confidence that this core will be anywhere close to be solid. I have seen too many other platforms try and fail doing what you are doing. Another analogy I can think of is spending all your energy and efforts designing a fashion dress to put it on a pig. Right now we only see the dress to interest us to a wedding and we don’t know what to do with it.
4 Likes
Nooooooo!
Rene’s Logitech Harmony plugin is one of the best plugins for me.
I know if I lose some Vera plugins that I am using now, I’d have to seriously consider another Z-Wave controller hub…
4 Likes
I know what Ezlo should do!
Get the names and addresses of the active 3rd party plugin developers and send them a thank you letter and a goody gift bag.
Its those guys who have helped to keep Vera going all these years !
They should also be given special priority support and direct access in to the Ezlo develop teams and have an “account manager” who looks after them.
And obviously access to all the resources they need for plugin development and creation.
Any company that looks after their talented 3rd party community developers, is sure to succeed.
9 Likes
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.
Flabbergasted. Or maybe gobsmacked.
2 Likes
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.
2 Likes
How is this constructive, @Steven_Share?
I deleted your other comment as well.
Please keep it civil, on topic and if possible constructive, per our community rules.
Thank you.
1 Like
We changed the state to “pre-Alpha” due to user requests.
I think we all knew it wasn’t really a “beta” version. Just loose usage of the word “beta”.
Either way it doesn’t really matter does it! As long as the end product is very good.
1 Like
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.
5 Likes
I think that had something to do with me LOL getting that ball rolling in the online media haha.
Have Ezlo actually said there will be no local API ? Or are they just saying they are not ready to let us play about with the new one yet?
1 Like