Hi all,
I have been a zwave device user for quite some time now but I still haven’t wrap my mind around the fact that some devices are natively supported, some will work just fine as generic and some does not work at all.The same holds true for hubs. Some performed better than other with respect to device support. Just to be clear, I am not talking about added functionalitites (even if they are inportant) like WIFI device support or plugin of any sort. I just want to address the Zwave functionalities.
I think that my confusion comes in part due to the fact that by definition/understanding, Zwave (compared to zigbee which is more open) is a standard that has been elaborated between different manufacturer to provide interoperability. In that framework, one would wonder why some device are only partially working or not working at all? To obtain Zwave certification, one would also think that testing against the certification would be required? As far as the hub manufacturer are concerned, their work should be focussed in implemeting all zwave_command_classes and updating approved existing ones required by new devices that were not part of the original specification. Why do the hub manufacturer required to support individual devices? Is the Zwave certification given too easily to manufacturer not properly implementing the specification? You would think that by now, a simple Zwave light switch would be somewhat standard! Is the Zwave authority loosing focus/control on its original mandate?
Competition is getting organised fast… with a much broader scope in sight. Zwave should be mature by now and all should be smooth sailing, but it is not! Where is the problem?
Any insight would be appreciated.
All very good fundamental questions.
The short answer is that the zwave standard command class are well defined but left room for interpretation for some of them to allow for openness and creativity. Generally speaking all devices with a zwave label should be compatible with all zwave controllers but it is indeed not the case:
- Some device manufacturers decided to jump on the customization to differentiate their devices (Like Aeotec) and for some even push a proprietary device to push their hub (I have Fibaro in mind) by using command classes differently than others when they could have avoided it.
- The controller software therefore has to create device specific libraries for these devices which lead to where we are today and some, like vera have become so infatuated with the device specific library in their design that they support the non recognized devices poorly.
For having explored other controllers, I can only recommend to avoid buying devices which are not “generic”. I have very rarely found a device which functionalities could not be supported by a cheaper more generic zwave equivalent. (I actually found aeotec to have such irreplaceable devices). Also go for a controller focused on supporting the zwave stack as opposed to the specific devices.
1 Like
Someone should make a comprehensive list of which devices behave which way under Vera. Or is there already such a Wiki out there?
Yes, Vera has such a list, but if they say it works… it very often doesn’t, despite. And even if you cant support and are vusy for a year and ~100 mals further…
https://support.getvera.com/hc/en-us/articles/360021951333-Works-with-Vera-Certified-Compatible-Devices
for example this device which should “work with Vera”…
https://community.getvera.com/t/aeotec-multisensor-6-6-in-1-works-with-vera-not/212135