Not really, I would say it is more about the settings and possibly different revisions of the z-wave command classes.
My Zooz outlet/plugs driver is universal other than the device settings. You can (and people do) use it on any Z-wave plug that follows the current standards. It works for metering or regular plugs. It has pre-programmed settings for Zooz devices, unknown devices are presented with no settings.
Also just found out this week someone has been using my Dimmer driver for an Aeotec dimmer and it has been working good.
So really other than the device specific settings you could cover the majority of Z-Wave devices with generic drivers. Typically each driver I create is for a separate "class" of device that has different capabilities. At this point I have code that covers most of the messages that devices send in. Its just a matter of piecing the right chunks together to make a driver for the specific capabilities of the device.
When I wrote that, I was thinking about the several scene controllers that I've worked on drivers for. Their usage of "generic z-wave messages" has been... creative and individual.
I assume this is what HomeKit or Alexa are doing internally when they pair to a Matter device. They don't have ability to switch out a driver. (In some cases, you can choose the representation of the device in the UI. ex: switch vs plug vs light)
LOL, I assume all the competing parties will turn this protocol into spaghetti, just like previous ones.
This is where I think a dynamic driver could be useful. We can't do it as a user driver, because we can't dynamically define capabilities, commands, and attributes. (Though folks have asked before: Dynamic Capabilities, Commands, and Attributes for Drivers) So it would have to be internal to the hub.
I found a comment from @mike.maxwell that gives a potential architecture that a "Matter-Everything Driver" could use:
Though having a child device for every capability would get messy in the UI. I like the "purity" of auto-discovering Matter abilities and making them available. But usability triumphs over purity.
Not my favorite approach to turn lots of things into child devices...I really like having access to Swap Apps Device when I want to move things around when doing testing/troubleshooting, replace devices. Child devices aren't supported by Swap Apps.
I was having the same thought today. why can't HE create standard background library's that can be called in a custom driver?
something like @matter to tell it it's a matter driver. Then @switch and/or @dimmer or @motion and or @battery
then you just list these in the driver and that's it. You don't see the "code" if they want to protect that but standard drivers can be built easily. If there are issues then when they fix the library everyone gets the bump
I haven't uploaded the latest updates, but notice this file here: Hubitat-matterTools/matterTools.endpointAndChildDeviceTools.groovy at main · jvmahon/Hubitat-matterTools · GitHub. In that file, the function getComponentDriverByEndpointType looks at the Matter endpoint type ID and assigns child components based on the Matter type. So, for example, an Eve Motion device gets both a Motion child and an illumination child. I actually like the use of a different child device for each type - it makes it cleaner when you are controlling a given endpoint.
I expect a "publicly usable" version will follow Hubitat's next firmware release (there are some Hubitat Matter bugs to be worked out, so I'm waiting for the next Hubitat firmware release to do a final update / code fix). I am pretty happy with the progress so far and have it working so that the same driver works with switches, dimmers, RGB bulbs, multi-endpoint switches, Eve Motion, Eve Energy (including energy usage reporting), and a few others.
yes understandable but i was thinking of it more for your sake and time sake, surly this is a good all around better approach? ie rather than you having to reinvent the wheel each time you do a driver / going back and having to fix each one when there is a issue. Surly a standard set of functions that can be called would help you and everyone else out just as a bonus.
Did you succeed in getting a Tasmota Matter device added to Hubitat?
I just landed a couple of Athom ESP32-C3 plugs that have matter support. After commissioning it with Tuya Smart and putting it into sharing mode, Hubitat was unable to join it to it's fabric.
I can confirm that once the Matter device is commissioned, put into sharing mode and then joined as a Matter device to Hubitat, the old commissioning device is not longer necessary. You can remove it from the original commissioning fabric and the device will continue to function with Hubitat. Keep in mind that if you do leave the device only connected to the Hubitat fabric, you cannot then put the device back into sharing mode, at least as at 2.3.8.138, so if you ever want it to join another fabric, you will have to factory reset the device and go through full commissioning again.
