One thing that the ole dogs around here may or may not appreciate anymore is the Fear Factor that newer folk may (or may not and should) have with respect to Custom A & Ds.
That is to say...as long as there is an eager beaver on top of things as the platform evolves one may never incur significant risk in taking these on and continuing merrily along upgrading the platform.
But the other day, as I upgraded HE, I had this fleeting thought as I pushed the button...that I have not followed up on (waded through) the specific threads relevant to the CA&Ds I use....so I have no idea if the initial (or a subsequent) developer is keeping things current.... and if the upgrade I am about to do is going to crater said software.
It would be nice to go to a dashboard of all the published apps and see a GREEN, YELLOW, RED light as to if a particular CAorD is up to handling the upgrade or otherwise sees it as low risk to what is in place. Maybe this is inherent to/in HPM.
Just thinking out loud about how this can become LESS of a hobby
Pretty much every developer who releases anything creates a topic (thread) about it in the forum. I'd suggest "tracking" that topic (option under the bell icon/button at the bottom of the page) so new replies go to your "Unread" count in the forum, and then you'll easily see them:
As great as HPM is, it seems to make it easy for people to say that something is "from HPM" and forget where it actually comes from: a developer who hosted their code somewhere and likely posted something about it, almost certainly here, to let people know about it.
Not every post will be useful to you (I suppose having two different topics, one for releases/announcements and one for general discussion or help, might eliminate most of that concern, but I haven't seen that do anything and it might just make things more cluttered and difficult to find). But ... sometimes you'll hear people ask questions or report issues with recent updates, so it can be helpful. You'll also generally see discussions of new releases from the author (HPM lets you show release notes, but some just point back here--or many people don't read them regardless, I've found...). These can be good to know about too in case there are changes you care about.
So...not exactly what you're asking, but FWIW, it's what I do and think it works pretty well.
Thanks for the time invested in the thorough reply. All on the mark as to how to track/investigate this stuff. I was just picturing a more organized "quick look" dashboard.
I realize we run the full gambit of C A&Ds where this might not be warranted or maintainable but for mainstream Apps and Drivers it seemed simple enough to have a: Green light to represent a developer saying "I'm onboard the latest upgrade to the x.x.x level and I've made appropriate changes or believe none are necessary".
Whereas a Yellow would be, "Yet to be proven at x.x.x use at your own risk and let me know if anything looks squirrel-ly
and lastly, Red being...."If you upgrade to x.x.x this App or Driver will break as it is currently incompatible".
One thing I think about when beta testing an HE release is does it affect any of the custom apps/drivers I have installed, so I can give a heads up to the author.
I've been on Hubitat for a while now. (My oldest hub is a C4.) And I have a number of custom apps and drivers that I've published out. (Through the forum, and in HPM.)
Here's the good news: It has been a long time now since an HE update has broken one of my apps or drivers. In the early days, I had to pay a lot more attention. But I don't think an HE update has broken anything for me in at least a year now. Maybe more.
I'm sure my apps don't exercise the full extent of the HE apis, so YMMV, but this is my one data point.
As someone who develops and maintains what (I hope) many could consider important drivers in their setup, I am certainly someone who is (at times) "lax" in responding to issues raised for my custom drivers (it can vary....).
So while I have adopted the convenience of HPM, it took me a while and I still haven't adopted the beta option, which would have suited me in recent times.
I guess what I'm fumbling my way towards is to say that.... while there can be compelling and justifiable reasons for adopting a perfectly reasonable convention, we can't rely on all developers to adopt it, no matter how compelling the case.
So, in my opinion, the onus still needs to sit with the HE owner, taking the conservative approach where necessary to guard their HE setup from a problematic configuration.
I'll admit I don't have to contend with the wrath of significant others who may not take too kindly to an ill-informed update to their day-to-day life... So a problematic update does not hold the same gravitas....
That said... my point is essentially don't expect all those who toil away for the benefit of others to adopt the same consistent approach, regardless of the outcome you want to achieve. They may agree, but life may not always align to your expectations.... so ultimately you will not get a consistent outcome.... If you want that, you need to take matters into your own hands and manage the risk to suit your own circumstances....
To flip our reservations on their head.... you could also say that dev's adopting some form of transparency could drive users adoption of their drivers / apps, in the same way that those who have adopted HPM are likely to have achieved more uptake of their solutions than those who don't. i.e. if the case is compelling enough then users will vote with their.... clicks... (?)
TBH - I do need to read some of the earlier posts in more detail.....
And this is the tight rope that is walked every time somebody takes on a Custom App in this environment. It is unbelievable the amount of work/craftsmanship put into some of these! It is easy to become heavily reliant on them. And that is downright scary when you basically have multiple Custom Apps running "just fine for some time" and basically "check out" of following any ongoing discussion regarding them. And the adage: "then don't upgrade" is NOT a solution if you want to benefit from the evolution of this platform.
Tis the kind of reliance that always makes me think...."this is very popular, it serves a very helpful purpose not otherwise served by the platform, why can't these things be proof-of-concept for HE and integrated so we don't have to worry about them being left behind for any reason"
I think it basically comes down to making a compelling case for users to demand a feature in their apps/drivers and to make that easy enough for developers to deliver.
This does happen. For example with @ogiewon's pushover driver a few years ago and with @djgutheinz's Kasa integration more recently. Before @bcopeland worked for Hubitat he was a community developer. @bertabcd1234 created the new documentation website earlier this year.
But individual users, or small groups of users, can't dictate the terms of how and when the staff decide to bring a community dev or their work product into the hub firmware or the company.
Even a wide swath of users might not get their way if the staff simply decide they won't, or can't, take on a highly requested feature after weighing all the relevant pros and cons; relevant to them as a company that is, there are some factors we don't even know exist as users/customers.
All you need to do is not upgrade that specific hub, and simply buy another hub. This allows you to have the custom apps that are working stay working as you upgrade the newer hub to "benefit from the evolution of this platform".
I'm not sure this really is that big of a deal, is it? As others have alluded to, I'm not dialed in to every app/device out there, but have any of them really come to a grinding halt because of a hub update? If it does, there's the, rather easy in most circumstances of rolling back the code upgrade and letting the dev of the app/device know.
Coming from the ST world where there were some devs that locked their apps/drivers behind a paywall (and absolutely nothing wrong with that), I could see this being a reasonable ask. However, in this community, where I've never seen that, I couldn't fathom asking someone that's volunteering their time to also keep up with a "does this work with XX code version" table.
Even if it was community led:
It would inevitably go stale.
A single user could hardly extensively say that a custom app/driver is unaffected by a firmware update. Inherently, folks have different use cases for the same stuff that could result in one user being fine and another having a critical failure.
I suppose we could have a grid of "this didn't immediately melt down after a firmware update" but never a "this is certified to run on XX firmware."
Maybe app/drivers breaking was a constant thing early on (and I would certainly expect it to be for code that was a toddler compared to today) but I just don't believe this is a big deal.
Last point, if you are running a custom app/driver, you should always accept the risk that:
The code could be abandoned at any moment.
Just because it breaks and that's an emergency for you (the general you; no one in particular), doesn't constitute an emergency for the dev.
If my apps would've broken a few weeks ago, they would've stayed broken until this past week as working on them would not have been very high on my priority list.
It has been interesting reading the thoughts a musings on this topic. It is a worthy topic for discussion, but as many have remarked, difficult to get to work across the spectrum of developers who graciously contribute time, sweat, and tears to expand the functionality of HE for all.
This will is a discussion had in enterprise computing too. Open source software [the type of contributions we provide the HE community], free without guaranteed support, is tempting to enterprises trying to meet all the demands of the organization on a limited budget. The challenge open source comes when something doesn’t work. The organization can’t survive a failure of software that has no, or sporadic support. Hence most resort to fully supported software.
An interesting oddity in all of this is Linux. Linux is used by most major organizations. It is open source software. Red Hat and Oracle, and possibly others, provide support for a specific code base of Linux. Mind you, they do not and cannot seek the Linux code. They sell support.
The point of my ramblings is, every HE owner and potential owner needs to decide their tolerance for things that might have an occasional issue and not be able to get immediate support. If your tolerance for issues with unsupported software is low, only use the applications and drivers provided by the great Hubitat team. On the other hand, if you can handle the occasional issue, avail yourself of the fabulous contributions the community of developers have graciously shared with us. I have actually been amazed at how responsive the community developers have been.
Thank you to all who have given of your time, imagination, and brilliance to enhance our Hubitat experience.
