Is there a community repository for Drivers and Apps?

We all have our own Repositories elsewhere in github. Some for ST, some for other projects, I didn't project that HubitatCommunity/ repositories would supplant personal repositories. I think development, abandonment, belong in our personal repositories. At the moment you're ready to "publish" it in a thread, that's when it could/should be put onto HubitatCommunity/ IMHO.

Maybe 100% of "your" HubitatCommunity/ is a readme pointing back at your personal github.


OK; that makes sense. But if you've got five projects in a personal repo, each a separate file/files, you're going to just copy one of the files over to your 'community' repo? You lose all version history, etc.

I'm not any kind of git/github SME.. way, way closer to newbie on the spectrum, but doesn't FORK do the job? You fork it from your personal repository and the history remains and is "traceable."

Sort of. If you have five files in your repo, you could fork it, delete the other four, and then you can sort of find the original history. But a fork is a 'copy', and each can change independently and get out of sync. It doesn't do much to address the goal of having a reliable, canonical version to refer to.

It sounds like maybe the Hubitat community is in a bit more rough-and-tumble phase than I knew! That's cool too! Maybe some repos will have clear projects and versioning, and some will have a more wild-west approach. If the Hubitat org ever wants to standardize, they could define a standard and track to it, then.

Let the coding begin! I'm gonna try to use pull requests and versions on a per-project basis, and you can all laugh at me. :grin:

1 Like

In 50% of the threads at community.hubitat (guessing) is some wad of code. Some of it is wholly reproduced, some is linked to github. It's horrible because you can't find it AND if you do, you have to scroll top to bottom to be certain there's not an improved copy buried lower. Yea, we've got an agreement to use the top message for that but.. that only works when the Thread is itself an announcement.

I simply hoped that this iteration of github code would be all of that but dedicated to code. Just a place to find code. A means to get the code. Extensions beyond that is gravy, in my opinion. Desirable, cuz I like gravy, but a place where developers of Hubitat code can 'advertise their wares' in any manner that suits their need. Want to "move in" to this HubitatCommunity/yours/ and have it be both your development and distribution site.. feel free. Want to contribute only a ReadMe pointing back to your better maintained site.. please do.

That's what rattled around in my head a couple days ago when I contributed. :smiley:

And now I see we need some disambiguation of community.hubitat (this site) and HubitatCommunity (the git hub location) :frowning:


@csteele @joshua

I'm sorry but I don't think this is for me.

I develop the code I want to, at a pace I'm comfortable with.
I also don't intend to collaborate on my projects which is one of the reasons I don't accept pull requests.
If someone has suggestions then I will usually try to accommodate and I always credit them if I use their code or suggestions.

One of the reasons to have my own GitHub account is so that I can control what is released with my name attached to it. Perhaps I'm too much of a control freak but that's the way I am

As the code I write is open source I am unable to control what people do with it after I have released it.
My update code is a prime example, where the old code was posted in this thread before it was complete, without any reference to me.

I think what you have to realise is that most developers do this for fun,or as a hobby, as soon as you start putting 'standards' or 'rules' in place a lot of developers (myself included) would find this disagreeable.



Makes sense! It's a shame Hubitat disallows loading modules, or it'd be really easy to distribute your excellent auto-update code.

I think where we've gotten to is exactly what you describe - each person, totally on their own to do what they want, but agreeing to stick their repos here so they can be easily found. Seems like a good place to start, to me anyway.


I agree Andy. You and Eric were two of the people I thought would be ReadMe only types. I don't think I'm alone in thinking that when a newbie shows up asking "where?" we have a much simplified answer. "Did you look in HubitatCommunity for more ?"

You've just described my nightmare. I don't want to be running something in my house on an old or buggy version of code.

As for the 'use the top message' agreement - I had never heard of it! . . . this is going to be much better!

There's a category of Getting Started and a tag of Code Share. That's where a lot of code gets released. Followed by discussions, improvements, etc. A lot of the time you'll see the originator say words to the effect of: "I've updated the code and updated message 1 to my github."

for example:

