So here's my thoughts. If Custom code is such a cornerstone of Hubitat's success and it's encouraged, I believe if Hubitat is going to benefit from that functionality, there should be some responsibility on their end to help moderate it. If the developers don't want to help Hubitat with some kind of certification program, then they shouldn't be allowed to publish code in Hubitat's forum community. Post it on your own site. This would cut down on Hubitat's support calls for custom code going bad.
Having "Releases" published in the community on Hubitat forum gives it a sense of legitimacy that it's "ok" to run on your hub. I just don't see how you can have it both ways, advertise you can run custom code and benefit from the developers and the community "buzz" for being able to do so, but then also washing your hands of any responsibility of the problems the code could present.
I run very little custom code, so this doesn't affect me very much. I'm trying to advocate for a better system than, "here you can do this, but your on your own" but yet you can take advantage of the "buzz" around the platform.
There should be a better way. I like having the ability of using custom code, but there should be something in place to govern it if there isn't going to be any development for hub metrics or health monitoring.
I would like to see actual metrics of things like total users/customized app users/users reporting problems before using labels like "cornerstone" and "people" that tend to infer things. To continue to infer things based on a lack of meaningful data does nothing to further this discussion. It would be great too if someone could provide the same requested data from SmartThings and any of the other players out there. That would certainly build a better case.
So far it's been a few people ask for access that has been deemed unnecessary. Unless a real case with proper data can be built, it's more-or-less an exercise of back and forth between requesters and HE principals that continues to play out in existing and new threads with no change.
As far as a programing environment, it's a great thing to have, but there's no obligation to it. There has never been a marketing point about writing custom code, nor is there anything in the documentation that says they allow and support it.
My personal view is that it is great that they allow it. It gives users like myself access to devices and products that HE doesn't directly support (e.g Echo Speaks, Ream Water heater, etc). When I load this, I know it's custom and has the potential to break at any time, since it's NOT supported by HE. I watch the logs and if there is a problem I contact the developer.
My hub has crashed twice. The first time was due to a Z-Wave device that buried my hub during a bad join process. This caused my job queue to fill up and the lights in my house were blinking so quickly and randomly that even the cat looked at me with a WTF expression. The second time was due to a corrupt database which seemed to be exacerbated by a custom app that I pushed a little to hard. Support helped me in both cases with the HE stuff and I reported the overuse to the developer.
It seems very remedial. If you use the product as advertised, you are supported and have little chance of issues. If you load custom stuff on it, YMMV (just like thousands of other products out there).
We all want this product to be better and HE grows by leaps and bounds constantly.
I don’t believe it is. @bravenel has mentioned a few times that users of custom code are few compared to the many who don’t.
“People don’t buy Hubitat for Cobra’s apps!”
I spoke with Bruce about this some time ago.
At the time, I said I would love to be involved but I have not had time to persue this.
As for being prohibited from publishing code in the forum..
There are currently 1182 copies of my various apps & drivers being used every week
I wonder what my userbase would say if you took these away from them?.
Perhaps you would like to tell the authors of this custom code (assuming you did not write it yourself) that they should not be releasing their creations (before you remove it)
I have already said in this thread, that when one of my drivers caused a user a problem, I immediately addressed it.
Had I not, the user would have easily removed it.
I am not unique in providing swift & effective support for the code I release.
Most, if not all developers here do exactly the same.
I would not, however; expect Hubitat staff to spend time either reviewing my code or supporting it.
Nor do I, and yet they often do provide support for me when i'm developing something for their platform. I've had their help a number of times. And thanks for that.
I'd love to see those numbers, including drivers. I'm betting its easily 25% their base, probably more, I'd be surprised to find otherwise. In truth, are they actually measuring it, or is it a guesstimate?
I'm pretty sure that everyone here understands that custom code announcements from individuals aren't officially endorsed by Hubitat and that using such code has inherent risks. Your level of risk tolerance is likely different than mine and I'm guessing is predicated by specific need. If I have a "need" for a something that's only available in the form of custom code, I generally make a decision based of who authored the code. If it's someone that has a good track record of addressing issues quickly then maybe the risk is worthwhile. If not, my decision is likely based on the urgency of my "need".
Also, a certification process is going to be labor intensive and costly and those costs need to be absorbed by someone. Want really fast certification for apps and drivers? Hubitat is going to need to add more staff or slow down their current development tasks to certify third party code. Speed not an issue? Backlog is going to be a problem and the complaints will start rolling in; "I submitted my app for certification 3 weeks ago and I haven't heard anything back yet".
Personally, I'd hate to have Hubitat staff use precious and limited resources doing anything with third party code. I'd much prefer them to keep on chugging along as they are now surprising us with new stuff and expanding the number of supported devices. Just one man's opinion
I've been following this in this and another thread and just thought I would voice an opinion.
I'm not trying to be controversial but just saying it as I see it.
Anything that can be loaded on my hub via this
and via the driver dropdown under this
are official HE apps and drivers.
Anything under
and this
is not.
So to me if I have to manually cut and paste in apps and drivers they are not official even if it says 'RELEASE' in a forum post it is not official if I have to manually do it.
Just me and my simplistic approach and as I say, I'm not trying to upset anyone but just give an opinion.
Can I just add that without any 'non-official' drivers and apps, my home will not be as automated as it is now.
I think we have a difference of opinion. I'd like to see a path for developers to be able to post "certified" versions of their apps in the forum. The other apps that aren't certified could be posted somewhere else. The way apps are listed now make them look official or at least have the appearance to work and have the blessing of Hubitat.
I can see that if someone used custom code from somewhere else and it messed their hub up, then yes, you get what you get. But something listed on the Hubitat forums looking like [Release]; that has the appearance of a supported app. I'd like for Hubitat to grow and have added features, and a lot of platforms allow for development, but I think it would be helpful to many to have a certified app program. I don't expect the Hubitat staff to support custom code, but I'd like to see ways we can view how code is performing on the hubs.
I'm sorry that I have an unpopular opinion, but I believe that to drive the system more mainstream and increase adoption, having apps that are certified is a need. Back when the first iPhone was released, the only way to publish apps was to jailbreak the phone and install apps from a third party. It was the wild west as far as apps\games went. Very quickly Apple saw potential in having an app store that provided "good" apps. I don't see why that would be a bad thing here.
I usually like to be pragmatic, so here is my question:
In your opinion, would it be ok to have a subcategory in the this community that clearly states that any app posted in that category are community developed apps and not "certified" or supported by Hubitat as the company?
There are many benefits in having one common community without splitting it off.
Hubitat says they get a lot of support calls for custom code. I think they can save themselves some headache with that by creating an app program. Otherwise, as I was told, they get what they get with increased support calls by allowing the custom code section to be the wild west.
I'm not anti app or anti developer, I'd like to see some better order and rules with how it's handled. I would think developers would love to have a section where their apps are featured and to see their apps widely used.
Perhaps a good start would be a forum section dedicated to Custom Code or "apps" with disclaimers. Right now I think a lot of them are kind of sprinkled around. Sure, the certify apps, that's going to take some work. It'll be up to Hubitat to evaluate that. Whether support costs for dealing with custom code outweighs the costs to develop a program. A program I think in the end will prove to be valuable even if it isn't at the beginning.
You've no need to apologise for having this opinion.
It's a perfectly valid one and I believe you have the best of intentions.
At the moment I'm just thinking if it ain't broke................. etc. etc.
OK, I hear you and understand. I know the limits; however, as our base of owners expands, not all are as aware as the respondents to this message. In an attempt to be proactive, I have added the following disclaimer to top of my TP-Link thread:
Disclaimer: No association with Hubitat
This integration is custom code developed by a Hubitat user. It is in no way certified by Hubitat.
The developer has fully tested this code within a home environment using available TP-Link and other devices. No significant problems have been found that would impact other integrations; however, the complexity of the Hubitat system does not guarantee some level of adverse interaction in other installations. Hub performance issues : If you have problems or issues with your hub performance, the following steps are suggested, in the following order:
Reboot the hub and see if the issue returns
Disable this integration and associated code and see if the issue returns
If removing the integration corrects the issue, contact the developer for corrective action.
Contact Hubitat support after removal and you are assured the issue is not with this code.
One of many reasons some of you migrated over here is specifically because we do not warehouse or aggregate any statistics or data regarding devices, drivers, applications or events, anonymous or otherwise...
It was a decision that the Hubitat team made. Two of the main points of Hubitat is that
a. It operates locally without the need of cloud resources
b. All data also resides locally without any aggregation/collection done by Hubitat
It is their main statement about the product when you look at the website.
Could they get information out if if were to collect it? Of course! Data collection, aggregation and sale of data a is a billion dollar business. However, Hubitat decided to not do it. I have to say, the Hubitat team is very involved in this community and actually listens to the needs of their users. I can't find any other system that releases so many feature updates as Hubitat does. Product development can strive even without the collection of user/usage data.
I don't think it is a question of right or wrong. It is one of those things where you have to make a decision on how you want to run your business and develop your products.
I for one like it and I can't see me moving away from the platform any time soon. It exceeds the expectations that I had after reading the product description! EDIT/ADD: Especially in combination with the availability of community developed apps/drivers.
Everyone is entitled to their opinion, though, and I respect that of the OP. I just disagree on the need.
I think the path proposed in the first post is detrimental to the product and user base, and is not grounded on need or data, but rather feeling/FUD.
The system could be improved in various ways, but it doesn't HAVE to be for the product - and developer user base - to continue to thrive.
The path mentioned simply discourages sharing of code more than it is already. I already share much less code here than I do on many other platforms because of the lack of user responsibility (and poor segregation between system and user space code).
There's the answer then. I cannot fathom how one could claim that the apps/drivers third party developers have built for this platform are installed by a small percentage of users, if in fact that's not a known statistic. I believe Hubitat has under valued the contributions of custom developers and has far under estimated the adoption of custom development artifacts.
Keep in mind I'm not advocating that it is a requirement of Hubitat staff to support custom code. I'm simply saying the context of this discussion maybe out of perspective.
