After spending a bit of time working on my own configuration to use packages to organize discrete automations and components in my HA config, I had a bit of a brain wave when thinking about how to extend and expand packages to provide a more seamless experience for the end user.
Develop packages in such a way that it allows for templating of entity id’s to allow for the packages to be more universal across different user specific installations. I.E - If I developed an alarm clock package, provide the ability to import parameters such as what light I want to turn on when the alarm goes off via something similar in nature to the secrets.yaml !secret <secret_name> call, except in this case it could be something like variables.yaml !variables <variable_name>.
Create a github for these packages and design a web ui component so that users could download and configure them all within the HA website. Documentation for setting up these packages can be provided in the same manner to components via the home-assistant.io website or if a way to install them by the web UI is made the configuration would essentially be self documenting.
Encourage users who have made projects on the community forums to package their projects into packages using and upload them to the new github for said packages.
With this methodology components would essentially add “devices” while packages would add “functionality/automations”. This would encourage the development of packages as a means to distribute complex automations in such a way that it would make it extremely easy for anyone to get started It would also set HA apart from the competition by curating high quality automations in the same way the development team curates components, allowing for an extremely easy drag and drop solution for commonly used automations such as alarm clock, manual alarms, climate, etc.
Additionally, I could see the development of a testing suite that would ensure these curated automations continue to function with the highest of quality as the core/component code of HA changes. This would ultimately reduce the number of issues being reported by users who simply have made errors in their configuration and reduce the workload for supporters who current spend a great deal of time troubleshooting non-issues.
Let me know what you all think. I would love to hear feedback and get thoughts on anything you would append to this idea.
We already have a system for this and it’s called components
As per the docs there are two type of components: components that provide integrations and components that provide automation. Examples of such components are Flux, Alert and Device Sun Light Trigger. There are also more generic components in this category, like the automation component.
Oh, and yes, components can register panels for the frontend so that’s also taken care off.
I think that YAML can only take us this far. If you want more advanced functionality you will need to use Python. This can either be a one off custom component or a more generic solution, in which case it would be cool if people contribute it back to the main repo.
My fear, as seen by the underwhelming number of components that actually add automation functionality is that the learning curve for python, code formatting requirements and the understanding of the core HA code makes developing such things in python out of reach for many community members. Many of whom who are quite capable of developing complex and robust YAML based automations. An example of this would be the lack of an alarm clock component, but an extremely expansive “Creating an alarm clock” community forum page: Creating a alarm clock
To double down, I’d also want to point out that HA YAML configurations are in my opinion absolutely massive. Just take a look at the complexity of any number of the configurations community members have provided on github, yet very few have developed components to provide similar functionality.
I see it two ways:
Embrace YAML, with all its flaws, as something that is inherent to HA and not going away and leverage it as a means to encourage those with the skills to understand YAML and not the skills to understand python to develop for the platform.
Some how educate the community on how to develop python based automations to a degree that they’ll begin to do so.
Fundamentally I think #2 is impractical. Especially as the community grows and the number of community members who understand the YAML syntax grows with each new user. While the number of users who understand the python syntax, formatting, etc. grows at a substantially smaller rate.
Ironically without the simplified YAML syntax I highly doubt that HA would have nearly the following it does today.
Feedback is always appreciated and thank you for chiming in @balloob.
AppDaemon seems to be making some progress on this forefront. A few great tutorials have been written for it as well that help in the introduction of concept and flow.
Agreed. The idea of drop-in, YAML-based package files is very popular on the gitter channel. Especially for those just starting and are looking for the quickest, easiest wow-factor to see what HA can do.
The idea for a !variable option would make these packages much more flexible. But maybe the existing secrets architecture can be used instead of developing something new.
would be much more concise and a little less brainwork
The pain point for me was when I had to write a lot of automations.
Being able to specify a yaml “shortcut” would be nice.
Some automations are easily written in using the yaml automations syntax, while some would be more time-spent efficient to write in code.
I propose both options be available, but distributed as zip files to streamline installation and management.
Activating an automation package, would be as simple as dropping it into a directory and configuring it in the yaml.
each implementation can be written as a separate appdaemon-style runner, and on restart, the automation package component can delegate each package to it’s runner.
I like the idea of providing something that can be transferred across users, but I’m not sure if packages are the best solution. First, there is the problem of discovering packages - how do users find the right packages. Further, given that most users will have different devices and different requirements, it is unlikely that one package will serve many users. Packages are inherently more complicated than simple YAML, making troubleshooting even more difficult. Who will spend efforts guiding users as to how to use these packages?
Users can already search repositories of users and copy the relevant YAML code, which is relatively easy to understand. The proposed approach will add lot of complexities without any meaningful gains. I agree with @balloob, let us not stretch YAML to something that it is not designed to do.
Great suggestion @keatontaylor. I like the enthusiasm to extend the ease of usage.
Building on @rpitera comment, this sounds more like an “app repository” for appdaemon perhaps as an alternate way to add functionlity in pre-baked chunks of multiple components.
I do like YAML in that I can use it for making things work through pure configuration rather than having to “open the hood” and write my own components for everything. (I am a code dabbler but really like that most can be done with configuration)
