Is there a community repository for Drivers and Apps?


#22

Not sure whether this comment belongs here or on the original HE/Intermatic thread, but...

I appreciate @joshua's offer to consolidate and maintain a repo for the PE653 driver. I think that would be a great boon, but I would want to see @keithriley's buy-in. I may be way off-base, but my understanding is that we are relying upon Keith's code. @JMack89427 and @JDogg016 have made contributions to that, but I thought the plan was that Keith would take their updates and integrate them back into his code and he'd maintain it (for as long as he's willing).


#23

I'm going to go read it. . . . I am wondering whether I could modify it to look at the releases in Github for the repo rather than you needing to update a file.


#24

OK, I -thought- I got his buy-in, but if not, feel free to discard and destroy, no skin off my back/nose/teeth, as the saying goes. Apologies, @keithriley if I missed a memo or stepped on any toes.

And anyone who wants access, holler - it's here:

I'm also happy to transfer it to someone if that's desirable. See the convo in the other thread for what I did.

I'm jazzed to be joining this great group, and whatever I can do is great!
I'm also happy to host a zoom meeting/etc to discuss this really quickly.


#25

I created GitHub - HubitatCommunity/HubitatPublic and invited collaborators tooluser & cobravmax.

The Readme needs a LOT of work :smiley:


Community Apps/Drivers Portal
#26

No problem. I just didn't see it.


#27

Thank you for stating this. I have been thinking this since the time I started messing around with Hubitat. I am coming from Vera where most user developed apps/plugins/integrations are centralized in a repository accessible directly though the hub and apparently maintained on the corporate servers. It was a very convenient system, and basically similar to what we see here with the such apps as Rule Machine, etc.

At a minimum a wiki or other such maintained list would be helpful.


#28

Are there any things we could use to seed this fantastic repository of fantasticalness? Any really standardized plugins that everyone uses, which have become relatively stable?

By putting things in a single repo, we're tied to versioning them together, so we have to be able to say essentially "Here is Standard Kit 1.0", even if individual elements still get occasional revs.

Whatever we do, we should follow a predictable structure so people can find the stuff. Being a semi-official repository is a big obligation; you can tank a lot of people's experience if it's hard to find things.

Also, does anyone know what Hubitat's proposed solution is for incorporating these/versioning them, as @Wekurtz was getting at?


#29

I'd love to see this code! I'll try to add it to the Intermatic 653 DTH. My GitHub user is @tooluser.


#30

I added tooluser as a Collaborator yesterday and it got accepted.

Also, I extracted a cheat sheet...

DRIVER 
Metadata {
	...
        attribute "DriverVersion", "string"
        attribute "DriverAuthor", "string"
        attribute "DriverStatus", "string"
	...
}

def updated() {
	...
    version()
	...
}

// Check Version   *********************************************************************************
def version(){
    updatecheck()
    if (state.Type == "Application"){schedule("0 0 9 ? * FRI *", updatecheck)}
    if (state.Type == "Driver"){schedule("0 0 8 ? * FRI *", updatecheck)}
}

def updatecheck(){
    setVersion()
    def paramsUD = [uri: "http://<some Location>.com/versions.json"]
       try {
		httpGet(paramsUD) { respUD ->
			//  log.info " Version Checking - Response Data: ${respUD.data}"   // Debug Code 
			def copyNow = (respUD.data.copyright)
			state.Copyright = copyNow
			def newver = (respUD.data.versions.(state.Type).(state.InternalName))
			def codeVer = (respUD.data.versions.(state.Type).(state.InternalName).replace(".", ""))
			def codeOld = state.version.replace(".", "")
			state.UpdateInfo = (respUD.data.versions.UpdateInfo.(state.Type).(state.InternalName)) 
					
			if(codeVer == "NLS") {
			    state.Status = "<b>** This $state.Type is no longer supported by code  **</b>"       
			    log.warn "** This $state.Type is no longer supported by code **"      
			}           
			else if(codeOld < codeVer){
				state.Status = "<b>New Version Available (Version: $newver)</b>"
				log.warn "** There is a newer version of this $state.Type available  (Version: $newver) **"
				log.warn "** $state.UpdateInfo **"
			} 
			else { 
					state.Status = "Current"
					log.info "$state.Type is the current version"
			}
		}
       } 
        catch (e) {
        log.error "Something went wrong: $e"
    }
    
    checkInfo()
        
}        

def checkInfo(){
  if(state.Status == "Current"){
     state.UpdateInfo = "None"
     sendEvent(name: "DriverUpdate", value: state.UpdateInfo, isStateChange: true)
     sendEvent(name: "DriverStatus", value: state.Status, isStateChange: true)
    }
    else{
     sendEvent(name: "DriverUpdate", value: state.UpdateInfo, isStateChange: true)
     sendEvent(name: "DriverStatus", value: state.Status, isStateChange: true)
    }   
}


def setVersion(){
     state.version = "<some Ver>"
     state.InternalName = "<some Name>"
     state.Type = "Driver"
   
     sendEvent(name: "DriverAuthor", value: "<some Author>", isStateChange: true)
     sendEvent(name: "DriverVersion", value: state.version, isStateChange: true)
}

[Updated]


#31

@csteele

Old code.

Yet the json in github is the newer version it seems


#32

Which one has the latest? it's true, I just picked the first Driver or App I found in your github.

I used my cheat sheet to add code to two drivers (don't have any Apps I'm maintaining) and using that .json, got the expected result


#33

The latest version is on my test hub.
You are missing quite a bit with this one.
There is also different code for apps.


#35

Anyone have experience with GitHub Organization? It sure seems like the right way to organize this.

Organizations are shared accounts where groups of people can collaborate across many projects at once. Owners and administrators can manage member access to the organization's data and projects with sophisticated security and administrative features.

But before I click the Transform to Organization button, maybe some things need configuring first?


#36

I do have experience with organizations, and concur that it's the right format for this, so long as there are a number of repositories that are ready to adopt a similar layout/release pattern, and share developers across them.


#37

OK, I transformed it to an Organization and created a Repository for each Collaborator. I then invited each Collaborator to be a Member of the Organization.

I'm sure there needs to be dozens more Collaborators/Members to make this usable. Any suggestions for Next To Do ?


#38

Thanks for doing this!

I would suggest we have repositories per-project (driver/app), rather than per-person. (Could you delete my repo, or give me access to do so?) That fits the collaboration model for projects.

I can move in the Intermatic 653 repo, and notify that thread.Are there other projects that would be good to move in?

One other question - what's the "HubitatPublic" repo intended for?

I could write a brief tutorial on using Github Community/Repos/Releases/pull requests etc if it's useful. I could make it the readme for one of these repos, I suppose.


#39

I'm not a developer but as a power user, I like the per developer model (like the picture) much better. As a user we always have our favorite developers. Having all their work in one area (then sub-folders for each project) makes it much easier to see what else they have done.

Going to be great to see most of the developers in one area though! Great ideas flowing here.


#40

I thought /HubitatPublic would be a good place to "pin" Instructions. This Thread will creep to the bottom soon and anything useful will become notoriously hard to find.


#41

What you're describing (per-developer 'tribes' of code) is valuable - but it's not a community repo, is it? It's just a convenient place to find people.

In general I observe immature projects are owned by a single developer. These change fast, but they're unstable - all it takes is someone getting married, having a kid, changing jobs, etc for code to die and be orphaned. Those are 'beta' software - at your own risk kinda stuff, with a high tolerance for reinventing the wheel, incompatibility, etc.

As projects stabilize they take in more of the community, and more people are involved. They use standard practices, version well, and are reliable.

I am dubious of the value of calling a loosely connected bunch of developers an 'organization'. Speaking as a developer, even if I am working on a lone-gun project, I don't mix my files in with files related to another driver or app. (I'd take that as a sign of someone who wasn't very organized.) So I'd still want a per-project repo, just owned by me.

I'll go with the flow here, but IME a successful community has community standards and is focused on projects, not people.


#42

For example, look at the zwavemultichannel-pe653 repo. Clear versions: