Looking for input, GitHub repo and HPM Packages

I am going to be adding more drivers to GitHub and HPM and I am trying to lay it out in a organized fashion. GitHub is not very friendly if you want to move stuff around so hopefully can move some things once and be done. Looking for thoughts and maybe this could be a guide to new developers as well?

Here are some givens IMO

  • Separate folders for Drivers and Apps
  • Within Drivers, for physical devices use separate folder per brand.
  • File names contains brand, model, and what the device is (switch, sensor, etc...)
  • So you end up with something like this: Hubitat/Drivers/zooz/zooz-zen-switch.groovy

This is what I am debating and have seen it done both ways.

  • Add subfolders for every driver set/package, most folders end up with only one file. This seems like overkill and I think it is possibly how SmartThings requires it to be so people just carried that over?? Only advantage of have all separate folders is the package json, and the changelog (if I have a separate file) can be in there. I would just need to have a plan for that all in one folder to keep it tidy.

  • Do I put for example ALL the Zooz drivers in one HPM package, or do a separate package for each "set", most would only be one file, but some could have a couple files. Seems like the intention for HPM is to have a package for each set/forum post, but I have seen some with everything in a single package.

  • Also thinking about the HPM packages and naming of things, how to make it so users can find stuff by searching the model numbers or brand.

1 Like

I'm curious what others think here, too. Even some of these assumptions turned out to be problematic for me (separating apps and drivers into different folders works well for simple apps and drivers, but some of my projects are a combination of apps and drivers, like my "notification proxy," and with some large projects like CoCoHue, I just decided to make it an entirely separate repo instead; not sure what to do in that former case except maybe pick one category, like apps, to put both app and related driver in if that happens? I should probably do that, but as you note, I'm not aware of a user-friendly way to move things...).

I haven't found a value in a separate folder for each app/driver unless they are complex enough to need multiple files (lots of my apps are, even if just parent app, child app, and HPM repo), but I could really see that going either way. I suppose it would be consistent if done that way (especially if there is an HPM repo file for each), even if it needs an extra click for people manually browsing your GitHub.

Regarding all related (e.g., Zooz) drivers in one package vs. each in a separate package, I think my preference is for the latter. I see the value in the former (easier to maintain) but suspect it might be less user-friendly (needing to choose "optional" components and go back in and reconfigure if you change your mind, rather than searching for new packages as might be most intuitive). But then that makes more HPM packages, more searching, and again probably more work for the maintainer. I'm not sure what the best thing really is. I'm curious what others think--like all of the above, this is just my opinion. :slight_smile:

1 Like

As both of you have said, either will work. I would probably lean to what would be simpler for the novice/basic user to understand. I think that is organizing by the specific device (e.g., Zooz switch, Zooz dimmer). There are far more users who fall in that camp than the advanced user camp. That follows the HE team’s efforts at ease of use. They are trying to help broaden the user base as much as possible. That will mean more novice users in the future that will do not want to grow beyond the basics. If it is easy to understand, they will use it.

On the question regarding apps with drivers, what is it primarily? Is it an app that needs drivers to function (Simple State Machine), or devices facilitated by and app (Wemo devices)? Decide the storage location based on the primary function.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.