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.
I’m allright with this reasoning, but no mechanism has been put into place which replaces the functionality which was lost.
YAML was the one and only means of configuring things, so I wasn’t making any decisions at all for my users. They used the one way to configure things, and then I added elements to their setup through packages. Nice and easy, and nobody had to change how their setup was configured.
All of these things are great, for users who have elected to use YAML. What of everyone else?
The “view” component is specifically what we’re talking about here. This allowed one to drop a package which would have all of the HASP-related components shown in one place, and would create one for every device a user deployed. It’s this loss of functionality specifically that is a problem.
I don’t know.
you haven’t posted any real code that was used in the old states ui that was specifically for the frontend so no one can see what might be an alternative in lovelace using GUI mode.
Another thing I don’t know if you realize is that you can edit the GUI created files in raw mode and then paste blocks of yaml into it. That might be the alternative that your users who use GUI mode can use to get the same functionality.
granted, it’s not quite as easy (maybe…) as dropping a folder into your packages directory or using !includes in yaml mode but it might work.
1 Like
The top of the thread explains a bit about how all of this goes together but here’s the condensed version:
This is the specific YAML that’s pulling together the groups created in various places into a single view.
This is the script that makes the required configuration changes. This script works for all users, regardless of how they have configured their existing system. It is run once for every device deployed, so a single user may have to execute it several times if they have several touchscreens.
The result is that each device deployed gets its own view in its own tab, all of which is auto-created for the user and which works on all installations. It looks like this with one device deployed:
edit: on a personal note, thanks for looking into this with me @finity!
OK, just to make sure I understand what’s going on…
your script creates the package that contains all of the pieces parts that work with one individual switch plate?
it also creates a group in that same package that creates a view that then gets all of those pieces parts included in groups in the single view?
is there some “magic” that happens in the switch plate where it needs to have all of that stuff in a single view or is that just for the convenience of the end user?
The reason I ask is if it’s just a user convenience and the switch plates doesn’t have to use that view in some way then in your script you could output the members of those groups into a text file in the lovelace view format (including the code for required entities cards) that a user can then decide if they want to directly paste the contents of the file in the GUI generated raw file or put the contents in an !include statement in ui-lovelace.yaml if they use yaml mode.
It seems to me (at first read) that the rest of that script should still work exactly like it did before.
I think… 
Your understanding is correct, the only element we’re concerned about here is the creation of the view element. I’ve been trying (and thus far have been successful) to prevent forcing the user into making manual configuration changes in a text editor but this might be where that has to end.
Is there any way to interact w/ the Lovelace GUI editor via service calls? Like, could I issue a call to create a view?
As far as I know that’s not possible.
In the grand scheme of HA I don’t think it’s too onerous of an ask to have to manually edit a single text file.
I really don’t understand why you can’t use the same stuff. Group is not gone, just the view attribute. Just add a identifier to a main group entity_id and you have the exact same functionality, but you aren’t using the view field. I have no idea why you’re making such a big deal out of this when you could have spent less time coming up with a simple solution instead of arguing for GUI interface changes for something that happens on the back end. Just an FYI, all software packages are decoupling the back-end from the front-end. It just makes sense. It makes it so you can replace the front-end whenever you want with whatever you want. This gives the ability to go on any platform. Your code should act the same way.
The steps I would take:
- Create version where an update occurs. This will update old configurations to new configurations, I.E. remove the
viewfield from groups and add it to theentity_id. - Update your objects to populate your existing ‘view’ property based on the group’s name, but this property is only in your project/integration/whatever you do.
If your code was build well, there would be nothing else to change.
The code is embedded into my user’s existing configuration files. Every user of the project is going to be faced with a broken config when 107 drops. This is why I’m making a “big deal” about it.
I did it this way because that is the supported way to enable Views using the States UI. I don’t feel like that was a matter of sloppy practices on my behalf. It was, and is, the way you create a view using States.
I get the argument for de-coupling the UI, all I’m trying to do here is to figure out a way forward that works for all users. The way it has been de-coupled appears to create two fundamentally incompatible configurations. This isn’t a necessary feature of decoupling the front-end from the back-end, but it is the way Home Assistant has elected to move forward. I’m left trying to deal with the result.
So have your users go in and add _view to plate{n} groups and remove the view: true field. Update your code to look for _view. I still don’t see the problem. If users don’t want to do this, they don’t update. This change will take 20 min tops. And not to mention, you can build a utility for people that do this, if you really wanted to.
I’m working on a bash script to handle this right now, at a bare minimum I need a way to deal with existing configurations such that we can remove any deprecated statements so we don’t hang Hass on reload.
Left unsolved is a universal approach to programatically add a view to a Lovelace user’s configuration, regardless if they’re using the UI or YAML.
So, I see you keep getting stuck on using the UI elements. Are you using the HTML from the ‘groups’ to create the interface in your system? Is this the hang up?
EDIT: You must be, so you must be serving the ip/states/plate{n} page to your utility.
The way things work today is that the user runs a bash script, it asks them for a device name, and it then deploys a package for the individual device. That package contains a bunch of YAMLs, which should still be fine, but one of those YAMLs includes a view which will be deprecated on 107.
Users who have a bunch of HASP devices will have several such files, each in their own package folder. I think I can grep and sed my way through modifying their existing packages to remove the view such that Hass won’t fail to load due to the deprecated config calls. So, on that side I think your suggestion above is actionable.
What’s left is how to give them that view back in a way that is easiest for the user to execute and provides the broadest support for their existing configurations. The way Lovelace has been implemented means that there are two, fundamentally incompatible ways that they might be configuring their environment today. I prefer not to force them to change from one to the other, so I need to accommodate adding a view (or something similar) to either approach with as little friction as possible.