Home Assistant: Difference between revisions

Line 55:

services.home-assistant = {

enable = true;

~~# Good starting config, that will get you through the configuration~~

~~# flow, that has a hard dependency on a few components.~~

#

# Components might not actually have YAML configuration, but

# mentioning them in the configuration will get their dependencies

Line 73:

Line 71:

</syntaxHighlight>

~~{{Note|Sometimes~~ configuration ~~is only possible via Integrations,~~ in ~~that case~~ the ~~integration itself must be prepared~~ in ~~your declarative configuration. e.g. for WLED integration support:~~ <code><nowiki>services.home-assistant.config.wled = {} ;</nowiki></code> is ~~required~~}}

==== Using components without YAML configuration ====

When a component has no YAML configuration its dependencies can in theory be installed by mentioning the component name in <code><nowiki>services.home-assistant.config.wled = {};</nowiki></code>. This is deprecated, since Home Assistant will usually complain about the config having been migrated into the graphical user interface.

In recent versions of the home-assistant this use case has become more prominent and therefore received a more straightforward implementation, that also ensures that the component is still provided by Home Assistant.

{

services.home-assistant.extraComponents = [

"wled"

];

}

</syntaxHighlight>

==== Making additional python packages available ====

We control the dependencies we pass into the Home Assistant python environment through module options that make the dependencies available, when their relative component was declaratively mentioned.

For other use cases like PostgreSQL support in the recorder component or the use of custom components, we provide an option to inject arbitrary dependencies from nixpkgs available python package set.

{

services.home-assistant.extraPackages = python3Packages: with python3Packages; [

# recorder postgresql support

psycopg2

# miele@home

flatdict

(callPackage ./pymiele.nix)

];

}

</syntaxHighlight>

==== Using custom components ====

We currently do not provide a way to declaratively manage custom components through the NixOS module. There is an open PR with an implementation, that still requires further work and discussion to make it a good solution.

* https://github.com/NixOS/nixpkgs/pull/160346

Until then custom components can be installed to <code><nowiki>/var/lib/hass/custom_components/</nowiki></code> as is the customary for Home Assistant.

==== Using custom lovelace modules ====

The support for custom lovelace modules is planned, same as for custom components.

* https://github.com/NixOS/nixpkgs/pull/160346

Until then lovelace modules can be installed to <code><nowiki>/var/lib/hass/www/</nowiki></code>, which uses Home Assistants internal webserver to serve files below <code><nowiki>/local/</nowiki></code> on your installation. This webserver will not follow symlinks, which we will allow in the future by applying a patch, which will be reasonable safe to do because of all the hardening options we apply by default. The patch in the question is part of the PR above:

* https://raw.githubusercontent.com/mweinelt/nixpkgs/hass-custom-everything/pkgs/servers/home-assistant/patches/static-symlinks.patch

=== Reusing existing YAML configuration ===

@@ Line 55: / Line 55: @@
    services.home-assistant = {
      enable = true;
-     # Good starting config, that will get you through the configuration
-    # flow, that has a hard dependency on a few components.
-    #
      # Components might not actually have YAML configuration, but
      # mentioning them in the configuration will get their dependencies
@@ Line 73: / Line 71: @@
 </syntaxHighlight>
-{{Note|Sometimes configuration is only possible via Integrations, in that case the integration itself must be prepared in your declarative configuration. e.g. for WLED integration support: <code><nowiki>services.home-assistant.config.wled = {} ;</nowiki></code> is required}}
+==== Using components without YAML configuration ====
+When a component has no YAML configuration its dependencies can in theory be installed by mentioning the component name in <code><nowiki>services.home-assistant.config.wled = {};</nowiki></code>. This is deprecated, since Home Assistant will usually complain about the config having been migrated into the graphical user interface.
+In recent versions of the home-assistant this use case has become more prominent and therefore received a more straightforward implementation, that also ensures that the component is still provided by Home Assistant.
+<syntaxHighlight lang=nix>
+{
+  services.home-assistant.extraComponents = [
+    "wled"
+  ];
+}
+</syntaxHighlight>
+==== Making additional python packages available ====
+We control the dependencies we pass into the Home Assistant python environment through module options that make the dependencies available, when their relative component was declaratively mentioned.
+For other use cases like PostgreSQL support in the recorder component or the use of custom components, we provide an option to inject arbitrary dependencies from nixpkgs available python package set.
+<syntaxHighlight lang=nix>
+{
+  services.home-assistant.extraPackages = python3Packages: with python3Packages; [
+    # recorder postgresql support
+    psycopg2
+    # miele@home
+    flatdict
+    (callPackage ./pymiele.nix)
+  ];
+}
+</syntaxHighlight>
+==== Using custom components ====
+We currently do not provide a way to declaratively manage custom components through the NixOS module. There is an open PR with an implementation, that still requires further work and discussion to make it a good solution.
+* https://github.com/NixOS/nixpkgs/pull/160346
+Until then custom components can be installed to <code><nowiki>/var/lib/hass/custom_components/</nowiki></code> as is the customary for Home Assistant.
+==== Using custom lovelace modules ====
+The support for custom lovelace modules is planned, same as for custom components.
+* https://github.com/NixOS/nixpkgs/pull/160346
+Until then lovelace modules can be installed to <code><nowiki>/var/lib/hass/www/</nowiki></code>, which uses Home Assistants internal webserver to serve files below <code><nowiki>/local/</nowiki></code> on your installation. This webserver will not follow symlinks, which we will allow in the future by applying a patch, which will be reasonable safe to do because of all the hardening options we apply by default. The patch in the question is part of the PR above:
+* https://raw.githubusercontent.com/mweinelt/nixpkgs/hass-custom-everything/pkgs/servers/home-assistant/patches/static-symlinks.patch
 === Reusing existing YAML configuration ===