A thought that may or may not belong in this thread.
We are now in 2022, and it is pretty clear that Yaml has died, or maybe on life support for a few more months.
My biggest issue, as it turned out, was not that I can’t easily store my config in git.
It is rather the case that most UI-integrations cannot change, once they are configured.
Lets say I need to do a routine change of a API-key or password
Integrations need to be deleted, and added again. And there is usually no way to se the current config, so you have to remember all the other parameters configured, just to change one of them.
Most times that works semlesly, but I have hade countless issues when all my entities are assigned new ID’s after reconfiguration.
And any id-configuration is guaranteed to be lost.
I soon want to change hostname of my Deconz install, but that means that over 100 entities will have to be renamed, by clicking them one by one.
Is this whole “configure once and never change” an intended practice? Or is it just that developers chose to do it that way?
It kind of turns the whole Home Assistent experience into a house of cards. An ever increasing fear of changing just any device at home, in fear that it would mess with Home Assistans precious working state.
Yes, we have backups. But backups is for data, not configuration.
If the integration in question doesn’t give you the option to reconfigure the endpoint, add a #feature-requests for it. Also, you can edit any configuration in the .storage folder to change the endpoint for the integrations that don’t offer it. Just make sure home assistant is off when you edit it.
If you have discovery enabled and change host name of deconz it should be updated automatically. If it doesn’t you can start a new config flow for deconz integration and it should update the adress of your existing integration.
There is no “the integration”, it applies to all of the ones i am using (the ones that has a config flow). That’s why I am wondering if it is by design, if it has to be that way, or just happens to be by choice for the ones I am using.
That last part is interesting.
A year ago, someone would often suggest modifying .storage, but then the mods and more experienced users would urge to ignore that advice, and never touch .storage.
Has that bad practice become a necessary evil now?
Then you must not see the … or the configure button? Secondly, most integrations can be reintegrated by just adding it again and it will replace the current integration.
You can always modify the .storage files. I do it all the time. Just don’t expect help if you break it. It’s pretty simple to do if you understand json. Lastly, we all urge people not to modify the files because most people don’t understand json.
One of my integrations. No, you are correct, I do not see the configuration button. Should I file a bug report to my monitor vendor?
There is no way to “not understand json”, that is not what avoiding .storage is about.
It’s a place that lacks fail-checks, because all data there is expected to already be fail-checked.
Modifying that is as sound as patching a running docker container, except that the docker container can be recovered.
I use the octopi integration and can confirm, I had to remove it and readd it to reconfigure the host.
It wasn’t hard, but still annoying, I may look into doing a PR to add a configure for it, if someone doesn’t beat me to it.
Doing the editing in storage myself too, quite often indeed, I feel we still should express a fair warning not to.
It s not just an issue of understanding Json and it’s syntax. That’s the easy part.
Most of all, there are huge cross related dependencies between the storage files. If you forget one, or simply didn’t realize those exist, your chances of breaking things are high.
The id’s that hold these dependencies are easy for a computer but very hard for users….
Had a really weird case the other day of an integration (yaml config) no longer providing data for a sensor and I was using a template sensor as well to make it prettier. Anyway when I deleted the sensr and template sensor the template one I could not delete no matter what I did. Searching all .storage files and I could not find it and could not delete from entities.
Ended up duplicating one of the working templates and then deleeting it and it was gone. Really weird issue. Generally .storage is performing really well these days and works well
I agree. It generally works fine. Until it doesn’t… Then you have no easy way to figure out where that entity is being regenerated.
It’s happened to me too just recently a couple of times. I searched every config file and *_registry file and never found anything. Ultimately I never did actually figure out where those entities were coming from. It seems that eventually I just restarted HA enough times that whatever it was fixed itself. It was a frustrating couple of hours of time trying to figure it out with no real satisfying resolution in the end. It worked but I have no idea why it wasn’t and then why it did.
I’m starting to see more of those questions being asked on the forums lately too so it seems to happening more often. Again not sure why tho.
Could YAML really go away? I use packages extensively to group different entity types together to be able to keep my head around, what I think is, a complex setup. I don’t use the UI for anything except one dashboard (and then I use the raw config editor ) I get the replacement of YAML config for integrations but are we also talking about all the other YAML stuff as well (groups, automations, templates etc)
Please, do not remove yaml, it is needed for ChatGPT, moreover, in future products related to HA, you need to come up with some kind of analogue of the open source automation format, configuring on, using YAML
) I get the replacement of YAML config for integrations but are we also talking about all the other YAML stuff as well (groups, automations, templates etc)