
* 🔥 Removes octopress.js * 🔥 Removes use of root_url var * 🔥 Removes Octopress generator reference from feed * 🔥 Removes delicious support * 🔥 Removes support for Pinboard * 🔥 Removes support for Disqus * 🔥 Removes support for Google Plus * ↩️ Migrate custom after_footer to default template * ↩️ Migrate custom footer to default template * ↩️ Migrate custom header to default template * 🔥 Removes unused template files * 🚀 Places time to read directly in post template * 🚀 Removes unneeded capture from archive_post.html template * 🔥 🚀 Removes unused, but heaving sorting call in component page * 🚀 Merged javascripts into a single file * 🔥 Removes more uses of root_url * 🚀 Removal of unneeded captures from head * 🔥 🚀 Removal of expensive liquid HTML compressor * 🔥 Removes unneeded templates * 🚀 Replaces kramdown with GitHub's CommonMark 🚀 * 💄 Adds Prism code syntax highlighting * ✨ Adds support for redirect in Netlify * ↩️ 🔥 Let Netlify handle all developer doc redirects * ✏️ Fixes typo in redirects file: Netify -> Netlify * 🔥 Removes unused .themes folder * 🔥 Removes unused aside.html template * 🔥 Removes Disqus config leftover * 🔥 Removes rouge highlighter config * 🔥 Removes Octopress 🎉 * 💄 Adjust code block font size and adds soft wraps * 💄 Adds styling for inline code blocks * 💄 Improve styling of note/warning/info boxes + div support * 🔨 Rewrites all note/warning/info boxes
3.8 KiB
title, description, redirect_from
title | description | redirect_from |
---|---|---|
Packages | Describes all there is to know about configuration packages in Home Assistant. | /topics/packages/ |
Packages in Home Assistant provide a way to bundle different component's configuration together. We already learned about the two configuration styles (specifying platforms entries together or individually) on the adding devices page. Both of these configuration methods require you to create the integration key in the main configuration.yaml
file. With packages we have a way to include different components, or different configuration parts using any of the !include
directives introduced in splitting the configuration.
Packages are configured under the core homeassistant/packages
in the configuration and take the format of a package name (no spaces, all lower case) followed by a dictionary with the package config. For example, package pack_1
would be created as:
homeassistant:
...
packages:
pack_1:
...package configuration here...
The package configuration can include: switch
, light
, automation
, groups
, or most other Home Assistant integrations including hardware platforms.
It can be specified inline or in a separate YAML file using !include
.
Inline example, main configuration.yaml
:
homeassistant:
...
packages:
pack_1:
switch:
- platform: rest
...
light:
- platform: rpi
...
Include example, main configuration.yaml
:
homeassistant:
...
packages:
pack_1: !include my_package.yaml
The file my_package.yaml
contains the "top-level" configuration:
switch:
- platform: rest
...
light:
- platform: rpi
...
There are some rules for packages that will be merged:
-
Platform based integrations (
light
,switch
, etc) can always be merged. -
Components where entities are identified by a key that will represent the entity_id (
{key: config}
) need to have unique 'keys' between packages and the main configuration file.For example if we have the following in the main config. You are not allowed to re-use "my_input" again for
input_boolean
in a package:input_boolean: my_input:
-
Any integration that is not a platform [2], or dictionaries with Entity ID keys [3] can only be merged if its keys, except those for lists, are solely defined once.
Create a packages folder
One way to organize packages is to create a folder named "packages" in your Home Assistant configuration directory. In the packages directory you can store any number of packages in a YAML file. This entry in your configuration.yaml
will load all packages:
homeassistant:
packages: !include_dir_named packages
This uses the concept splitting the configuration and will include all files in a directory with the keys representing the filenames.
See the documentation about splitting the configuration for more information about !include_dir_named
and other include statements that might be helpful. The benefit of this approach is to pull all configurations required to integrate a system, into one file, rather than accross several.
Customizing entities with packages
It is possible to customize entities within packages. Just create your customization entries under:
homeassistant:
customize: