Nope. don’t have Netflix, never will, not any other S… ( i have 4 “open-air” channels, default country free air channels picked with a basic antenna on the roof, and my Fiber is only for the Internet )
Im Fully aware of this, as i worked as system-administrator for about 15years … and had a hell with the management at 1 place when i incorporated monthly change of passwords ( in a development company, with patented software )
But we can agree that we disagree, to maybe 50%, and as this is a “Release Blog Post” i guess we should leave it there, so people can report their “problems” and get feedback, but ofcause also their “opinions” in short … and yes i have also always “checked my code”, but if it works “with a click” and im maybe even able(in some cases to modify) Makes life so much more easier ( which btw also “automation” is all about)… Sitting and writing code have never been anything that Triggers me, so for me it’s basically a “need to do” in some cases
Sorry to hear that HA, as you know it, is running away from you, and if it leads to less options for you, i do however think that “auto-rotation”( not really a good term/approach ), as you say “no-reuse” of password, can in a corporate network be implemented in various ways and levels
I 100% agree. This is a discussion about a statement made in this Release Post.
I want to take focus on what user-friendly vs. newcommer-friendly is.
Because as demonstrated: it is not the same! And the current HA way is to go “newcommer-friendly” which has already taken affect on “user-friendly”.
This even continues to the changes in wordings made with this post!
We currently have a delta in what the new wording says vs what the docs and actual tool says.
This is neither newcommer-friendly nor user-friendly.
I will find a new way to get my password-rotation working again.
I will find ways to get features which were never intented by the devs.
HomeAssistant is OpenSource and extendable by default afterall.
It’s just about the way which we all are about to go.
Yeah but you are clearly happy to write scripts.
So all you really have to do - is to change the password that component is using, in the JSON file in the /config/.storage directory. It’s a little bit more work for you to do, but it’s still absolutely possible.
I am very happy to write scripts.
I just don’t want to reinvent the wheel.
Home Assistant has a very suitable way to manage secrets in a dedicated centralized file and reference them throughout. It had a way to configure everything via organized files. It is not like i am asking to implement something new. Abstraction that were already in place allowed for an easy convenient way to mange them. If i wanted to add a new service to my password-rotation all i had to do, was tag that entry in my password manager and reference the secrets.
Done.
Now i have to lookup the domain of that service (most of them are plainly named, fair enough) or in some cases the specific entry_id if i have multiple of said domains.
Anyway, i’d have to manage a additional config-file for my script in order to find the correct mappings.
Having config-files to manage config-files seems a bit unnecessary.
This is by far not as convenient or use-friendly albeit still doable.
Clearly the previous implementation was more user-friendly as Home Assistant itself allowed for the correct mappings of secrets and config.
My Point is not “urgh they have no way to rotate secrets automatically”.
My Point is that the migration to UI managed configuration is not as useable as they make it to be.
It is only more newcommer-friendly. There is still important functionallity missing in the UI. An example of that is the ability to simply reset the passwords. Whats the point of having a newcommer getting frustrated because they forgot the password to a certain service and thus changing it, only to then find out HomeAssistant does not offer an option to reset the password!
Would you think that a newcommer looks in the storage folder in some json-file?
Is it even documented, that this is a possible workaround?
Spoiler: the answer is no.
Edit: in case of this thread it would rather be that dashboards are now called dashboards but the documentation and app itself still reference lovelace.
considering what you’re saying here, and trying to make that mindbend (since we where told for a long time to use MariaDB or some other external DB so have a better , faster and more reliable DB which would be nicer to the SD…)
What would be the decisive factor for this currently? In my setup, running a RPi4 with an SSD (and all data on that SSD), and a heavily curated recorder (included/excluded entities), I’d love the setup to be as simple as can be. So, going back to core SQLite seems attractive?
If going back to that, can we save the DB (is it migrated?)
( which btw also “automation” is all about)… Sitting and writing code have never been anything that Triggers me, so for me it’s basically a “need to do” in some cases
