I am having trouble validating the extraordinary claims. Hubitat lists 160 supported command classes and your documentation only shows 124 supported. But that’s not even an apt comparison as ~50 of the entries on the ezlo list are all part of command Class 0x31 multisensor, which is only 1 entry on Hubitat.
Now, I can’t prove if the Tide Sensor feature is working (nor do I really care) but I also can’t see how that list updated 18hrs ago shows a significant percentage of the Zwave command class list is covered.
Nor is it worth my effort to fact check further. Extraordinary claims require extraordinary proof. If you want us to believe you are the bestest, make a grid of all the classes and your controllers and the competition and show what you support that others don’t. You said you know this already so it can’t be much effort.
However I’m not even sure this is really the thing users care about. I mean, yeah, awesome marketing win, woohoo, you get an extra bullet on your feature list but to the point other have made, are these marketing points worth the developer effort? Is anyone going to use ehat you call Command Class 68 - Tide Level?
Or would users prefer the tamper status bug that’s existed in one form or a other since February be addressed?
I would prefer the latter but the former makes for a better tweet.
We only list the latest version of command class.
Hubitat is listing “all versions” as you can see from the screenshot "Association Grp Info " command class has been counted 3 times as V1,V2 and V3. We only put the latest version of the command class and not all previous versions.
At the end of the day, its the number of devices controller supports that matters…and we support 294 and Hubitat support 233 (according to their website).
Hubitat supports 101 Command Classes if you count the latest version of Command Classes only (no double counting by adding the previous versions)…
Ezlo supports 124 Command Classes (only counting latest versions of Command Classes)
Because our platform is new and we buy the products to test, if a product is discountined we can’t buy to test. That is why our promise is “to be compatible with every commercially available” device. Because we test these devices before we put them into our compatibility report and if we can’t buy them, because they are discontinued, we can’t put them as compatible. (although they may still work ).
we recently started covering Zigbee. Our aim is again, to cover every commercially available device. for Zigbee today we can’t make the statement about having the most coverage, like we can for Zwave. But we are working on that
for Cloud etc, thanks to VOI we cover around 30,000 devices!
So Zwave is good…Cloud is good…now on to Zigbee!
continuous improvement!
OpenZwave seems to follow the structure of the Z-Wave Application Command Class Specification (Document No.: SDS13781 Version: 15) where 0x31 is multisensor and all the sub sensors are defined elsewhere.
Well, since that doc is from Silicon Labs, owner of the Z-Wave technology IP, I don’t think you can have more command classes than they do without being out of spec.
SiLabs only lists the command class parent, not all the child commands. I.e. MultiLevelSensor (v5-11 is 0x31, section 4.68) is one command class, you break out the dozens of sub classes (tide sensor, seismograph, smoke density, etc).
OpenZwave follows the SiLabs document standard from what I can tell. Which means their 60 odd classes is close to, if not, the entire SI Labs command class set.
The question is, how close are you?
SILabs is the source of Z-Wave licensing. Pretty sure that makes them the gold standard against which all others should be measured. Its pretty foundational.
OpenZwave has 800+ devices supported and appears to have all command classes supported.
So you can say no one else supports more command classes when you get to 100%.
Saying you support more devices, probably isnt going to happen.
To be honest I can’t readily tell you how you stack up to HomeSeer as in many cases they certify entire zwave product lines. (E.g. all Yale locks, all aeotec sensors, all GE wall switches, etc) As a consumer it works out but doesn’t lend itself to ready comparison.
So not sure you will ever get that “most supported devices” tag.
Hi melih, what does “integrated device on Ezlo Platform” mean ? What can users/testers expect when they want to pair those devices on controller with Ezlo firmware ?
Those are the devices we purchased and tested all the way to the UI level…
for example: You might have a device and might work with the zwave controller, but the application might not show some of the UI elements of it.
Everything we are showing has been manually tested from zwave controller to App UI level.
Of course because our controller works with the “Interview process” unlike others who “hard code integrations” any device that complies with zwave standard will be able to be controlled by the zwave controller. But the UI might have some quirks with that and might report somethings differently etc. But thats because of the UI implementation and NOT zwave controller ability.
To summarize, there are 2 components to integration
1-Zwave controller aspect (Ezlo has the largest integration thanks to its command classes)
2-UI on the application aspect (Ezlo has the largest integration thanks to buying these devices and testing it manually)
And as you know, almost every week we add new ones!
I admire your positivism and enthusiasm.
There are indeed a lot of zwave devices on the integration list although I seriously doubt if Ezlo supports most zwave devices.
But there is a much more serious issue here: so far I have tested 6 zwave devices that are on your list. Only 2 of them work fine (33%), 2 work only partly (33%) and 2 don’t work at all so are completely useless (33%).
See my detailed test report in the topic “Beta Feedback Ezlo Plus” post nr 107
So please stop making these statements because they are false. And let your team solve all the bugs and improve the testing methods.
Thanks in advance
).