A very powerful feature in many object oriented languages is inheritance. This allows you to write a class that inherits functionality from a base class. You can then add additional functionality or override/augment existing functionality from that class with your own code often with little effort.
This is likely not a simple feature to code but I believe it would be a great asset to Hubitat if this type of feature was implemented with drivers themselves.
For example, if I have a z-wave device that did not have a dedicated driver built in to HE and the generic driver works the basic functions but does not support every feature of the z-wave device, my only choices are to live with the limited functionality or go to the trouble of writing my own by re-inventing all of the work done with the generic driver just to add a feature or two.
If Hubitat implemented driver inheritance, I could write a driver that inherited the generic z-wave driver. Then I only have to add the missing commands for the device and override the existing commands that won't do everything I need. If I needed to handle incoming data from the device, I would just have to override the parse routine to handle the data and call the base driver's parse routine passing the data my routine does not have to handle.
I can't be the first one to suggest this. I just want to plead a case for adding it as a feature.
Samsung didn't go to the trouble of trying to implement inheritance but they published the code for most of their supplied drivers that you could use as a template to add additional features on top of which basically achieved the same thing. It was a nice feature.
Our architecture is not geared towards support for this. I'd encourage you to let us know about devices you need drivers for. We need to know what devices people have need for...
It's good the Hubitat team wants to know what drivers are needed by the community. But in reality, the pace of driver delivery probably can never keep up with the wish list, for all sorts of reasons. Here's a case in point...
The supported device list is already extensive which is great. And new devices do get added gradually over time. And we have great user community contributions. Of course, users should really stick with supported devices. But this market is exploding with new devices and it's likely to only get more complicated. I do wonder how to manage this quandary into the future?
Well, except that @mike.maxwell was very open and direct that there is a long queue of devices awaiting drivers,...
... and therefore he would absolutely not look at supporting the Giderwel / Gledopto because he considered it fringe. Despite being one of very few controllers for Zigbee RGB+CCT strips.
I'm not challenging the decision; I simply returned it and bought an RGBGenie. But the RGBGenie cannot control the white distinct from the RGB. Apparently it's not a WhiteGenie. So a driver for the controller I'd first purchased would have been nice.
@btjohnston76. The issue with controlling the white channel separately has to do with the zigbee protocol. Z-Wave is able to do this. The color spacing in zigbee is not.
We did just receive yesterday a prototype for a 5 Channel zigbee controller that is white tunable. Additionally it is dip switch settable between 5 channels of single color, dual channels of white tunable, and rgbw. Stay tuned.