Lovelace yaml with split directory does not work

hhaim · March 16, 2019, 8:36pm

I’m using this modular way to include a components (which is great)
packages: !include_dir_named pkgs

Until now I’ve used group which worked with lovelace (there was an automatic translation)
Once I’ve moved to native lovelace (using yaml), adding “view” to each component does no work any more. (Lovelace looks only into a the global file called config/lui-ovelace)
Is it possible to have lovelace to work like group work in a modular way?

the full example of my configuration file can be seen here

github.com

hhaim/hass/blob/master/configuration.yaml

homeassistant:
  # Name of the location where Home Assistant is running
  name: Home
  # Location required to calculate the time the sun rises and sets
  latitude: !secret accurate_latitude
  longitude: !secret accurate_longitude

  # Impacts weather/sunrise data (altitude above sea level in meters)
  elevation: 43
  # metric for Metric, imperial for Imperial
  unit_system: metric
  # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
  time_zone: Asia/Jerusalem
  # Customization file
  auth_providers:
      - type: homeassistant
      - type: legacy_api_password
        api_password: !secret http_password
  customize: !include customize.yaml

This file has been truncated. show original

finity · March 16, 2019, 8:48pm

yes you can use !includes to split your lovelace config using yaml mode. Which is the biggest benefit there is to using yaml mode.

Here is my ui-lovelace.yaml file contents:

resources:
 
  ## https://github.com/atomic7777/atomic_calendar
  - url: /customcards/lovelace/atomic-calendar.js
    type: module
  
  ## https://github.com/gadgetchnnel/lovelace-home-feed-card  
  - url: /local/lovelace/home-feed-card.js
    type: js
  
  ## https://github.com/custom-cards/config-template-card  
  - url: /local/lovelace/config-template-card.js
    type: module
    
title: Docker - Lovelace
views:
  - !include '/config/lovelace_views/lovelace_main_view.yaml'
  - !include '/config/lovelace_views/lovelace_media_view.yaml'
  - !include '/config/lovelace_views/lovelace_environment_view.yaml'
  - !include '/config/lovelace_views/lovelace_automations_view.yaml'
  - !include '/config/lovelace_views/lovelace_system_view.yaml'
  - !include '/config/lovelace_views/lovelace_zwave_view.yaml'
  - !include '/config/lovelace_views/lovelace_security_view.yaml'

then in my config directory I have the following files:

and here is an example of the contents of my lovelace_media_view.yaml:

title: Media Players
cards:
  - type: entities
    #title: Garage
    show_header_toggle: false
    entities:
      - sensor.last_alexa
  - type: media-control
    entity: media_player.chromecastaudio1984
  #- type: media-control
  #  entity: media_player.bdps6700
  - type: media-control
    entity: media_player.computer_room_dot
  - type: media-control
    entity: media_player.kitchen_dot
  - type: media-control
    entity: media_player.livingroom_dot
  - type: media-control
    entity: media_player.master_bedroom_dot
  - type: media-control
    entity: media_player.garage_dot
  - type: media-control
    entity: media_player.big_room_dot

Each view I defined above gives me a tab just like defining a group as a “view” in the old ui.

But just to clarify…your groups that you defined as views are useless now since lovelace uses it’s own config files and ignores the “view: true” in groups.

lolouk44 · March 16, 2019, 8:49pm

As far as I know it’s not possible to break ui-lovelace like for components, but would love to be proven wrong.
Also please check my DM

finity · March 16, 2019, 8:54pm

Challenge accepted!

See my post above. It only works if you are using lovelace in yaml mode.

hhaim · March 16, 2019, 9:03pm

@finity this is not exactly what I’m looking for.
I think @lolouk44 understand my point and my understanding that it is not possible.
The point is to add the “view” folders into each of the components which does not work like other yaml
and not to have another split of view

Mariusthvdb · March 16, 2019, 9:09pm

though I am with @finity here and use includes for most anything in yaml mode Lovelace, I am willing to take your challenge it would be an option for what you want. The thing is I am completely in the dark what that would be… talking about components confuses me somewhat. What exactly are you trying to realize? Please expand on that further, so we can help (if possible of course)

