Lovelace and packages

I’ve been making extensive use of Home Assistant packages for convenient distribution of the necessary components required for the HASwitchPlate project.

The way HASP works is that for each physical HASP device, a set of components are deployed including input_sliders, input_text, a whole pile of automations, several groups, and a view. I created a script which will pull down a copy of the package, rename everything to match the selected HASP device name, and deploy it into the user’s Home Assistant folder structure. This keeps everything nicely compartmentalized and the only modification required to the user’s main configuration.yaml is to confirm that there is a call to include the ./packages folder. Users can add and delete the folders as needed and the components/views/etc are created/deleted automatically.

Now however we have Lovelace, and it works quite a bit differently. The standard UI approach puts everything into a single file, and I don’t see any means of using packages against that file. An alternative is to force the user to transition to yaml, but that also doesn’t appear to support packages (or maybe I’m doing it wrong), meaning once again the user now needs to individually maintain the entries in the file every time they add/remove a HASP device.

Am I missing something here? Is there an approach to using packages with Lovelace? If so, does anyone have a repo somewhere where this is done so I can take a look at a functioning example?


I’ve been using yaml mode for lovelace and after a bit of learning I find it easier to use the UI…but lovelace yaml is not supported in package files :-(. Based on my experience coding with nodejs I suppose it won’t be to big a deal for lovelace code to scan the package directory files and pull any lovelace: keyed yaml objects with those found in the ui-lovelace.yaml file. I really really like the organization of packages not only for myself for but sharing. Lovelace yaml not supported there breaks that “bundling”. I suppose @ynot @luma that we just need to submit a request at github. At least it will be considered.

In the meantime I’ll keep a commented copy of the lovelace.yaml applicable for that package within the package file for reference and when I share.

It will never work because Lovelace is 100% separate from HA’s backend. HA’s backend loads the config at a different time then lovelace. Lovelace can also reload without restarting. If we actually found a way to make it work with packages, it wouldn’t retain this behavior.

Packages don’t work with reloads in the existing Hass codebase, so I think those working with packages today wouldn’t be too fussed about that at all.

I would agree. Looking for a simple way to distribute the Lovelace front-end as part of the package, I could live without reload without re-start.

It still doesn’t make sense because you’d need to place the cards into views. I think you guys have this pipe dream and aren’t thinking about the whole picture. Yeah you could have it split into a package, but you’d still need to have those configurations in different files. This isn’t the same as a configuration for the devices. Home assistant isn’t just going to know that a package is placed on page 3. And what happens when you want to combine 2 packages cards?

Lastly, you can basically do this with includes… Just place the file into the package directory and include it.

1 Like

For me, the major issue is being able to redistribute in such a way that the end user doesn’t need to manually edit their own configuration. What I’m trying to accomplish is this, except with lovelace configurations. @petro - Do you see any way to make that happen via includes, without prior knowledge of the user’s individual configuration?

Can you explain what that github does? The documentation for it doesn’t really explain it well.

Sure! I made a thing called the HASwitchPlate. Using it requires a bunch of things from Hass. It needs MQTT enabled and configured, it needs recorder to be turned on, it needs a handful of input_number, input_text, several groups, a custom view, an iframe for device management, and it also needs 60+ automations. All of these are required for every HASP deployed, so asking the user to create 80-some odd configuration changes for every device they install is a bit much.

So, we use packages. This way I can bundle the 80-ish configurations into a set of files all in a single folder. The script is checking to see if your configuration.yaml contains a packages: statement, and if it’s missing, it adds it. The end result is that the user can run a shell script, type in the name of their device, and all the changes are made for them through packages.

What I’d like is some means to make the same thing happen for Lovelace. I have hundreds of users, each with their own unique configuration. I’m trying to come up with a way that allows me to add items to their configuration in a generic manner, while requiring little (preferably, zero) manual intervention on their side.

Packages make this simple, and all the UI elements I need are included with those packages. The user runs a script, then they have a view with everything they need to use and interact with the device.

Any thoughts on how one might make the same thing happen w/ Lovelace?

Oof, I’m not sure how that would work with lovelace. What would you expect to happen with lovelace? I would think you could skip lovelace all together if I understand correctly. The thing about lovelace is, that you’re not configuring much when it comes to placing it in the interface unless you have a crazy interface. Even then, it’s one line or 4 lines (for a service call). At that level you can’t use an include. You can include an entire card which typically contains multiple entities. That’s also hit or miss because some cards only accept 1 entity. This is why I personally don’t see this 1 to 1 relationship with a package. For example my media player and harmony remote would be separate packages. But in Lovelace, the 2 are intertwined because I want a single UI ‘remote’ that controls it all.

Here’s an example of how this thing looks after deployment, along with all the UI elements being added:

The iframe on the left, the view itself, and the various controls shown (except maybe the automations) are all UI pieces the user may need to interact with. This is all very easy to deploy via packages with the states view.

Is there any reason to think Lovelace be able to do this without packages?

Oh ok, yeah, then your view would be a package item. So you’d treat each view as the packaged ui. It would have to be a separate file and you’d include the view file at each bullet.

You’re users would need to manage ui-lovelace.yaml and add the includes. Or you could attempt to do it, but if you’d want to be careful not to overwrite what thtey want in the thier pages outside the your stuff.


- !include path_to_auto_generated_package_file_for_view

your auto generated package file:

  id: plate01
    - sensor.plate01_xxx
    - type: entities
      title: plate01 Page Selection
        - sensor.plate01
        - etc.
1 Like

Fantastic, that is super helpful @petro! It’s going to be a bit before I can dig into this but it’s been a problem for me since Lovelace became the default UI and being able to address this in a useable way will be a big win for HASP users. Thanks!

1 Like

Reading the yaml files from the packages directory wouldn’t affect what the backend is doing and the lovelace code obviously can access the config directory (since it ready uilovelace) so I assume the packages subdirectory as well. Like I mentioned, in nodejs at least, one could read a yaml file in the packages directory (one by one) into a an object then then look for a lovelace: key in that object and than merge that key’s hash using Object.assign into the main object created from ui-lovelace.yaml. As to exactly how to merge that is an issue. I’d suggest each lovelace: key be it’s own view in the main lovelace object. This to avoid namespace/merge issues. Maybe for users sake a hidden: can be added that will not render/merge the view if desired. The title and icon not need be unique so that is not an issue although if no title: is provided it could use the name of the yaml file for clarity.

When done with all the yaml files in the packages directory the lovelace code could continue on as before. Assuming that there would only be a handful of yaml files in the packages directory this shouldn’t delay much the rerender of the front end.

Since I don’t program in python I have little idea how python stores hash objects from yaml/json and manipulates them. It has to be similar. I’m just saying in nodejs this would not be an impossible nor difficult task nor would it affect nor depend on any other backend code. I’d love to do a PR but don’t have time currently to become a python ninja :frowning: I did look around for an open source home automation system that used nodejs in the backend but lack of such had me settle on HA.

Thanks for this. Will try to put something like that together later in the Fall. Looks like a simple enough approach.

Well now that Lovelace is mandatory and all projects using States are going to be completely broken, I guess it’s time to see if we can’t somehow make packages work now.

I’m not really sure how states ui being deprecated produces a mandatory need for lovelace to use packages?

I’m not sure if you know it or not but you can already use !include statements in lovelace yaml mode to split your config up.

and if you aren’t using yaml mode then packages would be totally useless for you anyway since the ui is not using any yaml files at all in that case.

Edit: case…

These guys still don’t understand the pitfalls that come along with this. It will just make lovelace more complicated.

1 Like

The goal is a drop-in module that includes UI elements without requiring the end user to make manual changes to their config. Packages include the ability to do this via the states UI, such that one can simply drop a folder into their installation and everything comes with it automatically.

From my understanding, the solutions proposed thus far all require editing the existing configuration which brings with it a lot of opportunity for errors.

Edit: can one mix yaml mode and UI mode? From what I’m seeing it appears not. If not, now I have the extra problem in that there are two fundamentally incompatible ways to add UI elements to a users config.

Yeah, I’m still not getting it.

When you were using the states UI you still needed to create groups that you defined as views, then other groups that showed up as what we now think of as “cards” in lovelace.

All of that was done using yaml.

I’m not sure how having “everything comes with it automatically” helps in manually creating groups as views & cards.

Did you not ever modify your states UI manually and just always relied on HA to auto-generate a default config? Otherwise I don’t see where it’s that much different now.

You can still do that now and HA will generate a somewhat default page for you.


Just pick one.

Since you are comfortable with the states UI being configured thru yaml files (if that’s what you did) then just use lovelace in yaml mode. It works great and it’s how I configure mine right now.