And this isn’t so cool. I guess and hope you guys are planning on having a proper http web GUI at some point for the new firmware.
I hate using mobile apps for setup and configuration, especially on a complex system like Vera. I would never want to setup a Vera system from scratch only being able to do it in a mobile app.
However for that must have device that Vera doesn’t support natively but GH / Alexa does it would be handy for sure, even though it would be cloud based control.
This has been the greatest hurdle to overcome, they are designing the FW backwards.
I (and many others) are in the same boat,xxxxxxxxx if I’m going to fiddle around with tiny buttons on tiny screens with aged eyesight.
Otherwise, I’d be testing.
This sounds very cool, but does it mean in case we need support, the customer care team will have no way of remotely accessing the units running this firmware? And is it possible to roll back to a previous version?
If you will create a guest user and share it with us we will be able to use this information and roll back your unit to the previous firmware version.
In regards to remotely accessing the unit after upgrading to the new Linux Firmware, this is not
available yet for the customer care team.
In this stage we are not ready yet to share the information about the API or the mechanism for the users to create plugins, as it was possible on the old platform.
Also for the moment there is no backwards compatibility with the current plugins. Once upgraded to the new Linux FW all plugins that were installed on the controller will be lost and any new ones from the Vera app store can’t be added/installed.
The devices will be described in a similar way. Let us know please if we can he helpful with any further details.
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)