I’ve been watching these lists come out, but am curious to know whether this is just a “certification” process (i.e. “We tested and hereby declare that device X works with Ezlo products”), or is it more like a “registration” process (i.e. “We include the necessary predefined classes/support files for adding device X”).
If the former, does that mean you guys having to buy/borrow one of every device just to try each one??
If the latter, I’d be curious to know why “integration” isn’t essentially automatic for all Z-Wave compliant devices ever produced. (I thought that was the express goal of Z-Wave’s original spec.)
It was also my point and previous recommendation… Maybe I am missing something. EZLO is either testing and validating that these devices work or “integrating” ie creating custom device profiles and configurations for them to work on the platform. It is is the latter, run… It’s not sustainable and scalable. If it is the former, it is a vaillant effort albeit very secondary if the zwave stack and API supports are built properly, ie not as a patchwork like the vera is.
I certainly will never have any interest in looking at a compatibility list to decide what devices to buy. I just want to look at the zwave logo and be done. Something which I can already do today with a controller which has no compatibility list…
A number of devices failed to work on the vera because of these weird customizations for other devices, shoved down the users throat. (I have in mind a 10s auto untrip of a door sensor which I could not turn off even by adding the non existing auto untrip variable and turning it off and a couple of hours spent with support ending with… “sorry, not a compatible device”. These devices all work now on other controllers without ever having been tested by them.
This all smells and feels like the old vera again…
Either way, it seems like an incredible amount of work (which, by its very definition, is usually not sustainable, hence my question why it’s even necessary). I was likewise unaware of any other controller companies undertaking this kind of “integration” process … except edge cases, of course, such as when ST users contribute configuration files to render a specific device compatible with their hub.
Edge cases and exceptions … fun and necessary!
Validating every device ever manufactured … a fool’s errand?
I agree with @slelieveld. This is not old hardware, you still sell Vera Edge, Plus And secure. And your new ezlo controllers are still miles away from all the functionalities of your so called old hardware. That’s by the way thanks to the fantastic plugins that several grear exrernal developers have made. I am very worried lately because your company seems to have stopped all updates on this “old” hardware. Please respect the current and still loyal customer base!!
My last vera support mail about that device:
"understand, the developers have that in their queue and they are working on it, the development ticket was created the past March 3rd, and they are checking on it.
After setting the child devices to be invisible from the configuration file, after a while, the engine cloned those devices without the variable “Invisible” and made them visible on the Dashboard.
You are right, I should have have said “Old firmware” vs “Old hardware”…my bad.
The support comes, in the main, from firmware. All the integration work etc are within the Firmware.
So the new Ezlo Firmware has more integration than the old vera firmware.
That is why I asked. The new ezlo firmware has more integrations and a whole team that continually integrates new devices as they become available in the market and fully supported by that team.
So if you are using the Ezlo Firmware on the Vera Hardware and you think there is a device that is not integrated or it says integrated but for whatever reasons is not working well for you, please tell us so that the team can fix it immediately. Here is the list of all the integrations we have done on Ezlo Firmware .