you are wrong again
You can find this in Terms and Conditions on getvera.com website.
I could not agree more strenuously with everything @rigpapa laid out above in his assessment of where things stand. Spot on!
As to the points made in his numbered list, I might share some of my immediate thoughts:
-
“Find all the devices…” harkens back to how Microsoft Windows laboriously catalogs hardware signatures so that specific drivers can be (down)loaded to comport with what’s installed, even with respect to firmware revisions. In the long run, if it ran on old Windows, it stands a very good chance of running on the new.
-
“Examine the Vera firmware…” takes my analogy in (1) even farther, and if ezlo were to leverage some AI or catalog lookups here, their hubs could present a “Wizard” in the UI by which users indicate “Is that a Vistacam 700?” > “Yes” > “Which hardware revision?” > “2.01” > “Installing device”, etc.
-
“Collect data…” reminds me of how Logitech paid extreme attention to users of their programmable (“learning”) IR remotes, to the point where if a single customer managed - often with the express assistance of Logitech support - to make things work with Appliance X, then all of Logitech’s customers would gain drag-and-drop access to that same device. Instantly!
-
It appears, looking back, that lots of promises were made in haste as to the company’s timelines on testing, release, integration, communication, mileposts, feature sets, etc. which for various reasons have not come (yet) to fruition. I don’t really think many of us who’ve been around since the 2009-2012 founding era of Vera/MCV - especially the die-hard devs - thought our loyalty would pay dividends after the acquisition. (A dozen or more were shown the door last year, remember?) And I dare say only a mere handful remain who care enough in 2021 to continue the wait for all these disparate product roadmaps to evolve into a fully fledged platform.
So I second the sage advice by @rigpapa to explore ways of ramping up the pace of integrations (never mind all the other equally important stuff) in order to wow ezlo’s intended HA audience, to kickstart that new customer base.
Thank you for all your ideas and good intentions, really appreciate it.
Let me start with some facts:
https://ezlo.com/device-compatibility/
Ezlo has more than double the amount of devices integrated with it than Vera ever had!
Some of the issue is not that we can’t integrate, we can , we have and the numbers speak for themselves.
Unfortunately integration process is heavily reliant on manual process. Unlike Vera, Ezlo has full Interview process implemented, so in theory as long as the device being included complies with Zwave standard any generic inclusion should work. Vera did NOT have the “interview process” implemented and everything was hard coded effectively.
There are many nuances to device integration that touches everything from Firmware to UI and anything in between. Sometimes device manufacturers are creative and grey lines are implemented which throws off zwave protocol and “things don’t work” … a lot of timing conditions…
I honestly wish it was as simple as, us logging what people are using and sending us the logs when they have a problem with “inclusion”. Its not!
As a result the only way we can guarantee integration is by having physical access to the device and our “Device Integration Team” putting that device thru its paces and make sure not only it can pair, but it can also function (as per manufacturer’s intentions), reports status as well as all the UI is represented properly.
As a result this process we have, will only have an issue for discontinued devices where we can’t get hold of them. This is why we only guarantee if the device is commercially available.
HOWEVER:
Because we are nice people 
Anyone who comes to us and prepared to either give us their “discontinued device” (we’ll return it after we integrated it) or allow us to work with them “remotely” until we fully integrate, we will never leave an automation enthusiast behind!
So to summarize:
-We already have many more devices integrated in Ezlo than old Vera
-We have Interview Process in Ezlo and Vera did not.
-We have a 90 day Integration guarantee for any commercially available Device
-We will do our best to integrate any “discontinued device” as long as the user will either send them to us or give us access remotely.
Fair?
3 Likes
That’s not strictly true.
Patrick has worked with me and other Ezlo users to add support in Reactor for Ezlo hubs and devices paired to those hubs.
So I can have a Reactor rule aka scene that includes devices from my old Vera hub and new Ezlo hub.
1 Like
Good to hear! 
3 Likes
I had such luck, My Vera died suddenly and I thought Ezlo would be my knight in shining armor (disappointment). But I am still hopeful they get their act together a little faster and get it to the point of usability. Still too many devices not recognized and seems like released a bit too early but I stay confident that it will get together and a superior product evolves.
2 Likes
Unfortunately I have not been able to find any information beyond press releases that provide any insight into eZLO’s organization structure. The original release (MiOS Vera Market | eZLO Announces to Accelerate Time - Vera by Ezlo) along with information gleaned from your websites indicates eZLO acquired the company MIOS and by extension the Vera brand. I therefore assumed that “Vera” no longer exists as a company, only as a brand, which seems to be confirmed at the bottom of the “getvera” home page. Perhaps as the “principal” of eZLO Innovations you would be willing to enlighten me on eZLO’s acquisition of MIOS assets and the resulting company structure so I do not make similar mistakes in the future.
2 Likes
I bought a spare “Plus” just for this eventuality. (I had an almost bad experience with the Memento Smart Frame, digital picture frame. The company discontinued a great product, a product that was and is dependent upon the company’s server infrastructure. Fortunately for customers like me, the company is apparently continuing to support the required infrastructure despite discontinuing the frame and customer support years ago.) You might want to keep any eye on eBay as Edge and Plus controllers pop up there periodically. Also some folks list their units on this board after they change to a different brand.
1 Like
can you pls provide us a full list of devices that are not recognized? (In the other post you only provided one device) 11 days ago and our guys are on it (they have ordered it etc)
btw: did you try “generic inclusion” ? If Generic inclusion a Zwave standard is not working then that means manufacturer has some extra stuff in that requires manual process to integrate.
We will integrate any device, and enable you to do any automation and we will let you create any visualization you want!
“No Home Automation Enthusiast Left Behind” (Copyright )
Ever since new firmware update, devices that had worked no longer do and can’t get included. Enbrighten 55256 Z-Wave Plus Smart Receptacle / Enerwave ZW15R Z-Wave Wireless Duplex Receptacle / GE Lighting Control On/Off Switch / Schlage FE599NX / JAS12724 - GE 12724 Z-Wave(R) in-Wall CFL-LED Dimmer Switch.
I tried pairing as standard Z-wave devices and start pairing but stop at 5% than when I eventually get paired using another device, I can’t control properly. I understand you are adding more and more devices and it can be a “painful” process but after having the Vera fully functional, it’s a little disappointing. Plus it seems some of the standard functionality of the Vera device is not here. Something as simple as checking version and updates seems to be a process, or maybe I’m just not that familiar with it yet. But, I’m confident you guys will get it done
1 Like
Chipping in, albeit late in the game.
As a 10+ year Micasaverde/Vera user, my current Vera set up/configuration has been a decade long labour of love, which involved a lot of help from the Community forum. (It also inadvertently led to me learning a programming language in the process !!).
Before even contemplating a move to a Ezlo device, I would first need to see a clear migration plan, focussed more on what I would lose in the move, rather than gain. My Lua Startup for example has grown to become a long list of ‘require’ statements, and I’ve got multiple custom .xml and .json files too
It’s weird to think back to the complaints I made over the years about my VeraPlus, but truth be told I would be lost if(when) it eventually dies.
For those of us who are old-time Vera users - any chance the Vera product/firmware could be spun off as the ‘ezlo community device & firmware ? 
1 Like
Tell me more about what this does pls.
(I am very open to be educated about all your needs to help shape our development process, ask @cw-kid his education of us already helped shape our development and delivered few important capabilities in our dashboard thanks to his input)
Hi @melih
The ` startup Lua’ is at least in my mind , where the real customisation and personalisation occurs, although I’m far from an expert in it …
I’ve written a number of bespoke Lua scripts that are loaded at start up which I can call in scenes etc.
require "xxprowlnotification"
require "xxlogdanalockchanges"
require "xxcifsmountpi"
require "xxpollyfunction"
require "xxlogrestarts"
require "xxveracabinfunctions"
require "xxenergymonitor"
etc.
I also register a number of handlers, LuaTest is just one and it’s amazing a must have !
local rblt = require("RBLuaTest")
rbLuaTest = rblt.rbLuaTest
luup.register_handler("rbLuaTest","LuaTest")
And watch some specific variables too.
parkerc_WatchHandler1 = lockmodule.danalock_locking_logging("DanalockV3.txt")
luup.variable_watch( 'parkerc_WatchHandler1',"urn:micasaverde-com:serviceId:DoorLock1", "Status", 61 )
For me these have been invaluable customisations. I expect there are other ways to do it, but embracing Lua and luup made Vera come alive so much more…
1 Like
I think I understand.
we have seperated the world into two different segments:
Triggers and Actions
Triggers: are about “Data Source”, “states” that we can act upon…
Actions: are about “commands” , “doing something”…
we have included an ability to be able to write a “Script” (in Lua) (other languages like JS etc coming as well) inside your scene.
So now you can create a Lua code and put it in “Actions” as part of your scene.
Would that resolve your need about “Lua Startup”? If not, how can we improve? (much appreciate your insight!)
Note: the more the native system provides in terms of capability, the less code you have to write. Although we are providing full coding capability, we also want you to write less code to automate.
A key element is the “start up” piece, the ability to load global functions / modules at the very etc. that I can then call later , either within a scene or maybe run in the test Lua code window ?
For example, I’m notified of every luup restart, with this in the start up.
xxprowlnotification.my_prowl ("VeraPlus", "Luup Reload Notification", "Your VeraPlus controller has reloaded luup")
xxprowlnotification is loaded and then my_prowl is a global function that is available for me to use at the very start, and at any point later…
so you want to be alerted if the “FW” restarts? (you want to be able to create “Triggers” for “System” related “states” like a “restart” would be…) (am I understanding it correctly?)
Being notified of key system events is certainly of interest, but the main thing about the Start Up Lua for me. is the ability to really tailor the experience - e.g. set up luup.register_handlers, load Lua modules, global functions etc…
With the new ezlo devices, what is the deal about uploading files, whether that’s custom Lua, or my own variation of device, implementation and json file ? Is all that possible ? For example today, I have some z-wave plugs that I didn’t want anyone to be able to turn off via the Vera UI, so I created a new version of its existing json file and just removed the ‘control’ tab, now the device just shows the power usage (which is what I want), and I removed the risk of someone turning it off accidentally.
I appreciate these are nuanced requirements , I’m just sharing them as my use case.
Another use case for the start up, is that I have created a number of ‘HTML Reports’ - which are accessible via a luup.register_handler request. To give you a couple of examples I have my DSC alarm integrated with Vera and I’ve created a ‘last tripped’ report, that is a html table that shows a list of all my motion sensor and when they last tripped, (sort by the last trip date, so I can see what movement is going on in the house). Another report is my house energy, where I take the energy readings (watts) of all compatible devices, and also calculate the watts other on the fly (e.g Sonos_, and then I present a list of all my energy usage, comparing the total of all devices against my Current Cost plugin in Vera, which is showing the whole house energy
1 Like
So there are “Granular Control” that you need the native platform doesn’t provide, therefore you need access to add these “Granular Controls” yourself…
I believe, we should give our users full granular control, therefore would love to see all the requests so that we can push it in to our development.
On the other hand, it might not be practical (although we should still try) and therefore allow users to to add these controls by writing their own code.
We have re-architected a whole new way of adding “Plug -ins” we hope to launch this year (fingers crossed), whereby you can write your Lua code…and upload it either to your private space or public marketplace. I am hoping this Plugin capability should give you good control. If there is some capability that is not provided by this plugin, you just let us know, we’ll put it thru our dev and provide the functionality.
to Summarize:
1)Please tell us all the use cases (no matter how edge case they may be) so that we can put these as development items into our development roadmap (this is important because there will be others who might need these granular controls but not be able to write code)
2)Would love to hear your feedback if the plugin framework we’ll be launching is sufficient or not for your needs so that we can further develop it if need be. (we will announce it here in the forums).
Yes, I feel it’s safe to say, that a closed system will lose you the a lot of the key people who will help you innovate the platform - Vera in my mind was only ever the success it was because of the community that invested time/effort to make it better.
I appreciate some people will like a closed/proprietary system/set up, which is fine, but real innovation, real progress will be citizen developers and a vibrant (non judgemental) community
I knew nothing about Lua when I started out, but it soon became clear that Vera couldn’t do certain things (admittedly I’m going back to life with a Vera 2, 3 here) - the community was the sole reason why I choose and have stuck with the product, and have been a loyal customer for so many years.
But, I’m at a crossroad now, as things have moved on and there are so many more HA products/services on the market now to choose from - and for me ezlo lives/dies by it’s granular controls (customisation/personalisation) and its community. (If I had relieved solely on official tech support, no matter how good and necessary it was at time, so much of what I needed was provided by my virtual friends here, they helped me through it all) - and I’m doing what I can now to pay that support forward (albeit with the limited skills I have)
What started out as a single Vera system 10+ years ago, is now a mesh of interconnected tools (docker containers) but Vera has always remained at the centre… For how long, that’s up to you/ezlo to decide 
For me its not a question of an Open or Closed system. It should always be an open system imo…but the question is: How much of the granular control should be natively provided, and what kind of framework should we provide so that Open system can be expanded with ease.