Pros/cons. I agree with what you said but conversely it’s nice know they will support/maintain it if it ever breaks or needs changes. As a developer myself, sometimes you get bored with a project then the community has to hope someone else picks it up!
4 Likes
Yup, pros and cons... I prefer to have my destiny in my own hands as much as is practical.
Many devices have unique features and settings, or settings that are useful as commands instead of just preference/settings, and if they don't fit the standard driver mold in Hubitat then they are often just left out of the in-box drivers.
That drives functionality to the lowest common denominator, instead of the maximum capable for the device. I don't prefer that, in general. Yeah, great for consistency, but sucks for you if you wanted/needed the left out parameter/setting/command/feature.
At least if it is on github (and assuming no prohibitively restrictive licensing model) someone CAN pick it up and improve/extend it. I think the contributions of many exceed the capability of one.
I understand the rationale behind that sentiment. And I use some community-derived drivers. However, from a support perspective, it is probably in Hubitat's best interest to provide a common set of drivers that cover a large plethora of devices (like they currently do).
4 Likes
Probably. It should get you devices supported with a minimum feature set the fastest.
1 Like
Very valid point. This has led to frustration for me on more than one device.
I have very few complaints about Hubitat - really. But the limited functionality of the in-box drivers is one of them. Luckily user drivers can fix that.
LOL right, like the built in driver feature support on all the other platforms is sooo much better.... 
3 Likes
True. Can't argue that.
As long as user drivers are possible, I am OK. I literally couldn't use the system the way I want to without user drivers for pretty much all of my light switches, dimmers, and thermostats as the built-in drivers are each missing at least one feature I use.
Which, again, is fine since user drivers are a thing.
My whole point in my comment was simply that when a new driver is made, I prefer it to be a user driver so I can extend the code if needed. That isn't an option available to me on the in-box drivers, so they are less interesting to me for anything other than very basic devices.
But at the same time on ST I felt like I HAD to use the otb drivers because it was the only way to get local control. With HE I can have the best of both worlds using a custom driver.
3 Likes
A good user driver is a great thing for those that have the need, no arguments from me in that regard!
1 Like
@JasonJoel
Since I know that you've written Zwave Drivers, is it your understanding that ZWave drivers are more complicated, more difficult to write than Zigbee?
Or, does it always depend on the "bells and whistles" that the individual device has?
Nope, depends on the device capabilities - and if it is a more complex driver like a parent/child one, or multiplexed device.
I am much less experienced at zigbee, but now that I've written a half dozen of them, I wouldn't say they are "harder" than zwave.
I would say that it seems more common for zigbee device manufacturers to use custom clusters than it is for zwave devices though. That can make it take a little longer having to sniff out the traffic/decode the cluster data.
I'm definitely with you on this one. I've had the experience with several devices, where a particular preference/feature wasn't exposed by any in-box driver, so I was forced to either switch back and forth between the Basic Z-Wave Tool (if I just needed to set a Z-Wave parameter), or wait for somebody to come out with a better driver. The thing is, I actually have some basic coding ability, and in some of those cases, I'm sure I could have achieved the functionality I needed if I just had access to the code for tweaking. But to write a driver from scratch, without one to build upon, is currently not something I want to try.
Agreed. But that isn't ever going to happen - Hubitat has been very clear and consistent about that. So us users have to stick together.
True, but therein could be the difference maker. I believe all drivers should have all options and parameters from the initial release so it is only maintenance and enhancements from there on. Want to show simple looking drivers? Make an Advanced View or Tab that shows optional settings for Advanced Users only unlocked via a config in settings. Put an asterisk next to settings that may have hardware or firmware issues since that isn’t necessarily your issue, but don’t choose to skip adding parameters, options or features for the user. Another example with Alexa integration... if the API offers it, I would expect it supported here, yet it lags behind. You are right Mike, other platforms suffer from this too...but this Is THE platform that has an amazing team and community behind it that I am inspired by and has my attention right now. Keep doing amazing things and moving forward.
-Travis
2 Likes
yeah, that's the solution, it's been discussed internally...
We'll get to it at some point.
11 Likes
I would but most of my stuff i need. Sure the other half doesn't want me sending my Hive heating away for a driver
You need heat right now? 
1 Like
Frankly I would appreciate if staff member would come out with their real names and (creative) photos 
We always need heat on the UK 
1 Like
