I am confused, I thought that the big advantage of Z-Wave was that everyone adheres to the standard, resulting in Z-Wave devices working out of the box.
Apparently this is not the case and separate drivers still have to be written. In this topic I read an interesting explanation of how a zwave controller should actually work, all the necessary information to operate a device correctly is on the firmware of the device, the controller takes over this information.
This appears not to be the case with Hubitat.
Does anyone have anything useful to add about why Hubitat doesn't use this concept?
Capabilities:
- You can tell which capabilities a device supports from the device itself.
- Hubitat Drivers can't easily add/remove capabilities to a driver 'on the fly'/dynamically, so a generic driver would have to add EVERY capability, and have tons of buttons/commands that the device doesn't actually support. Not very user friendly.
- Could Hubitat change their driver model/support to allow for dynamic capability add/remove? Yes. If they did could you make an uber driver that "works" with most all zwave deivces? Kind of... See below.
Configuration:
- You can poll configuration parameters from a device.
- You can't tell what the configuration parameters do on a device without additional information - thus separate drivers. E.g. parameter 4 on device A may be "invert buttons" and parameter 4 on Device B may be "dimmer speed", etc.
Device Differences:
- Some manufacturers even use different configuration parameters on the same device model, depending on the chip used. Zooz does this, for example. The ZSE11 500 and the ZSE11 800LR use some different configuration parameters... So you can't even always have a single driver for a single device "type".
7 Likes
I have found that to be true. If you buy a wall switch, from any vendor, it will join and work with automations that ask for On or Off functions. I don't expect every manufacturer of switches to include motion sensors inside their switches. Yes, there are a couple, but, using ZWave specifications, it's a multifunction device and it would support On/Off commands as well as sensor reports with each motion detected or expired.
Could there be one driver for a thousand different devices? Sure, but then every Device Info page would be identical and include commands that are non-functional because they don't apply to that specific device. That's what drivers do.. they identify a common set of features (Capabilities) that use those standard ZWave commands and optionally, some commands and attributes that match features the manufacturer has included.
5 Likes
As an aside, certain things need an updated firmware to work with newer chips. A good example of this is Schlage locks. They FE locks (300 series) will not work with 700 or 800 series chips without a firmware update. Schlage on the otherhand will not release firmware updates for their locks. On their BE locks, anything below 7.10 is a crap shoot. This is but one example.
1 Like
Actually you can with current command class specs. You can poll the device for a name and descriptions of every parameter
@BrunoVoeten I already answered your question in the thread you linked to: [RELEASE]Shelly Wave 1PM Driver - #8 by jtp10181 and here [RELEASE]Shelly Wave 1PM Driver - #10 by jtp10181
I could make a universal driver right now for any specific type of device. It would work on any newly developed device using the updated command classes. Problem is, no one would use it.
2 Likes
It was clear to me that there is a solution with a separate driver, I was just surprised that Zwave also required device drivers. I assumed with the new 700 and 800 series that everything was a standard and that we no longer had to depend on the goodwill of third parties to write a driver. But it actually turns out that it is just like ZigBee
You can take a look at:
to see how a single driver might be built and how that might make the user's life harder.
2 Likes
Well one of the core designs for HE is that all devices are controlled by a "driver" aka "Device Handler" from the ST days. So yes, any device needs a driver or there would be no way to control it.
HE could create updated, more advanced, universal drivers that utilize all the features of current command classes. They could be built in and automatically selected when you pair a device so that any modern device "just works" out of the box with all features and settings exposed. It would still be considered a driver.
2 Likes
So the conclusion is that for basic matters (on/off, wet/dry, open/closed, ...) it may work, if it becomes more complex or specific, (thermostats, power measurements, the use of healt status, ...) there must be a specific driver?
Depends on how specific you mean. There always needs to be a type specific driver because the capabilities in the driver definition cannot be changed dynamically. But for example I have already built a universal driver that should work for any z-wave smart plug, with or without power metering. It detects if the device has power metering or not and also can detect multiple endpoints. The only thing it does not do is read all the settings from the device (but it could, I have that code in a different proof of concept driver).
For updated z-wave devices, in theory, there could be a universal driver for each "type" of device.
1 Like