@Cobra said it perfectly and was what I was thinking too. I've seen it for years over on the HomeSeer forums and then on the ST forums. This is a hobby and people LIKE to be a lone wolf hacking away at their code, at their own pace. If other people find it useful, that's great! But most coders write code for themselves first, for fun or just for the challenge and then at some point chose to share it with the rest of us.

In my opinion, all that is needed is similar to what ST has had for years...a simple wiki. Something that can list the developers and a sublist of what they offer. Click on the link and it'll take you to their git. :slight_smile:

This is the ST unofficial wiki: Category:Unpublished SmartApps - Things That Are Smart Wiki


I agree with @bptworld. I think the wiki model that was setup by community members on the ST system is a good start.
It's essentially an index to the various GitHub projects developer's have produced/maintained.
It is also a resource for how to install, configure, etc or whatever information the developer or wiki community think you should know..

This is a link to the site that I think is formatted well to help users connect with community apps/drivers.

Regarding developer vs project organization. I lean heavily toward project based. People look for solutions to their issues or new/neat ways to do things. They don't necessarily want to navigate in/out of developer's to locate projects they may use. I may like so-and-so developer but have no clue that this other developer wrote something that addresses a need/want I have if I only go/search by developer.

1 Like

Being new to this, those links provided by @bptworld and @rayzurbock certainly point to forums which appear to have a better structure. allowing easier accesss to the wealth of information that already exists and is growing.
Whether Developer focused or Project focused, β€˜search’ would be my friend :+1:t2:

The GitHub organization that @csteele has created actually can have a wiki, too.

We could create that as well - then it would truly be a one-stop shop. Code and commentary, in wiki format. Reasonable/desirable?

1 Like

I am blown away at the seeming lack of interest on this by the community. Storage in Github would make finding and sharing code so much easier, as well as streamline checking for code updates and managing versioning, I mean look at the multisensor 6 as an example. That sensor has 4 different drivers that I am aware of. Some of those drivers have different versions posted in different locations throughout the forum. Wouldn't it be amazing to be able to go to GitHub, click Multisensor 6, and see all the different driver options in one place?

1 Like

Heh. I hear you, my friend. But organization is expensive, and happens slowly. My hope is that people will do what they wish, and if they see techniques that benefit them - like clear releases, single repositories - they'll use them. And if they don't benefit them, they shouldn't!

I suspect that Hubitat has to come up with a way to organize this stuff if they want there to be a good experience in the long run. I hope they have a plan - someone alluded to it. I'd love to hear about it!

There are little hints here and there, but I don't think any details have been shared.

1 Like

I know I'm new here, but here are my thoughts. The Vera "app store" built into the hub is really convenient. I don't have my Hubitat yet, but I know that on the Vera it's a PITA to manually load a plugin (usually at least 4 files, and then manually creating a parent device). The "store" based thing they have makes it easy.

I see people here are arguing that it's better that they maintain their own repos because they do this as a hobby. That's great, and that's what I do. However, when I'm done with my code, I submit it Vera's repo so it's all packaged up and available through their app store. You could do the same thing here, where devs only upload release code to make it easily available to users via a 1-click install inside the Hubitat UI.

Edit: Another thing to mention here is that Vera does a validation process on your code when you submit it. It generally takes them at least a few days. But, I'm sure it's to look it over and make sure people are doing anything malicious in it, and possibly installing it to make sure it doesn't crash LUUP. Having an official place to get apps from, that are vetted, is eventually going to be a requirement for widespread adoption of the platform. Casual users don't even know what github is. And people installing plugins from unknown sources and having problems is going to reflect badly (from the casual user perspective) on Hubitat itself, not the app developer.


Do you know how they pay for this service? Do app authors pay to have apps in the catalog? Or do users pay to get an app from the catalog? Or do you think they make it part of their overhead?

Overhead. Apps are free and it's free to submit. One of the ways to do it here is to have a committee which consists of Hubitat devs and community volunteers, and then submitted apps are assigned or picked up by members of the committee to vet.

There are also tools that can be used to do some automatic assessment of the code and automated testing to reduce manual overhead.