FR: Please separate Driver updates from HE updates

I know some driver versions require specific platform versions, however I think Hubitat should strongly consider building a separate driver update service.

The primary benefits of decoupling driver updates from HE updates are:

  • Driver bugs and or features aren’t delayed by large HE projects (eg matter)
  • New product drivers can be made available to owners as soon as they are ready
  • drivers that only work on certain HE platforms can still be restricted as needed
  • service could be scheduled to customer preferences to either auto update or simply notify of new versions
  • previous versions of drivers could be made available in the UI - This would need great for troubleshooting if any driver issues arise

Cheers Derek

@mike.maxwell @bravenel @bobbyD @bcopeland


This is something we've "strongly" considered more than once over the years. However, doing this would require a major redesign of the hub architecture and update mechanisms. We think the current release schedule for hub updates works well for most of our customers most of the time. Making this change would introduce a whole new level of complexity for updates and for the hub itself, risk and cost that is not really warranted for what has been about a 3 month release cycle. Bottom line, this won't be on our to-do list.


It’s the most of the time that’s the issue. Eg it’s taken me since December 22 and 2 topics to prove that the Zen Driver has an update bug in it:

Had I been able to roll back drivers, it would have been IMO easier to diagnose.

And Aeotec Shutters are still broken in home kit many months after being reported - in not sure if that is a driver issue specifically, but it’s still frustrating.

I get the architectural change argument, but in the long run it would enable Hubitat to be more responsive.

Community driver updates via HPM are a great example. When ppl report bugs in the Weather Underground driver that I maintain, I can fix them and make them available very quickly.

Sorry, but our failure to address some particular bug in a timely fashion is a totally different problem.

This is not feasible, nor will we be pursuing this.

These are not built-in to the hub, pre-compiled and an intimate part of the hub. There really is no comparison.

Sorry, but there are no arguments that will overcome the issues that prevent what you are asking for from happening. With that said, I'm closing this topic.