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.
ui-lovelace.yaml
views:
- !include path_to_auto_generated_package_file_for_view
your auto generated package file:
id: plate01
badges:
- sensor.plate01_xxx
cards:
- type: entities
title: plate01 Page Selection
entities:
- 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 
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.
No.
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.
@finity The problem here is that it’s not my decision to make. I developed and support this OSHW project which allows users to deploy Hass-integrated touchscreens around their house. Packages are used so that they can very easily deploy one or several of these devices without editing their base configuration. I don’t get to decide for them if they are using YAML or the UI - presumably, their existing installation already uses one or the other, and so if I push YAML on them, then I break half of my user’s installations.
On my own, I’m comfortable using whatever, I don’t care if it’s YAML or UI. The people using my own project have made their own decision, and the way things are currently setup I don’t see a clear path toward supporting them in a transparent manner, without forcing them into using a configuration style they may not be comfortable with.
At least with that extra information I now sort of understand where you are coming from.
However…
I still don’t think that using packages with lovelace is the answer for at least a couple of reasons.
the first and foremost is that packages can’t be used with lovelace because packages interact with the backend. Lovelace configures the frontend. the two aren’t supposed to overlap at all. Which is the reason the switch to lovelace was made in the first place - to disconnect the backend from the frontend. So lovelace packages won’t happen as far as I understand things.
Second, you already made a decision to configure the frontend using yaml when you created the frontend config using group views/card in packages…which used yaml…
I see no difference between “enforcing” a decision for your users to use lovelace in yaml mode and forcing your users to use the older states ui which by default always used yaml mode.
At least now the users have the opportunity to get the benefits of the newer, more flexible UI. Even if they are still “required” to use lovelace in yaml mode.
As I said, I use lovelace in yaml mode and I don’t think I’m “deprived” in any way of the functionality of using lovelace in that way at all.
And, again, since you can use !include statements in your lovelace in yaml mode it makes it dirt easy to drop a new yaml file that contains an entire view into a designated folder (that you decide where it goes) and add a single line to the ui-lovelace file to include that lovelace view into your frontend.
Obviously I don’t know exactly how your project works but I can’t see how you couldn’t rework a lovelace view to work with it.
Maybe I’m completely wrong tho.
The other thing is that I don’t get is why you can’t still use packages in some way to do what you want.
The old states ui just used groups that you manually created to create the ui. You can still create those same groups in those same packages right now. The only thing you are losing is the “view:” option of the groups.
Maybe if you posted what you think might be limiting your ability to do what you used to do with the states ui then maybe someone might be able to help you figure out an alternative way to accomplish the same thing.
The states UI allowed one to use packages, and there was only one way for users to configure it (yaml), so using one set of packages allows the project to cover 100% of the users. I didn’t make any decision for my users, I used the one way things got done and it worked because states UI has a single configuration mechanism and that mechanism supports packages.
Then Lovelace comes along and neither of those statements are true. It has two, fundamentally incompatible modes of configuration, and neither mode supports packages. I noticed this a year ago, which is why I posted this feature request in order to bring visibility to this issue.
Now, a year later, Lovelace is being enforced on the user community with no clear path as how to handle a situation like this. Packages still aren’t supported, and we still don’t have a standard way to add UI elements that works across the userbase.