Lovelace: A method of splitting the configuration into several files

This is great I was doing a cpl of ugly work around to get attributes I wanted to display having templating available is huge for me thanks

Just remember that it’s the state at “compile” time. It won’t update dynamically.

This is a great facility. Unfortunately, it is not compatible with the Custom_Updater component and the tracker-card.

Yes it is. There’s a special clause in the updater to handle lovelace-gen

It does not work with the !resource statement, though.

Thank you, Thomas.

When using a generated ui-lovelace.yaml, my experience is that the Tracker-Card shows properly until either the “Check” or “Update All” button is pressed. After that, the Custom Cards disappear. I have tried replacing the generated resources section with the usual yaml, but I get the same result.

If I understand this correct, this is a way to make different sets of views? Like I describe in this tipic:

In that case, how do I do this manually without the script? And where is the lovelace folder?

No, sorry.
This tool is mainly for dividing the ui-lovelace.yaml file into more manageable parts. It doesn’t affect the interface.

There’s currently no way to do what you’re asking for, but you can kind of fake it using a combination of the lovelace kiosk script and using imges with navigation_path set.

You can also name a view " " (a single space inside quotes)…

I’m trying to make a header file that I will include in the top of all my views. The header has the weather-forecast in it as well as a couple of presence detection entities and some other entity cards relevant to each room. I can edit the ui-lovelace file and make it come out like I want, but I can’t seem to get the header.yaml file correct. Here is what it should look like. My presence tags are wrong, but that’s ok, it’s because of re-configuring owntracks and not part of this problem.

This is the ui-lovelace.yaml file that I modified to make it work.

views:
- cards:
  - cards:
    - cards:
      - entities:
        - {entity: device_tracker.turboc1208_cc1208, name: Chip}
        - {entity: device_tracker.scox1209_scox1209, name: Susan}
        title: Presence
        type: entities
      - type: weather-forecast
        entity: weather.dark_sky
      - entities:
        - sensor.date
        - sensor.time
        - {entity: sensor.master_temperature, name: Bedroom Temperature}
        - {entity: sensor.master_bath_sensor_temperature, name: Bathroom Temperature}
        - {entity: sensor.master_bath_sensor_relative_humidity, name: Bathroom Humidity}
        type: entities
      type: horizontal-stack
    - cards:
      - entities: [light.master_fan_level, light.master_light_level, light.master_floor_light_level,
          switch.master_cove_outlet_switch]
        title: Lights and  Fan
        type: entities
      - cards:
        - {entity: media_player.mbr_directv, name: Directv, type: media-control}
        - {entity: media_player.mbr_roku, name: Roku, type: media-control}
        type: vertical-stack
      type: horizontal-stack
    type: vertical-stack
  id: MBR
  panel: true
  title: Master BR

Here is what my MBR.yaml file looks like

- title: Master BR
  panel: true
  id: MBR
  cards:
  # The filter card will filter entities for their state
    - type: vertical-stack
      cards:
        - type: horizontal-stack
          cards:
            - !include header.yaml
            - type: entities
              entities:
                - sensor.date
                - sensor.time
                - entity: sensor.master_temperature
                  name: Bedroom Temperature
                - entity: sensor.master_bath_sensor_temperature
                  name: Bathroom Temperature
                - entity: sensor.master_bath_sensor_relative_humidity
                  name: Bathroom Humidity
        - type: horizontal-stack
          cards:
            - type: entities
              title: Lights and  Fan 
              entities:
                - light.master_fan_level
                - light.master_light_level
                - light.master_floor_light_level
                - switch.master_cove_outlet_switch
            - type: vertical-stack
              cards: 
                - type: media-control
                  entity: media_player.mbr_directv
                  name: Directv
                - type: media-control
                  entity: media_player.mbr_roku
                  name: Roku

And here is the header file that is giving me problems.

cards:
  type: entities
  title: Presence
  entities:
    - entity: device_tracker.turboc1208_cc1208
      name: Chip
    - entity: device_tracker.scox1209_scox1209
      name: Susan
  type: weather-forecast
  entity: weather.dark_sky

What am I doing wrong?

Try pasting it in manually and see what happens:
You’ll get:

- type: vertical-stack
  cards:
    - type: horizontal-stack
      cards:
        - cards:
            type: entities
            title: Presence

Doesn’t look quite right now, does it?

it’s the weather I’m having problems with when I run it through the converter.

I followed the installation instructions step by step but now I have the following problem:
python 3 is required but I dont know how to install it on my machine.
I use hass.io on a tinker board and I am currently using the IDE addon.

There’s a special section in the readme for usage on hass.io. Home Assistant itself runs on python3 so it’s definitely available, but a bit harder to get at in hass.io since it’s inside a container.

How would someone run this who is using docker for running HA? Is it the same procedure as for hassio?

And just to clarify my understanding of this if I decide to go this route instead of the standard !include statements…

in the lovelace directory (that I created in my config folder) I would create a main.yaml file with the similar structure as the existing ui-lovelace.yaml file but I use !include statements pointing to other files that will get compiled into the new ui-lovelace.yaml file when i run the generator command?

is there any benefit to running this compared to using the current built-in !include functionality?

It would be the same procedure as for hass.io, yes. I use that myself, running Home Assistant in docker.

Your understanding of the procedure is correct.

The main benefit isn’t really the include function anymore, since it’s been decided that functionality will stay in core indefinitely. Instead, I’d say the main benefits are the jinja templating and the !file statement.

In short, lovelace-gen isn’t as useful as it seemed it would become. Which is great!

1 Like

Also, see this topic for more recent updates and discussion.

Hi. Trying to get lovelace-gen up and running but i keep getting the following error with python3



What am i doing wrong?

You’re using a version of python 3 (3.5) that’s more than two years old. However, that version is supported by Home Assistant, so I should change lovelace-gen to work with it as well… Expect an update in the next few days.

Thanks. :slight_smile:

It’s updated now. The new version should work in python 3.5.3.

Hi @thomasloven

I’ve added

anchors:
  mystyle: &mystyle
    card:
       ....styling....

to one of my includes but after generation in ui-lovelace.yaml there is only

anchors:
  mystyle:
    card:
       ....styling....

left. I’ve got generation errors, I thought because the reference (&mystyle) is missing.

Example reference:

- type: custom:button-card
  entitiy: switch.dummy
  styles:
      <<: *mystyle

If I add the parts to ui-lovelace.yaml manually it works like a charm.

Is it possible to use anchors with the generation script?