Currently, the auto-update mechanism in the HASP project has each device checking for an update once a day. In the last 24 hours 617 devices have requested to the update file. That’s 617 configurations that will be broken as a result of this change.
To figure out which configuration approach my userbase is using for Lovelace, I posted a poll this morning. So far the results look like this:
“Still using states UI” is a user that is currently using YAML. This means the userbase is exactly split down the middle, one half is using the UI, the other half is using YAML (whether they know it or not).
Personally, I’d create the yaml for them in a text file and have them paste it where they need. If they even need this. They just specify if they use yaml more or the UI editor.
If yaml mode:
create a single file, with the entire view.
If UI mode:
Paste each entities card into a separate file.
If you’re feeling extra motivated, you can attempt to write directly to the lovelace json files in the hidden .storage folder. EDIT: I don’t know if this will work. Depends on the read/write process for lovelace config.
It looks like your user base (at least those that replied to the poll) has potentially already moved on without you. You are still focusing on how to make lovelace conform to the old way of using the states UI. But your users are already using lovelace (in both GUI & yaml mode). Which isn’t really surprising since lovelace has been the default UI for a really long time now. So apparently your concern about which path to take is moot.
Oh for sure, we’re all running Lovelve w/ HASP but that’s because states still works. We can have the UI elements distributed via packages today and it works fine. That’s the problem we’re facing, everything works with Lovelace today but it won’t come version 107.
The complaint that you were stating above was that lovelace doesn’t allow you to automatically create a view from the groups that you dynamically created.
Even if the states UI still works right now, if you are using lovelace as your UI then the “groups:->view:” option doesn’t do anything at all. Lovelace completely ignores that option because lovelace doesn’t use groups to create the UI like the states UI does.
So now I’m even more unsure of what you are using the “view:” option to accomplish in the UI or why you still need it in your config.
OK, so let’s try a different tack…
If you manually create a group and include the “view: true” option then what changes in your UI when using lovelace?
It only works because of one of two things: either the user manually switches over to states view in order to interact with HASP (it’s not an every-day thing, so this is OK), or they had the existing states views automatically imported when they first enabled Lovelace.
It’s not ideal but for the moment it works. It won’t come 107.
Do you really think that most of your users are still using HASP in that manner?
Or do you think it’s more likely that most of your users have switched the the old HASP states view into a regular lovelace view and aren’t even using the states UI view any longer.
According to users on Discord it’s one of the two options above, or that they’ve manually created their own views. Manually creating their own is just fine, and I think is the best end-state for the sorts of users that build this project, but I also need to “ship” with a reasonable default.
HASP is cool because, while a pretty complex project, it comes out of the box with a bunch of functionality that allows you to get the device running with very little initial configuration. There’s a lot of complexity to deal with once you dig into it, but with the existing deployment scripts getting the device powered up and connected to Hass is straightforward. I’m pushing to try and keep things this way, which is why I’m drilling into this specific issue.
It’d be easiest for me to say “fuck it, learn to Lovelace you dopes” and leave it at that, but if there is a way for me to make that first step easier by having something reasonable presented to them without their intervention, I’m going to do that.
It’s a design principle of the project, and I intend to continue operating in this manner.
I really do appreciate the input and I think your idea of generating the YAML and providing the user with guidance on what to do with it is where I’ll be going with this. Thanks @finity!
