-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for custom AppDaemon apps #77
Comments
I need to do a lot of research, before starting on this one. Do you have any example repositories for AD apps? Is the suggested local location the official suggestion from AD? |
I don't know that there are a ton of examples of repos specifically designed for shareable scripts. But here's an example of one with a number of scripts: Here's my repo, pretty basic at the moment but both scripts in there are completely designed to be used as-is, with only YAML configuration needed: I feel like there isn't really a standard at the moment for this, but I think having something standardized like HACS available would encourage more "ready-to-use" scripts to be developed. Every configuration I've seen posted on github has AD apps in /config/appdaemon/apps, but you're right that it's not a hard and fast rule. Would probably need to make that user-configurable in HACS. Like I said, I have a couple other ideas in mind that would work to do this outside of HACS, but if you're interested in the idea I feel like leveraging the framework that's already been built here makes sense. |
I would love to have AD in there to, I did some research to have it in custom_updater, but it could not find any clear standard. I could probably force the user to use that local dir for as one of the requirements, making an option would be too much that can go wrong. But the biggest issue: For now I don't think the AD community is ready for a change like that, I'm not even sure it would make sense |
That's a good point, since a typical AD app can be pretty small, a lot of people just store their apps as one big repo with every app in an individual folder. One repo per app feels like it would be overkill, but anything else would require more re-architecture on the HACS side. For now, I'll probably continue to explore what other options might be available, then. |
The same requirements apply to Lovelace plugins as well, some of those are only a couple of lines, but there most plugins are in a dedicated repository. So it could work for AD to, but for now I don't see that happening in that community, I may be wrong. |
That makes total sense! I will try and put out some feelers on the forum and see what the community's interest level is. |
Lots of apps here. |
@apop880 sample structure: https://github.com/ludeeus/ad-hacs |
So that's a sample in terms of how a repo for an app would be laid out? If so, I think that looks great! |
Correct 👍 |
Implemented in 0.9.0 🎉 |
Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
One benefit of AppDaemon that I think is underutilized is how reusable and shareable apps are. I think a lot of Home Assistant users are put off by the learning curve of learning Python to use AppDaemon. However, it's very possible for people to create apps that anyone can use without modifying the underlying Python code, that just take some YAML configuration to set up. It would be great to be able to have a section in HACS, in addition to custom components and Lovelace plugins, for custom AppDaemon apps that could auto update.
Describe alternatives you've considered
If this isn't something you're interested in implementing with HACS, I've looked at some other options for having apps auto update, but I think this would be the cleanest route and would put everything custom in one interface.
Additional context
Apps would land in the appdaemon/apps/<app_name> folder. And I think it would be possible to pull the suggested YAML configuration out and include it in HACS like Lovelace plugins do.
Also, I would be happy to take this on myself and put in a PR. But I wanted to run the idea by you before I start any work on it to see if it's something you'd be willing to merge or implement.
The text was updated successfully, but these errors were encountered: