I don't see it happening. If they can test a device and it works as expected then it goes into the official compatibility list. If a device is a standard z-wave device and outputs the standard clusters based on the category of that device, chances are that the generic driver will work with it and that generic driver will expose all available attributes. It is up to the vendor to supply 1st a device to hubitat with said available documented capability so they can test it and approve it then vendor has to work out what ever deal to be able to use the Hubitat symbol on their packaging. If a vendor reaches out for that aspect of marketing I'm sure @pete will gladly work with them. Until then we have to be satisfied with a combination of the official list, word of mouth from other users, and community driver. I will also say that @mike.maxwell and @bcopeland are great about accepting the loan of a device in order to create a driver for it. If they do that, it will be rolled into that category's generic driver or a separate driver and it will be added to the official compatibility list.
Why stop there? How about a 3-D matrix that includes every firmware release for every device? Or maybe 4-D, which includes every hardware version as well .....
Thanks; that seems to provide a first-order answer, but would like an official response from Hubitat team. This conversation continues to talk around the issue. Where is Hubitat in the conversation?
What constitutes the "official compatibility list"? Not seeing it. Does that mean Hubitat providders a driver, or what? Does that mean the driver [Hubuitat official or comunity provieeded] provides access-control or all capabbilities of the driver, or what? I have an existence proof that the anser to both is false.
Hubitat cannot have it both ways, They either release all driver source for all devices--and provide approrpriate documentation--or they do not,. If you do not, the the entire concept on which this ecosystem is built is BS.
Apologies if that is harsh, but it is what it is. You can't have it both ways Hubitat.
These are devices that work with Hubitat under the mesh conditions in their testing facilities. As individual mesh networks and homes vary considerably, YMMV.
Maybe start with something a bit simpler: currnet capability-firmware. That would be a great start.
It sounds like you have not looked at the docs:
To answer your next question, this means that Hubitat has either tested the device to work with built-in drivers (or written one specifically to work with the device) or at least heard a consensus from the community that it does.
Before that list existed, early adopters noted their findings here instead: Custom Device Drivers [Wiki]. This list has continued to be maintained (by the community) as a list including community-created drivers, but Hubitat, by definition, does not provide support for community code. However, it may still be useful if you're looking for a device you can't find any "official" word on. So could a search of this forum or a post of your own asking a specific question about a specific device.
I'm not sure how your conclusions follow from your proposal in the rest of your post (e.g., I understand you must want the drivers to be open-source, though they happen to not be; but this would still not answer every question you could have about any particular device unless you also know how its firmware works, possibly inner workings of the platform itself, and other details). If you can provide an example of what you're actually looking for, or perhaps another commercial hub that does what you're asking, it may help clarify.
Not trying to boil the ocean ("...answer every question..."), just want sufficient data in order to make informed buying decisions.
At the risk of sending this conversation down the rabbit hole of a particular device-driver, hope a concrete example might help illustrate the issue. To that end, the Minoston Mini Power Meter Plug (MP31ZP) ...
- Check official ZWave certification docs and capabilities--good for my use cases. Check!
- Shows supported by Hubitat. Check!
- Buy and install one of them. No issues. Check!
- Then... Looking at Hubitat device page, many of the device's advertised capabilities cannot be controlled-accessed from the Hubitat driver.
- Hmmm... Search the Hubitat forums for enlightenment... answers are effectively "if you want to control that you are on your own". E.g., "Advanced Send ZWave Command" or using the "Basic Z-Wave tool" driver.
- Yes, can do #5, but if advertised device capabilities (by manufacturer) are not available through the nominal Hubitat UI, does that constitute "supported by Hubitat"?
If had known #4 and #5 ahead of time it would likely have changed my buy decision. Nowhere does Hubitat provide the data needed to make an informed decision. Again, this is not a critique-evalation of any specific device or Hubitat driver.
Thus my post, and hope conversation. Think this is an issue that deserves attention, with a solution which should not be onerous. Or maybe me being too simplistic in framing the problem-solution, or having unrealistic expectations?
p.s. Having trolled through the ZWave certification docs for a large number of devices, appears feasible to ingest that information to auto-generate drivers (Hubitat, HA, maybe others). Might not be the prettiest from a UI perspective, but a driver-of-last-resort or maybe driver-of-first-resort/starting point. (One reason have gravitated to ZWave is that information seems fairly reliable and is readily available in an automation-friendly form. Zigbee more squishy. Another conversation.) At the moment working on py script to do so; might also be done with a Hubitat groovy app. If anyone has worked on such, would love to hear your thoughts-experience. Thanks.
Sorry, but think that is a canard. These devices have an interface contract (as specified by ZWave); they obey the rules of that contract or they do not. For purposes of this discussion, will only consider those which obey the rules (are ZWave certified),
As to the question of drivers being open source... Maybe reframe that as Hubitat should open source all drivers which are generic, for some definition of "generic". That is, those which support only a subset of device capabilities. That would allow the community to build on those basic capabilities (the Minoston generic driver being a case in point),
Again, not asking for an answer to every possible question, but as the Minoston driver indicates, there are fundamental issues with Hubitat's representation of "support".
And no, do not and should not have to know intimate firmware details,. That is a canard and distraction. All of these (ZWave) devices have a defined interface contract, documented by the manufacturer, certified by ZWave.
If you think that information is incorrect, would love to hear it. As would think the folks who perform ZWave certification,
The staff have stated unequivocally in other threads that since this isn’t an open source project, they don’t consider requests from users to release all their driver code.
That doesn’t sit well with some people, and I don’t mean to get into a philosophical debate about closed vs. open source code, I’m just pointing out that their position has been outlined and doesn’t appear to be subject to change.
Sending an Advanced Zwave command is available on every single device page. So how is it not part of what you term the “nominal Hubitat UI”?
Thanks for helping to set my expectations. As you might tell, new to this ecosystem. Will strike "access to Hubitat developed driver source code" from my list. That leaves "properly documenting Hubitat developed driver capabilities". Not going to get wrapped up the former (driver source, OSS, etc.), if the latter (proper documentation) is provided.
Really it appears that you joined this platform w/out doing sufficient investigation of what you were getting into. It's a common mistake (I've done so myself in the past) so not surprsing, really.
You clearly had very specific expectations in terms of device support, device/platform documentation, etc. You could have taken some time to ask the very specific questions here in this very responsive forum, or directly to HE staff who are here all the time, to search out if the detailed device support matrix you desire existed (and as far as I can tell you didn't find out if HE had a supported device list at all), and generally confirm if the platform capabilities, operating procedures and philosophies of management team (i.e., not open source) met your requirements.
And frankly, your request for a complete and up-to-date matrix of all devices HE supports, (which would have to cover both FW and HW device versions, potentially HE hub versions) covering all device functionality and support would require an insane amount of work to complete and maintain, and have little or no use/value for the vast majority of HE's users. I believe HE staff will not spend/waste their limited resources in a project like that. The ROI for the typical user/HE is just not there.
The nominal UI should provide access to parameters which are supported by the device. If the Hubitat-provided driver/UI does not provide access to those parameters, it is deficient. Using the Advanced ZWave command is an escape. I can do that with any number of tools and a CLI. Does that mean all can reasonably claim they "support" every device? That depends on your defintion of "support". At present Hubitat is playing fast and loose with that term, as appears are device vendors.
I've been on HE for couple/few years now, and my (unverified!) conclusion is that HE's official / baked-in driver support just tries to cover the main / most-used parameters of a device. Selecting which parameters to support is admittedly subjective, but I think HE tries to balance not surfacing too many options (overwhelming for newbs) with providing a reasonable amount of that device's capability.
Look at the manufacturer's own parameter options for just about any ZW device -- more often than not, there are a LOT of parameters -- some obviously useful (hopefully ones HE adds), but a lot that are frankly not useful to the vast majority of users. I think HE shoots for covering the main basics, but they also rely on community developers to provide other options that surface more parameters & capabilities for users who want that additional oomph.
And I think that's a pretty reasonable approach... It keeps HE staff out of the weeds day-in-and-day-out, and it empowers the community to forge new options. Sometimes those community-developed options even become integrated by the staff as "official".
When researching a new need and I have a few devices in mind, my first stop is always the community forum here to do research -- if I can't find the answer I need by searching, I create a new post to ask about it. I haven't been steered wrong yet.
Yup. But to clarify, I did not have very specific expectations, Also did a significat amount of due dilligence on various solutions.
But there is no substitute for hands-on, as I think anyone who has been in this business will agree. (Have been doing embedded since dirt: i4004, i808x, Z8x, M650x, i960, M30xx, iAPX3xx, NS32xx, ... Name any micro-processor/controller poduced in the alast 50 years and I've probably touched it, or can give you good reasons why you don't want to touch it.)
Based on my hands-on evaluation, my post was intended to try and help identify what I think is a significant Hubitat weakness that, if remedied, might help set it above other solutions.
Would caution that this apparent attitude of "not our problem, blame the user" is a dangerous and slippery slope. Moreso "The ROI for the typical user/HE is just not there." Maybe need to start with that, because that may be the root of the problem,
But I digress,.. a little documentation (not necessarilly "...a complete and up-to-date matrix of all devices HE supports...") would go a long way. IMO that would be a significant value add and a reason for buying into the Hubitat ecosystem.
Hmmm,,, that suggests possible options... Standard, Advanced, and Really Advanced, Problem at the moment is that those "Advanced" options are not available through the UI--unless you go to the Advanced send ZWave command. Which comes with a bunch of caveats, cautions, and hand-crafting of the message to device.
Think what you suggest would be a good comproise middle ground, Something between "OMG you have to be a wizard and you risk breaking everything" and "I just want to set parameter X to value Y cuz the UI does not expose it in a friendly manner",
Another view I think you may be missing is the goal of being a Home Automation system. Many people start with Remote Control... in which their mobile device becomes a substitute for getting up and walking to the wall switch. For a small number of people, remote control is where they stop, especially after getting Alexa, Siri or Google home to do most of the phone clicks. It seems that a lot of your questions assumes you'll be spending HOURS messing within the device info pages. WHY? Why take one of the best Home Automation systems and use the smallest sliver of what it does?
The entire point of drivers is abstraction, to take as many of the common features of a device type and abstract it into a common command or attribute. Switches have switch stuff, Door Sensors don't.
I think you should use this system for a few months to understand what is on offer. Swing back to this topic then and pick it up again 
The problem is that these too are entirely subjective categories -- my idea of Advanced vs Really Advanced is likely different than yours (probably more so when considering any one specific device), and almost certainly different from a user very new to home automation.
I'm not convinced this type of approach solves anything -- it just adds yet another layer to the cake.
I'm good with the current system -- I don't see a need for additional compromise. If the stock HE driver doesn't cut it for me, I look for community versions -- in most cases, those accomplish what I seek.
In cases where they don't, I bust out the Basic ZW Tool for ZW stuff and do it myself, or if it's zigbee, I guess I'd post to the community and see if a dev (HE staff or community) is willing to take it on. I haven't done that myself yet, but there's a good track record of success with that here overall in Hubitat land.
The fact of the matter is that true home automation is not simple or easy for "the masses" at this point -- it's a hobby and labor of love for most of us here -- we enjoy (for the most part!) the thrill of the hunt and the tinkering & tweaking.
What you seek is a nice and lovely ideal, but I think it's prone to the very same issues of inclusion-related subjectivity that we have now.
Not sure what you mean by this. The driver capabilities are determined by the device and it's firmware regardless of it being z-wave and zigbee.
Umm again... Not sure what you mean. The driver exposes what's available on the device in the forms of attributes. RM for example when you're building a rule allows access to those attributes. Here is a good example of allowed attributes...
Honeywell T6 Pro Z-wave
RM accessing those attributes
and then the allowed values from that attribute
Nowhere publicly or in documentation have they ever said they support every device. There is no conceivable way they could. They do say however they support everything in the official compatibility list which I assume you have read and they even include a few caveats on certain devices.
See comment above..