finity · March 16, 2019, 9:11pm

I agree. I guess I’m missing the point of what you want as well.

lolouk44 · March 16, 2019, 9:19pm

I was on the same point/train of thought as @finity sorry…

hhaim · March 16, 2019, 9:33pm

Ok, sorry for not being clear
Let me give an example what works (for groups) and does not work for lovelace view

In my configuration file I have this lines
"
packages: !include_dir_named pkgs
"

This line force the configuration file to read the yamls files from pkgs folder
Each file includes every aspect this component (sensors, custom, group view etc)
I call each file a component because it is a self contained element

In my case, let’s look at one example

pkgs/boler.yaml

It includes

"group: "

and

“sensor:”

see this

github.com

hhaim/hass/blob/master/pkgs/bolier.yaml

homeassistant:
  customize:
    switch.b0:
      friendly_name: Boiler
      icon: mdi:shower
    
    sensor.btemp0:
      friendly_name: Boiler Temperator 
      icon: mdi:oil-temperature

group: 

  bolier_group:
    name: Boiler
    entities:
      - sensor.btemp0
      - switch.b0
      - input_boolean.boiler_auto_enable
      - input_number.boiler_timer_time
      - input_number.boiler_temp_min

This file has been truncated. show original

I would like to add to bolier.yaml

The section of view from this one

github.com

hhaim/hass/blob/master/ui-lovelace.yaml

#title: My Awesome Home
# Include external resources
#resources:
#  - url: /local/my-custom-card.js
#    type: js
#  - url: /local/my-webfont.css
#    type: css

# Optional background for all views. Check https://developer.mozilla.org/en-US/docs/Web/CSS/background for more examples.
background: center / cover no-repeat url("/background.png") fixed
# Exclude entities from "Unused entities" view
#excluded_entities:
#  - weblink.router
views:
    # View tab title.
  - title: Home
    # Optional unique id for direct access /lovelace/${id}
    id: main
    # Optional background (overwrites the global background).
    background: radial-gradient(crimson, skyblue)

This file has been truncated. show original

Like this:

views:
cards:
- title: Boiler
…

but it does not work

hhaim · March 16, 2019, 9:40pm

It make it even more clear, this is the diff that does not work

Mariusthvdb · March 16, 2019, 9:45pm

The packages do still work, and are very useful. Its the group: that isn’t used in Lovelaceany longer.

Lovelace needs a paradigm shift…
So start using views with !includes for most anything and forget about groups. (I still have them in my packages because I also use non_lovelace)

the View should be declared in a !included view file, as @finity showed you, and not as part of a package. It is the starter for Lovelace, referenced in ui-lovelace.yaml. The main advantage in my use case is that that file is hot-plugged…you can change it and it will show immediately after a refresh. That won’t work when using packages (I think, have never tried it), if declaring views in packages would work at all that is.

hhaim · March 17, 2019, 7:24am

Thanks you for your prompt response.

What I would like to have is that the “packages” model would be integrated into lovelace in the same way.

I would like to add this line to lovelace yaml

packages: !include_dir_named pkgs

and view and group (old) will be taken from the same file.

This way copy a single file (component) will copy all the information about this component (this was all the point in packages model)

It seems that Lovelace works differently (in a good way, e.g. Not require restart for example) but I would really like the full integration and not to have a separate file for Lovelace and original yaml
Do you think that it worth a feature request?

thanks
Hanoh

finity · March 17, 2019, 5:14pm

Not really.

There was a lot of effort to go away from the functionality you are asking to restore. I seriously doubt it would be reinstated.

metbril · June 29, 2019, 11:30am

The whole idea behind Lovelace is/was to separate the front end / presentation from the back end / entities definition logic. You’re basically asking to revert that design decision.

hhaim · June 29, 2019, 6:03pm

Not necessarily, I am looking at this from a different angle (user not developer). You can keep the implementation separation. I’m suggesting to add a Lovelace section in each YAML file. This way each logical section could have all the definitions needed for a component point of view. This is exactly the point in the package design which is a good thing and ignored by the Lovelace dev team.