I would also like to have a clean separation of configuration and data/state so I can keep an overview of when something has changed - this allows me to find months after I made I change why I did it. For me this is the main motivation to keep the configuration in git so I have a history.
I like how HA is storing history into a dedicated DB which, if worst comes, can be reset and no config is lost. The .storage directory is currently used for config, state (as listed by @DudeShemesh) and caching (hacs for example tracks the github starts under .storage/ repositories). Unfortunately the separation is not in a per file basis so keeping a clean full history of config is not possible at the moment.
So I am wondering if there is consensus about the desire to split the information in .storage into config (that would only change based on user triggered actions - including updating HA) and state/cache (that can change at any time any could potentially get reset. This could be implemented in different ways such as a subfolder or a prefix for each type so .gitignore rules can be simple. If there is consensus we could start working on such split - I would personally look at contributing a PR to some that I use so I am not asking others if I can help but I would like to avoid spending time in a PR that does not meet consensus from the community.
So looking for feedback supporting the idea or alternative ways to have a history of configuration changes. @frenck - mentioning you since you have been involved in this subtopic - maybe worth moving into a dedicated forum topic?
And in general - thanks to the HA community - I just moved from a different automation 4 months ago and I really like how open this community is, how easy to find information and the huge amount of integrations and examples and options. I am an IT architect so I have a job-influenced way of doing things in big projects that I apply to home automation but I am not feeling frustrated at any time - home assistant is a great balance of easy and poweful base for programing my automation (I love appdaemon for that) and be reliable on my kubernetes cluster
I just meant that Itead (who makes Sonoff devices) have now also started making and selling several Zigbee based devices under the Sonoff brand, (and yesterday they even launched a Zigbee to WiFi bridge as well as announced more Zigbee based devices), and all such Zigbee devices can easily can be integrated into Home Assistant without using the Sonoff integration.
Making HASS configuration more user friendly via UI is a great idea. Also it’s great to be able to make config changes without need to restart. Unfortunately it doesn’t feel like correctly implemented.
I don’t understand why it’s not completely redesigned instead of switching to generating JSON files in weird .storage directory from UI and having this UI-generated vs YAML clash.
Why not having external store for configuration (SQLite, etc.) and option to enforce config via REST API like most mature services does? So purely UI users could utilize UI and users with Git-backed configuration, etc. could use their YAML files similar way as they do now and enforce configuration by calling curl against HASS API.
It could also support export/import of config objects back to YAML for backup purposes, etc. Could also handle schema changes during updates.
I don’t think that design decision is well thought and IMO it’s only making things worse.
I see a lot of references to the need to “restart” for changes to take effect instead of “reloading” as a motivation to do away with yaml. But I don’t think those are necessarily valid concerns. Or at least they are self-imposed limitations causing those concerns.
There are way fewer reasons to have to do a restart now than there were before.
We have a lot more availability of doing “reloads” of more things now than we used to that required a restart. At one time we could only reload customizations, scripts, automations and groups. And if any of those things were included in packages you also had to do a restart then because a reload wouldn’t work.
Now we can reload all of the above in packages too, input_* entities, and all of the Lovelace stuff (even if it is written completely in YAML like mine).
I’m not really sure if there was some sort of technical limitation that has changed to allow the newer “reload” functions instead of requiring a restart on those. But the question is then why can’t that same modification be made to allow all of the other stuff to be reloaded instead of needing a restart?
IOW, what’s the technical difference between an input_boolean defined in yaml and a sensor defined in yaml that allows the former to be “reloaded” and the latter required to be restarted?
The people who would want that type of solution already have those options. There are many, many commercial options that are “dumbed down” and made for the masses. HA has always been for those who want to “do more” than most commercial options allow.
You can make HA easy or you can make HA powerful but you can’t have both.
I see no real benefit for HA to just become just another appliance geared toward the least common denominator aside from the future profit it might bring to nabu casa. And if eventual profit isn’t the motivation then why do the devs want to dumb it down to bring in more users to the possible detriment of advanced users?
exactly.
This is a great community. People here are extremely generous with their time to help other people.
Just because we have disagreements over important topics like this doesn’t take away from that. I’d say that it’s a sign that we have a passionate user base that knows what it wants and is willing to say something when things are being done to impede that. To me that’s a positive.
yep and HA has grown into what it is over the years in spite of (or more likely because of) the flexibility that the yaml programming provided. How many have come to HA from other more restrictive platforms (like Domoticz)? It has to mean that HA, even with it’s “confusing and hard” yaml, was better.
Do you have any data that suggests that there are droves of integrations that aren’t being maintained simply because of the need to use yaml? If that was the case then there wouldn’t be over 1500 integrations right now because until recently everything used yaml and all of those integrations have always been maintained
Just because we don’t have a “flag” doesn’t mean we don’t contribute in many other ways. And it especially doesn’t mean that our opinions don’t count.
Generally speaking, yes.
How many times do we all tell new people to “post your config in text and not in screenshots” because nobody wants to be required to type all of the code out to correct/modify their code to be able to help them? I know I’ve said it a bunch. we all know it’s way easier for us to copy/paste/edit text than it is to write it all by scratch from a screen shot.
And for those reasons you will never really be able to use HA for it’s full potential.
But why should others who do use those things and, frankly, have been around for a lot longer than you have be deprived of the advanced possibilities/functionalities to cater to someone who won’t and doesn’t want to ever use those things?
And the exact reason for that potential is because HA is flexible/powerful and hasn’t been intentionally hamstrung by trying to cater to “the masses”.
No, it doesn’t “unlock” any other functionality other than remote access and easier voice integration.
Even if this will not be a particularly popular remark, what you suggest is probably a very romantic ideal of how things could evolve. Actually this community (and don’t get me wrong, I love this community) and especially the devs are more of a controlled anarchy rather than a let-sit-down-and-talk-about-it democracy. People dedicate their spare time to improve this project and IMO it would be too much to discuss every change to a integration on the forum first.
I know I wouldn’t because otherwise I wouldn’t have touched the Netatmo integration or at least only use my own personal changes rather than contributing back. I have broken things, some of you now suffer … public weather sensors … and I’m a little sorry about that. But I’m testing things with a group of “alpha” testers beforehand to not do something completely stupid.
So, in general, I think HA is evolving pretty well in functionality and user friendliness.
I agree, they shouldn’t! It’s not logical to push away your current userbase.
To be honest I do want to use the things you can do with templating, it’s just that I not able to wrap my head around how it works. I’ve tried to twice and now I’ve excepted the fact that I just can’t and never will. But I do really hope someday a lot of that functionality comes in some sort of UI. Again, not saying HA should stop providing the coding way, just add a UI way.
I just seemed as if you were making an overbroad generalization about “all these posts against the changes” and “not one of the people”.
If that’s not how you meant it then my bad. But I’ve seen that sentiment thrown around so many times it’s just ridiculous and I may be a bit over-sensitive to it.
It has not only run its course but ‘jumped the shark’ many posts ago, right about when the extant pandemic was used as an analogy. Not quite Godwin’s Law but damn close.
I currently work for a company and we moved away from editable configuration files about 5 years ago.
I work for a company that did this as well, but though we all accepted it (we didn’t really have a choice), I still miss the old text based tools. They were much more manageable for more complex environments than the gui flow builders. I know if we bothered to ask, I wouldn’t be the only one (we just don’t bother to ask because we don’t want to know ;-)).
Some of our gui flow builders also do generate standards compliant text files still that can in theory be portable and editable. If it must be in a gui, I think this is the nicest way to do it so you can switch between gui and non-gui worlds as needed.
I always fail to see the logic of the “please lock this thread” requests. Or the “censorship” vibe that comes with a moderator showing their authority by deciding that people can’t continue to talk about something that clearly interests those people because some find it “contentious”.
It doesn’t hurt anyone for it to be active.
Let those who want to keep participating in it keep participating. And if you don’t want to participate you don’t have to.
as long as it’s generally respectful what’s the harm?
Well we built a whole backend utility that allowed us to nicely view the files, it’s just XML. So we could edit them with an ‘editor’ if we wanted. But we didn’t give that out to people. Only for the devs.
I’m guessing you missed some of the early parts of the thread. There’s some deep seeded hate in some of these comments against the devs.
Something that people need to understand about development is that there will always be arguments. Not every PR will end in a happy situation for everyone. Some people in this thread are taking PR closures as personal attacks and they are projecting it on these YAML changes.
As for what’s the harm, it eventually allows people to ratch up the rhetoric to a point it serves to not only embarrass themselves but reflects poorly on the entire community. That’s why forum software has thread locks, often employed to protect people from themselves.
… and I’m a little sorry about that. But I’m testing things with a group of “alpha” testers beforehand to not do something completely stupid.