[BETA] Hubitat Package Manager

Hmm could you try again? That makes it seem like it's waiting for a response from github. Maybe I need to add some more error handling on failed requests.

Hi dman2306

It worked fine this time, so not sure what happened. Below is the logs of this run

app:1292020-04-29 20:06:14.984 infoUpgrading One at a Time Child

app:1292020-04-29 20:06:12.437 infoUpgrading One at a Time

app:1292020-04-29 20:05:59.749 infoUpgrading Life360 with States

app:1292020-04-29 20:05:59.017 infoDownloading One at a Time Child

app:1292020-04-29 20:05:57.032 infoDownloading One at a Time

app:1292020-04-29 20:05:55.817 infoDownloading Life360 with States

dev:462020-04-29 20:05:53.990 info'switch' set to 'off'

app:1292020-04-29 20:05:48.344 infoChecking for updates for The Flasher

app:1292020-04-29 20:05:48.110 infoChecking for updates for Hub Rebooter

app:1292020-04-29 20:05:47.799 infoChecking for updates for One at a Time

app:1292020-04-29 20:05:47.529 infoChecking for updates for Life360 with States

app:1292020-04-29 20:05:47.222 infoChecking for updates for Hubitat Package Manager

app:1292020-04-29 20:05:46.972 infoChecking for updates for Matthew (@scottm61)

app:1292020-04-29 20:05:46.848 infoChecking for updates for OpenWeatherMap-NWS Alerts Weather Driver

--- Live Log Started, waiting for events ---

So, even if the developer chooses not to use your app then users are able to point this to their github and the apps/drivers can be imported?
Is this how this works?

Andy

Yep, same as they'd be able to just copy the code off of github by hand.

1 Like

I'll keep looking and see if I can find anything.

If you then made a private repository on GitHub that the app had authorised access to (somehow not revealed in the code) then this could be used ? Or with the recent new GitHub expanded features for private repositories you could add 'authorised' users to a private GitHub repository - again if that's possible ... read onl

But once authorised on a different site like Cobra's or srwhite's - can't they do that anyway ? I really don't see what added security this arrangement offers except knowing who is accessing your code ?

The HPM app won't be able to access the private repo to download the groovy code.

Can't that access be obscured in the code some way ?
Regardless once in HE the code is visible.

Not sure I follow. HPM needs access to the location of a groovy file that is hosted on a website that can be accessed without a username/password.

I suppose technically yes, it could live behind a non-public wall of some sort. I'm not sure what authentication method would work, but a closed source ecosystem could provide a token which the package manager could add to the request -- but nothing like that exists yet.

But I don't think that's what Hubitat Package Manager is about, and it's not what the manifest generator I made is about either.

Both are in place to serve the convenience of the user, not the developer. The user then can get updates without manual (and error prone) copy/paste, and even without needing to monitor the tech support thread on this forum.

In the case of the manifest generator, it further simplifies the process by letting the user generate a manifest file for a github repository which they don't have write access to.

I was thinking along the line of allowing support for private repositories that had enabled access for a 'HE Package Manager' user.

A private repository hosted on GitHub doesn't have functionality that would support that. It'd have to be some custom code which gave out the code in the presence of an auth token of some sort. It could be as simple as a query string, now that I think about it, which probably wouldn't need any modification of the package manager as is.

1 Like

Could something be built? Yes. Will I? No. The only thing I said I will NOT consider adding to HPM is support this feature. While developers are free to deliver their apps and drivers however they wish, that's not a model I believe is good for this community and it's not one I'm in favor of and so I don't plan to put effort into building something like that when 99% of HE developers are fine putting their stuff up publically. They don't need to host their files on github, but they do need to be hosted somewhere that is not behind a username/password system.

7 Likes

@dman2306

I have noticed a couple times when I've update multiple bptworld files, you select all of them and select next, it will show a blank box with a Done button. But it will update individually.

If I see it again, I will log it

1 Like

I agree - my apps are on GitHub (although my final licence terms are still being considered) and I actually don't see what, if any, increased protection a private server offers. However I do not feel that Hubitat themselves do their bit here with closed source offerings.

I must be missing something with private servers ... am I , maybe just having to acknowledge acceptance of the licence conditions ? All contributed HE apps and drivers have source code exposed.

1 Like

I mean, what's best for the community is a hard thing to pin down. It's often true that the best thing for the community isn't what some of the people want. I think the best thing for Hubitat (the community, and the device) is home automation interoperability. Some people think it's the forums, others open source drivers.

Hubitat (the company) doesn't seem to value open source the way many people in this forum do -- their code isn't published. They need to sell hubs, for one. We want this! My guess is that they're not allowed to share at least portions of the code due to NDA for proprietary APIs of one vendor or more. I'd love to poke around and see what Hubitat (the device) is spending its time doing, but it doesn't matter to me in the way that a lot of free (as in freedom) software junkies think it should.

That said, there is a large economy of software developers around here who are donating time. If there's one thing I know about donated time, it's that it goes away. The worst part about free software is that it gets stale so quickly when someone has no time for it. The reason I'm on a Hubitat in the first place is that it was cheaper and quicker to get my devices on HomeKit with a new Hub than it was for me to dive into fixing the HomeBridge plugin for my last hub, which was a project someone once loved and now has forgotten.

OP @dman2306 has invested a lot of time in this app, but we know his time isn't infinite. We should be thankful for the time spent with the best intentions for the hubitat community.

But also, equally

If a developer wants to find a way to release a proprietary driver through a login screen or otherwise, even if they want to attempt to validate installs by one method or another, that is okay!

The best part about a market is that you don't have to participate if you don't want to. There are free markets and there are paid markets.

If I had a device which someone wrote a driver for, and they charged a reasonable price for it, I'd probably pay for it. I pay for a lot of software which I use every day, and the software running on my hubitat is executed hundreds or thousands of times a day by everyone who interacts in my house.

2 Likes

This was the main reason behind my move away from public github to my members website.
I know it's not foolproof but it gives me some comfort :slight_smile:

I'm really not sure of your reasoning here.

With one or two exceptions, everyone is granted access to free membership on https://cobra-apps.co.uk

ALL my apps & drivers come with multiple web pages showing installation and use instructions.
EVERYTHING is documented - That's why it took so long to produce

I have a full helpdesk ticketing system where errors and requests are logged and dealt with in a timely manner.
If a ticket is registered, both @Royski and myself know about it instantly via email.

I provide an email system which enables email directly from your hub.
This costs me to provide & maintain at no charge to the user

Compare that to most github repositories which have little or no documentation and no organised response. (I'm not criticising anyone here as I know the time it takes to document and support anything)

Now I have a genuine question:
How is this bad for the community?

Andy

2 Likes

I have no issue what you are doing with your code.

But the devil's advocate would counter with - and why can all of that not be done WITHOUT the login requirement? How is that part improving anything for the end user?

I'm not saying the things you're doing are bad, but couldn't every single thing you said have been done WITHOUT requiring access to your website? A helpdesk, an email system, documentation, none of that required you to make it private.

The decision to make it private is what I don't personally support. All the other stuff is great. I just don't really see why you needed to put it behind a website like that so that the community as a whole requires permission to get it. Again, you're free to do as you like. You're not doing anything wrong, but it's not what I think is best.

1 Like

Lol. I should have just shut up. Dman posted the same thing I did.

3 Likes