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.
1 Like
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.
4 Likes
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.
1 Like
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.
5 Likes
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.
1 Like
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",
1 Like
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 
5 Likes
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.
5 Likes
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.
1 Like
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..
1 Like
Thanks everyone for contributing to the conversation. Think it's time to close this chapter and for me to do some more homework before I put my foot in any further.
Specifically, cut code. HE has a lot of power and capability, and the only way to really learn its potential and limits is hands on (coding),
Hope to have more specific questions and constructive suggestions in the near future. Thanks again for your time and willingness to engage.
5 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
