I'm really jazzed to see all this development! I was afraid, getting into Hubitat, that I was going to have to stumble through it on my own.
I see a lot of development is handled in an ad-hoc format here in this thread. How is best to make sure one is up-to-date on current versions? There's a GitHub repo, I see - is there any plan to use GitHub pull requests/branching/versions? I'd be happy to maintain that structure if it could help keep versions clear.
I'm all for this. I see this repo https://github.com/hubitat/HubitatPublic that appears to be owned by @mike.maxwell . I'm not sure if that's something that we could use for Hubitat-wide user-created drivers/apps or if we should start something else?
@JMack89427 Dig it. The current repo is owned by you. It looks like it has both 'current' and older versions in it. Something like the
quickGetWaterTemp feature @mike.maxwell is working on could be tracked as a branch and pull request. . . . if people are comfortable with that kind of workflow. I don't want to step on any toes, nor make it harder for people to contribute -- only to organize contributions so they're clear and don't cause regressions, and so people can always find the version they want.
Given my druthers, I would:
- Introduce a 'readme' with details about what is fixed in each version
- Create 'releases' that are tagged versions of the repo so people can readily find the version they want
- Use GitHub issues? Perhaps? To track what is being worked on so the thread doesn't get confused
- Use branches/pull requests to make fixes merging really clear - then people who wanted to work with a branch/beta version could, but others would know what was current and stable.
The latter two I'm unsure about. Are people familiar w/ branching and pull requests? Or would that create a barrier to entry that is too high?
You're the current repo owner, right @JMack89427? (I'm not even 100% sure of that. . . .)
If we did something like this, it could be a natural fit for eventual 'promotion' to eg the
HubitatPublic repo - it looks like that is fairly stalled at the moment, but they do have a repo of contributed code. If we got this stable and versioned, I'd be happy to talk w/ them about how to get this into it once it was complete and stable.
All of this with a big ol' grain of salt - I've been lurking and I think I have a feel for what's happening, but, again, don't want to step on any toes!
Say the word, I'll do the above - let me know what repo to do it in. I could even create a new one with a clear history and versions and make everyone here a contributor/owner.
The repo that I house the current code in was only created so that I could share the code. I'm happy to leverage that if people want to start there. I envision something more community-centric where different projects can come together. That way, when someone is looking for a driver or app, they have a one-stop-shop.
That's Hubitat's "corporate" repo and probably should remain the "official" one. A variant on the name MIGHT be a better solution for "unofficial" code.
https://github.com/hubitatCommunity/HubitatPublic <-- for example
Hubitat has said that 1) don't really want git integration like ST did.. something better is desired.
I think it would be wise to setup a https://github.com/hubitatCommunity/HubitatPublic/ at the very least. @joshua if you are willing and able, give it a crack unless a hundred critiques would offend, because there are at least that many people with their own github structure
Concur re: the public repo, that's the one I meant, sorry.
"Strong opinions, weakly held" - that's my motto. I run a large-ish team converting some ancient codebases with a mishmash of practices now, so holding a lightning rod is my day job. . . .
BUT I'm still concerned about branches and pull requests. Is everyone who here who is working on the code comfortable with making a branch, doing their thing, and then merging, potentially after getting review and commentary on the pull request?
It can be a great way to bring people up to speed on how to build their own, because otherwise everything happens in the dark. But only if the people contributing code currently (@JMack89427 - you're down, thank you - @csteele it sounds like you are - @mike.maxwell sound good to you?)
- Create a Habitat Public organization, even though it'd only have our stuff in it for now - just in case.
- Make it explicitly open-source.
- Create a repo for this project, mimicking Hubitat's folder structure, so that if they want to 'adopt' things the community develops they can.
- I'd take your existing repo @JMack89427 and use it to seed the above, including releasing versions.
Then people could start creating branches and people who wanted to learn could watch those branches. We could use this thread to coordinate and announce releases.
LMK your GitHub user names and I'll do it, or, again, LMK if I'm going too fast here!
@joshua - Sounds great. Nothing is set in stone but this seems like a great stepping off point and I really appreciate your willingness to be the point person on this!
This Community supports "Titles" in our profiles. Mine is "Developer", "Owner" is quite common, etc. To have Developer added to your profile, thus allowing you to select it, you'd contact support @bobbyD
Perhaps there's a way to communicate with all holding a Developer title, offering to add them to the Repo.
Then that would need to be in the README.
I just realized that I replied the above on the wrong thread - or at least not the one I intended. I was going to get it started on just the Intermatic 953/653, and then have a larger conversation about building a larger community process once we had a good flow worked out. I think I'll still do that - but I am willing to help build the larger, too.
Oh no; I see, you split the thread. Nifty.
I think there is a need for both: A central Public repo, and individual repos for things under faster development.
Releases (and versioning) apply to an entire repo at once. Code typically iterates quickly at first, and then stabilizes.
I'd like to suggest a model where anyone can host a module until it stabilizes, at which point it can be incorporated into a standardized public repo. Iteration may happen there, but will usually be (eg) broad changes that affect everything.
This will also let us work out a flow and make it minimally annoying before we bother a lot of people.
We can use this thread to discuss the larger repo and what Hubitat and active developers would like out of it, so we get it right. Your idea of contacting support and getting their input seems like a very good idea.
Yes, I asked that the thread be split so as to not Hijack the Intermatic one.
Without GitHub integration it can be difficult to keep up with new versions of custom drivers and apps
That's why I'm starting to add weekly version checking to any app/driver I release.
This way alerts appear in the app or on the device page and in the logs if there is an update available
I do this by reading a json file hosted on a 'hubitat.uk' website I registered
I'm happy to share the code and discuss hosting other json files if any developer is interested
That's awesome! I would love to try adding that to a DTH. Can you start a thread on it?
This is how it appears in an app:
And this is a driver:
Don't know how I missed reading every word of your excellent description.
And when there is no update available...
Yea, I saw that in your code weeks ago and was envious.. very smart, brilliant.
Refined it a little bit and removed references to 'Cobra' as a weekly schedule called Cobra was confusing some people.
Now it's called updateCheck - A bit more obvious
Obviously you can steal the code but I'm happy to host you a json file (and can give you ftp access to upload it to hubitat.uk )
You can see the json format by going to
Yes, I lurked during your problem when the file changed. Once it settled out I snooped heavily and understand it.. which is of course why it's brilliant.
Those damned commas... catch me out every time