As painful as the plugin support transfer is an opportunity to clean house (too many unsupported and obsolete plugins in the app store), it would be good to know if you are planning to support anything similar in capability. It seems obvious to me that you are going away from lua. If so what language will it be? Or will there be any?
On the other hand the API compatibility is absolutely critical to those of us who have developed their system for years and have very complex automation already setup. I donāt how many we are but speaking for myself, it will be a major hurdle to migration and if migration there will be, it will unlikely be to your ezloās new and unproven platform. Food for thoughtsā¦
I hope, for the sake of your developers and users, thereās a long beta test time for this, so that existing apps can be moved from the existing FW to the new. A lot of my setup relies on apps and moving without these in place, would be a no-go for me.
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).
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 )
Indeed and at the risk of sounding like a broken record, it looks like the firmware is built backwards: from top down for a pyramid or from the outside-in, starting from the cloud, the mobile appā¦ I am starting to actually believe that there is a reason beyond pure engineering here (putting on my business hat).
Sorry but I donāt see any reason to test such a limited setup. Really getting worried if Vera is still a good solution for me (and I think many many of the current Vera users)
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.
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?
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.
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.
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
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.
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?
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.
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.
