diff --git a/_config.yml b/_config.yml index 241824da44f..9c0ada1e718 100644 --- a/_config.yml +++ b/_config.yml @@ -211,6 +211,8 @@ installation: key: "odroid-c4" - name: "ODROID-M1" key: "odroid-m1" + - name: "ODROID-M1S" + key: "odroid-m1s" raspberrypi: board: Raspberry Pi diff --git a/source/_dashboards/calendar.markdown b/source/_dashboards/calendar.markdown index 18ae6b31661..f29605ce1e4 100644 --- a/source/_dashboards/calendar.markdown +++ b/source/_dashboards/calendar.markdown @@ -17,19 +17,6 @@ The calendar card displays your [calendar](/integrations/#calendar) entities in All options for this card can be configured via the user interface. -## Card settings - -{% configuration_basic %} -Title: - description: The title displayed at the top of the card. -Initial View: - description: "The view that will show first when the card is loaded onto the page. Options are `Month View`, `Day View`, or `List (7 days)`." -Entities: - description: The calendar entities that will be displayed in the card. -Theme: - description: Name of any loaded theme to be used for this card. For more information about themes, see the [frontend documentation](/integrations/frontend/). -{% endconfiguration_basic %} - ## YAML configuration The following YAML options are available when you use YAML mode or just prefer to use YAML in the code editor in the UI. diff --git a/source/_dashboards/masonry.markdown b/source/_dashboards/masonry.markdown index 1c6e41ee2f3..53e8d7c065d 100644 --- a/source/_dashboards/masonry.markdown +++ b/source/_dashboards/masonry.markdown @@ -2,7 +2,7 @@ type: view title: Masonry view sidebar_label: Masonry (default) -description: "The default panel layout uses a masonry algorithme." +description: "The default panel layout uses a masonry algorithm." --- The masonry view is the default view type. @@ -12,7 +12,14 @@ The masonry view is the default view type. Screenshot of the masonry view.

-It sorts cards in columns based on their `card size`. If you want to group some cards you have to use [horizontal stack](/dashboards/horizontal-stack/), [vertical stack](/dashboards/vertical-stack/), or [grid](/dashboards/grid/) cards. +Masonry sorts cards in columns based on their card size. The next card is placed below the smallest card on the dashboard. + +

+Image showing how masonry arranges cards based on size. +Masonry arranges cards based on size. +

+ +To group cards, you have to use [horizontal stack](/dashboards/horizontal-stack/), [vertical stack](/dashboards/vertical-stack/), or [grid](/dashboards/grid/) cards. {% configuration %} type: diff --git a/source/_docs/configuration/splitting_configuration.markdown b/source/_docs/configuration/splitting_configuration.markdown index f5558c53bc7..59cf7fec3c0 100644 --- a/source/_docs/configuration/splitting_configuration.markdown +++ b/source/_docs/configuration/splitting_configuration.markdown @@ -3,15 +3,23 @@ title: "Splitting up the configuration" description: "Splitting the configuration.yaml into several files." --- -So you've been using Home Assistant for a while now and your `configuration.yaml` file brings people to tears or you simply want to start off with the distributed approach, here's how to split the `configuration.yaml` into more manageable (read: humanly readable) pieces. +So you've been using Home Assistant for a while now and your `configuration.yaml` file brings people to tears because it has become so large. Or, you simply want to start off with the distributed approach. Here's how to split the `configuration.yaml` into more manageable (read: human-readable) pieces. -First off, several community members have sanitized (read: without API keys/passwords etc) versions of their configurations available for viewing, you can see a list of them [here](/examples/#example-configurationyaml). +## Example configuration files for inspiration -As commenting code doesn't always happen, please read on for the details. +First off, several community members have sanitized (read: without API keys/passwords) versions of their configurations available for viewing. You can see a [list of example files here](/examples/#example-configurationyaml). -Now despite the logical assumption that the `configuration.yaml` will be replaced by this process it will in fact remain, albeit in a much less cluttered form. +As commenting code doesn't always happen, please read on to learn in detail how configuration files can be structured. -In this lighter version we will still need what could be called the core snippet: +## Analyzing the configuration files + +In this section, we are going use some example configuration files and look at their structure and format in more detail. + +Now you might think that the `configuration.yaml` will be replaced during the splitting process. However, it will in fact remain, albeit in a much less cluttered form. + +### The core configuration file + +In this lighter version, we will still need what could be called the core snippet: ```yaml homeassistant: @@ -27,9 +35,11 @@ homeassistant: customize: !include customize.yaml ``` +### Indentation, includes, comments, and modularization + Note that each line after `homeassistant:` is indented two (2) spaces. Since the configuration files in Home Assistant are based on the YAML language, indentation and spacing are important. Also note that seemingly strange entry under `customize:`. -`!include customize.yaml` is the statement that tells Home Assistant to insert the contents of `customize.yaml` at that point. This is how we are going to break a monolithic and hard to read file (when it gets big) into more manageable chunks. +`!include customize.yaml` is the statement that tells Home Assistant to insert the parsed contents of `customize.yaml` at that point. The contents of the included file must be yaml data that is valid at the location it is included. This is how we are going to break a monolithic and hard to read file (when it gets big) into more manageable chunks. Now before we start splitting out the different components, let's look at the other integrations (in our example) that will stay in the base file: @@ -51,9 +61,20 @@ mqtt: state_topic: "test/some_topic2" ``` -As with the core snippet, indentation makes a difference. The integration headers (`mqtt:`) should be fully left aligned (aka no indent), and the key (`sensor:`) should be indented two (2) spaces. The list `-` under the key `sensor` should be indented another two (2) spaces followed by a single space. The `mqtt` sensor list contains two (2) configurations containing two (2) keys each. +As with the core snippet, indentation makes a difference: -While some of these integrations can technically be moved to a separate file they are so small or "one off's" where splitting them off is superfluous. Also, you'll notice the # symbol (hash/pound). This represents a "comment" as far as the commands are interpreted. Put another way, any line prefixed with a `#` will be ignored. This makes breaking up files for human readability really convenient, not to mention turning off features while leaving the entry intact. +- The integration headers (`mqtt:`) should be fully left aligned (aka no indent). +- The key (`sensor:`) should be indented two (2) spaces. +- The list `-` under the key `sensor` should be indented another two (2) spaces followed by a single space. +- The `mqtt` sensor list contains two (2) configurations, with two (2) keys each. + +#### Comments + +The # symbol (hash/pound) represents a "comment" as far as the commands are interpreted. Put another way, any line prefixed with a `#` will be ignored by the software. It is for humans only. Comments allow breaking up files for readability, as well as turning off features while leaving the entry intact. + +#### Modularization and granularity + +While some of these integrations could technically be moved to a separate file, they are so small or "one off's" where splitting them off is superfluous. Now, lets assume that a blank file has been created in the Home Assistant configuration directory for each of the following: @@ -68,7 +89,7 @@ customize.yaml `automation.yaml` will hold all the automation integration details. `zone.yaml` will hold the zone integration details and so forth. These files can be called anything but giving them names that match their function will make things easier to keep track of. -Inside the base configuration file add the following entries: +Inside the base configuration file, add the following entries: ```yaml automation: !include automation.yaml @@ -78,9 +99,15 @@ switch: !include switch.yaml device_tracker: !include device_tracker.yaml ``` -Nesting `!include`s (having an `!include` within a file that is itself `!include`d) will also work. +#### Include statements and packages to split files -Some integrations support multiple top-level `!include`s, this includes integrations defining an IoT domain, e.g. `light`, `switch`, `sensor` as well as the `automation`, `script` and `template` integrations, if you give a different label to each one. Configuration for other integrations can instead be split up by using packages. To learn more about packages, see the [Packages](/docs/configuration/packages) page. +Nesting `!include` statements (having an `!include` within a file that is itself `!include`d) will also work. + +Some integrations support multiple top-level `!include` statements. This includes integrations defining an IoT domain. For example, `light`, `switch`, or `sensor`; as well as the `automation`, `script`, and `template` integrations, if you give a different label to each one. + +Configuration for other integrations can instead be split up by using packages. To learn more about packages, see the [Packages](/docs/configuration/packages) page. + +#### Top level keys Example of multiple top-level keys for the `light` platform. @@ -189,11 +216,11 @@ learn more about packages, see the [Packages](/docs/configuration/packages) page That about wraps it up. -If you have issues checkout `home-assistant.log` in the configuration directory as well as your indentations. If all else fails, head over to our [Discord chat server][discord] and ask away. +If you have issues, checkout `home-assistant.log` in the configuration directory as well as your indentations. If all else fails, head over to our [Discord chat server][discord] and ask away. ## Debugging configuration files -If you have many configuration files, Home Assistant provides a CLI that allows you to see how it interprets them, each installation type has its own section in the common-tasks about this: +If you have many configuration files, Home Assistant provides a CLI that allows you to see how it interprets them. Each installation type has its own section in the common-tasks about this: - [Operating System](/common-tasks/os/#configuration-check) - [Container](/common-tasks/container/#configuration-check) @@ -509,3 +536,8 @@ automation ui: !include automations.yaml ``` [discord]: https://discord.gg/c5DvZ4e + +## Related topics + +- [Example configuration files by the community](/examples/#example-configurationyaml) +- [Using packages to organize configuration files](/docs/configuration/packages) \ No newline at end of file diff --git a/source/_docs/energy/faq.markdown b/source/_docs/energy/faq.markdown index 25fce51be53..2cefbaf96ad 100644 --- a/source/_docs/energy/faq.markdown +++ b/source/_docs/energy/faq.markdown @@ -15,7 +15,7 @@ Think of this in a parallel to speed and distance: Power is the speed you are go Therefore Energy (kiloWatt-hour) is not an average of the Power you are consuming over a given period of time (the unit of the average power would be Watt or kiloWatt again). Energy is the integral (mathematical operation) of the Power function. -This difference is very important as you need to use the proper entities in our Energy Panel. +This difference is very important as you need to use the proper entities in our Energy dashboard. ## Creating an Energy Sensor out of a Power Sensor @@ -29,9 +29,9 @@ If you are using a 3rd party device (e.g. not reading directly from your utility To accomplish such, you can use the [utility_meter integration](/integrations/utility_meter/). With this integration, you define as many tariffs as required (in accordance with your utility provider contract) and HA will be able to differentiate energy consumptions in each of the tariffs. Please note that each utility provider has its own time schedules for peak and off-peak and you are required to create an automation that switches the utility_meter entity from one tariff to the other. -## The energy panel is not visible +## The energy dashboard is not visible -If you do not see the Energy panel in the sidebar, make sure you have not removed [`default_config:`](/integrations/default_config/) from your `configuration.yaml`. If you have, you will need to add the `energy:` integration manually. +If you do not see the Energy dashboard in the sidebar, make sure you have not removed [`default_config:`](/integrations/default_config/) from your `configuration.yaml`. If you have, you will need to add the `energy:` integration manually. ## Troubleshooting missing entities diff --git a/source/_includes/asides/dashboards_navigation.html b/source/_includes/asides/dashboards_navigation.html index 016aacfaf61..87e1eb85b3c 100644 --- a/source/_includes/asides/dashboards_navigation.html +++ b/source/_includes/asides/dashboards_navigation.html @@ -6,7 +6,7 @@