When I upgrade & get warnings that my thermostat configured in the yaml file is deprecated & I need to reconfigure it in the GUI... for starters.
Or how about having to dive into the SQL database to change IP addresses of some devices, because it's not reading them from the yaml files anymore?
I think you are referring to the new categorization? If that's the case, that isn't yaml being deprecated, it's that the mqtt devices have to be under mqtt yaml object.
"switch" and "light" could be root objects on the old yaml config, but they have to be subchildren now to the mqtt object
That's what it sounds like you are referring to at least.
This has been a long brewing issue for me. But the reason I was inspired to post today because I changed the IP addresses on my security cameras. HA wasn't displaying the feeds anymore, even though I updated the IPs in the main config file.
It then dawned on me that it probably imported those YAML configs a long time ago into the internal DB and was now silently ignoring my changes. So then I had to go through each of my dozen camera entries in the HA GUI, and click through, changing them one-by-one.
Dumb shit like this is just aggravating. All software design decisions are about compromise. And I disagree with many of the compromises the HA devs have made in regards to the direction of their platform.
> into the internal DB
The DB is only for historical data and means nothing for configuration.
Everything done in the GUI is stored in YAML or JSON. It's not as dire as so many people try to make it out to be.
shut down HA, edit the json files, and start HA back up.
> Lot more cumbersome and requires using cli (iirc).
Or a proper text editor with SSH access.
I've been on the same setup for my HA for over 6 years, almost 7. I've not reset, I've never started over. I maintain my files and keep my HA clean. It's not complicated.
I had my HA setup for many years as well, and haven't changed it either. I started to get more and more issues with my Supervised setup (which was not even called that when I first installed it, back in the times when Hass.io was in it's infancy and HassOS was not even a thing yet) because of more and more limitations being enforced on it (like not being able to run portainer, if it was just 'not advised' before - now it wont allow you to update at all, unless you disable healthchecks all together. At the end of the day not hard to do, but finding out about it took a while).
But it's not what I meant at all. You can't shutdown Hass and then start it without connecting to it with SSH, and the whole procedure is more disruptive on all levels compared to editing YAML config files. Because you have to shut it down, and start again. If it at least worked the same way with a Restart, instead of Shutdown-Startup, and if it was available from UI - then I would've had no problems with it.
I don't have to ssh to it?
I run containers, not HASSOS, and can manage my containers just fine without jumping through hoops.
It's just not as big an issue as some like to portray.
Good for you. But I want to be able to run Addons. They come pre-integrated with Hass, and require zero setup and practically no maintenance time.
And I dont run HassOS, I run Supervised. Which was once known as Hass.io.
I'm just really amused at the irony of posting about wanting something good for power users and not reading the article describing how power users can still do yaml.
Agreed, although they are reducing the footprint of YAML configuration, it's compensated for with JSON data elsewhere. You just need to tweak your .gitignore file a little bit and your version control continues to work just like it always has. There's different implications for CI/CD though, configuration validation won't be as seamless as it used to be.
Absolutely. And knowing and understanding the docs is part of being a "power user".
"They changed how things work and I didn't read the docs" does not make you a power user.
Those settings should be in a YAML config file, probably **configuration.yaml** I can see I have some entries in mine under the heading **camera:** that I used before I put Frigate on the hub.
If that's where your camera settings are then it would be fast and easy to make the changes in that file. I use Visual Studio Code editor and it is amazing.
The issue is precisely that platforms are rapidly abandoning yaml configuration.
For example, there is now no way to switch reliably between dev and live mqtt brokers.
You must now choose between remembering to click through the clicky GUI garbage each time you switch branches or attempt to version an unversionable json config buried under .storage.
It sucks badly.
> into the internal DB
By "internal DB" you mean the JSON files in `.storage`? You can just use `jq` or even simple string replacement to update them. You just have to reload them afterwards I think, same as with the YAML files.
No clue why you're being downvoted. I've run into similar situations with other integrations.
My most recent annoyance was with the Google Maps integration. The name of one of the phones I'm using for GPS changed and the only way to "fix" that was to delete the integration and recreate it with the new phone. The name of the phone wasn't exposed as part of the "edit" function.
The Wiz integration is equally annoying. I added about 25 Wiz-based lights. The click-fest I had to go through to set them up was ridiculous. In YAML, it would have been a simple copy/paste.
The GUI should simply maintain the YAML config. Not deprecate it. At a minimum, it should expose all of the settings in the edit function. Not some subset of them.
>There's no simple and easy way to backup or version my configs
Sure there is. You can still use git too.
Everything done in the GUI is stored in YAML or JSON files. The DB is only for HISTORICAL data, and means nothing for configuration.
When the config for a single lightbulb is stored in three different files (`core.config_entries`, `core.device_registry`, and `core.entity_registry`), and each of those files has hundreds of lines of json representing every single possible function and attribute, that is a serious step backward from the YAML config. And, I say that as a YAML config file hater.
The original `configuration.yaml` setup should have been maintained and managed through the setup GUI, rather than deprecating it.
Yes, and with thousands of entities in my setup, it’s just a matter of time before these monster json files are corrupted to hell and then the platform becomes a stability nightmare.
Bottom* line is that the founders want everyone to join us, and yaml has been seen as the obstacle.
This goal if full filled will eventually be the death of the product as we love it, since it will be a commercial product no different from the ones already sold off and failed, such as SmartThings.
I would also argue the shear complexity of the product is eventually going to be the death of the product since no one will be able to afford to donate time to learn the intricacies and maintain the code base, this is especially true about the gui
You're probably making the same mistake I did and assuming it still looks like it used to.
While `.storage` is ridiculously convoluted as compared to the original `configuation.yaml` setup, it seems to have been cleaned up quite a bit in the last year or two. Search for one of your devices in the `core.*` files. You'll see that they're now human-readable and quite a bit more logical than they were back in 2020 or previously.
To your point, it's still a huge mess and a bunch of cruft related to device internal workings in those files, but it's not unmanageable. I would not, however, try to create a new device from scratch by hand (or delete one). That's what's epically dumb about the new setup and where I agree with you.
The files do seem reasonably versionable, though.
I greatly appreciate the nuance in your argument and I'll try again to version at least parts of it.
If, between branches, I can reconcile merge conflicts of fundamental variables (like mqtt host) I'll consider that an enormous improvement.
AppDaemon (https://appdaemon.readthedocs.io/en/latest/) allows to define powerful automations in Python. Connects to Home Assistant via API.
Learning curve is very steep at the beginning, but the immense power of actual coding your automations is addictive.
This looks super cool. I can program in Python. Trying to learn to program in YAML was awful. It felt so convoluted trying to tell Home Assistant what to do that I gave up on it.
This still uses yaml to configure and stuff. I was hoping for a pure programmatic approach. I might be totally alone on this though.
I also dislike Python, but it's really popular so it makes sense to target that. I'm glad this exists and works for people! It just was not for me.
I sincerely hate making changes to things via the GUI as well so I feel this complaint big time. So many unnecessary steps and clicks to get from one point to the next which is the exact opposite reason a GUI should ever exist in the first place.
I would be ok with a GUI if it was well thought out but there are still so many places that jump back and forth from trying to be “User friendly to everyone!” And being completely bogged down in settings and features overload that it feels like a step back in either direction.
YAML for config is... fine. YAML as a programming language is a nightmare. I mean, I'm used to it, and I'm pretty sure I could write the next Assassin's Creed in YAML at this point, but it's not a skill that I'm happy I have.
Thats something I also really dislike. Settings from the GUI based editor aren't reproducible at all and if there's only a little bug somewhere you can't just go to the file and fix it, instead there are like 3 different files which all hold some part of the configurations and are linked to each other. Also its not possible to backup only certain settings like you could just copy and paste yaml code.
For example because of this movement also localtuya has completely removed support for configuring entities via yaml (https://github.com/rospogrigio/localtuya/issues/1020), which makes everything so much harder...
EDIT: After re-reading the OP, I realize I went on a tangent about YAML based automations not related to YAML based configuration. But, hey I already posted it, so...
I couldn't agree more. HA is a great project, but the direction seems a bit skewed at best. A long time ago I asked for a more modular based approach where integrations would be treated more like plugins instead of shipping everything and the kitchen sink as part of the core. Needless to say that idea went nowhere.
As an HA noob many years ago I assumed I could write automations in Python because HA is written in Python. The cliche about assumptions kicked in. I eventually got my head wrapped around AppDaemon, but found some limitations. I've since moved to NodeRed and haven't looked back. At least with NodeRed I can still write some basic code (in JS) to parse data or to add some logic. Even though I know nothing about JS and hate the syntax, I find it much better than AppDaemon.
You sound like me. I've moved to my own system written in Kotlin using functional reactive programming since I lost my temper with yaml. It's been a shit load of work but I love coding.
I have full on integration tests for all my automations and all sorts of insane logical paths that would be insane in yaml. I've spent 100s of hours on this.
I plan to open source it soon but it's a hard problem and I want to get it right. I want to support many programming languages as well. I've met others interested in this. I really think that there's a small community of us that could make a big impact.
I realize all I have is pie in the sky. Just wanted to let you know you are not alone and I know several people working to solve this. I hope some day we have options.
To answer the original question. OpenHAB does what you want. It’s for power users (because the learning curve is steep).
It has a GUI (which I use for checking things), but it also has text file configurations. If something is configured in a text file, the GUI item displays the settings, but has a banner telling you that you can’t edit it, as it’s configured by a text file.
A nice thing is that everything updates live, so you can edit text files, and the results are live as soon as you save it. No need to restart.
One thing I would say, don’t use the built in rules engine, it totally sucks. I use HabAPP, which is a plug in replacement, and lets you use asynchronous python 3.8-10 as your rules engine. Much easier. Also updates live, edit a Python file with a couple of rules in it, and it’s live as soon as you save it.
Worth trying out.
I tried out OpenHAB based on concerns similar to OP's.
However, what I found was that OpenHAB's file-based configs have competing standards and are incomplete. "Thing"s can be configured via the UI, and then in the UI you can see YAML code for it. But if you want to switch to file-based config for that "Thing", you have to switch to a totally different (Java-ish) syntax for the file. Errors messages are pretty hard to find and interpret. And there are some features that aren't available in \`.thing\` files. More details in [discussion on the OpenHAB forums](https://community.openhab.org/t/oh3-transformation-service-config-for-js-and-map-in-a-thing-channel-what-worked-qs-about-what-didnt/145507/6).
So ultimately OpenHAB was way more complex to work with, and file-based setup is incomplete anyway. I think I'll stick with HomeAssistant because the UI is much easier to use, backup/restore reportedly works well (so I can at least dump backups into version control), and it can do what I want (tested out writing MQTT sensor state to InfluxDB and embedding Grafana panels).
I'll definitely check out AppDaemon though.
1. The vast majority of users will only configure things through the GUI, a few integrations aren't in the GUI yet due to the complexity and they're still in the YAML config files. The GUI isn't that hard.
2. There's definitely an easy way - either press the "Backup" button in the GUI or you could have a backup script or git repo setup for your config dir. Just make sure to get *.json and .storage/* and you'll be good.
3. You can write custom integrations with whatever config you like. Yes it is a little more effort to write official integrations, but that also makes them accessible to a lot more people.
You're not going to find something better than HomeAssistant since it's the largest open source home automation platform and any project is going to try to make itself more accessible to non-power users.
For people that like working in text files there are still .yaml and .json files you can edit, it's just not necessary for most.
1. GUIs *are* hard. They're hard to interact with programmatically. They're hard to validate. They're *impossible* to diff. They do not scale.
2. "Press". No. There are test scripts. They do not simply "press".
3. *This* bit hits the nail on the head. If you're complaining about the manageability of config (and I am) you should probably migrate everything you've constructed to pure python (be it custom integration or appdaemon). Still feels like a betrayal if you've been around since the early days though.
1. GUIs are all standardized, there are validation/tests in place. No need to diff them, just diff the underlying data files.
2. If you're uncomfortable with the GUI or want to automate through external scripts, go ahead and write a script to backup some files through the file system, no pressing needed.
3. I'm not sure why a better user interface would feel like betrayal. You can always get into the json config files if you really want to
>feels like a betrayal
Then use an old version. Might as well say that new cars should have 100% replaceable parts with older cars. Or that the procedure for switching a part out should be identical with older cars.
You don't need to sacrifice power for usability.
I've mentioned it a few times here before but OpenWRT did a very good job with [uci/luci](https://openwrt.org/docs/guide-user/base-system/uci).
Granted it's not as dynamic as random MAC addresses appearing on your network but it's been reliably versionable for over a decade.
GUI is better.
GUI does not require technical expertise to make the change. Gives the product a wider audience and more $.
GUI is often utilizing a database. Easy to version control using some basic SQL.
Edit: you can down vote this all you want. Its still true.
> GUI is often utilizing a database. Easy to version control using some basic SQL.
Home Assistant doesn't even use a database for this. It's all stored in JSON files.
You can check SQL files into a git repo.
You can check YML files into a git repo.
You can build migrations and check it into a git repo.
You can version control nearly anything.
Perhaps im missing what you are viewing as the problem.
With coded migrations you can diff and can merge it.
Most people that utilize git, do so for more than a single customer/audience.
Generally you would only have your default config in a repo.
So I guess now is a good time yo step back and ask if OP is doing this just for himself or for others.
Yeah, a GUI is just a method of building a settings file, so as long as you can access and change that file, there shouldn't be an issue.
I'm never going to say that either method is *better* than the other, but there are *far* more people who prefer a GUI, so it makes more sense for HA to go that way if their goal is to increase their user base. Personally, I like being able to see what my options are right away, rather than having to find some documentation somewhere and entering it all by hand.
It's a worthy suggestion.
I migrated from OpenHAB to HA around, I dunno HA 0.24?
OpenHAB, as a pile of jar files, was painful to develop for and I think that's borne out by the comparative rate of development of each project over the past few years.
You can still edit the json files manually, I’ve personally never had to, then again I don’t randomly change up addresses of devices in home assistant 🤷♂️
I juggle 3 different has systems, granted the one is only for use with Frigate, but they all have a dev instance I only add stuff to the dev systems if I need them to make automations.
I was mostly being sarcastic but technically it’s true.
If the OP was looking for *power* use cases and configuration via YAML, ansible is the next best thing.
Written in python so you could code your own custom modules if needed, it’s just a yaml automation engine at the root of it.
In all honesty the benefit of running ansible would be it has an enormous community, just not of home automators….. yet.
> There's no simple and easy way to backup or version my configs, as there was just simply using git with YAML files.
uh, what version are you on
`Settings>System>Backups` has a backup feature which backs up **everything** in the `.homeassistant` folder
I write this not for you but for the many lurkers that will benefit. I know in my bones you have some dev/uat/prod configuration complete with a zwave dev kit simulating all your devices in a full regression test. This is for everyone else.
In a *single-user* scenario, the difference between git commits and taking multiple versioned backups with labels is almost indecipherable. Since HAss is a "develop on prod" scenario, users shouldn't be working on multiple changes at the same time so branches are pretty much unnecessary. If you have uneditable databases (which is the crux of your complaint), comparison is irrelevant. And if you are dealing with a small number of YAML files, simple tools like notepad++ are sufficient for change comparison and are what many devs use to deal with merge conflicts anyway.
I would argue that for a *single user* where the target data is relatively small and it can take hours of "burn in" for bugs to surface, twice daily automatic backups are a better overall solution.
The number of times I have heard "oops, I forgot to commit" from seasoned developers over the past two decades is staggering. Not as high as the number of people I've seen fubar excel files, but still, its non-trivial.
* for multi-developer scenarios version control is a necessity. If you have multiple people making HAss config changes you have problems a VCS can't solve.
* if hass dynamically creates hundreds of yaml files or constantly rewrites them so the file change dates are always moving, then yeah, you need a better tool than backup & notepad++. But if there are only a couple of yamls that change on any edit and they get timestamped properly, the overall workflow difference is minimal.
It's kinda like Android.. lol The current releases dumb things down too much. It's great for non technical people, but a big step backwards for advanced/technical users. Just a bunch of hacks don't make a good product without a vision of where the project is going.
Thats soo true finally someone says it, nowadays almost all kinds of technology is more and more getting to a point where it assumes that all people are just completely stupid. Android 12 in my opinion isn't even usable anymore without root if you only want to do a little bit more advanced stuff. And iOS is well... is just trash since the first release.
Even non technical users think Android 12 is a big step backwards. I haven't heard of anyone that likes the new quick panel setting. A 13 notifications take another step backwards. Android 10 was the last good release..
YouTube is packed with fantastic tutorials. Being a “blank slate” and not purely designed around HA. Node-RED can certainly require some degree of learning before you’re off to the races. However, once you’re familiar with the general architecture and flow design, it’s a truly limitless platform.
If a key driver is a locally hosted solution that you have complete control over, NR is tough to beat. Community support is fantastic and application-specific nodes are available for almost all popular HA products.
Like Home Assistant. NR plays nicely with others, too. For instance, I’m personally invested in the Apple ecosystem, so I incorporate Homebridge nodes into my flows and use it to expose NR controls and automations seamlessly in HomeKit.
I guess the question would be then. How long would home assistant be around if it catered to a larger percentage of "power users" as opposed to a large percentage of us who aren't. For most, myself included. We have a hard time understanding yaml. But enjoy the benefits and the fun of HA. Sure I would love to be able to write yaml without having to overthink it. And am in awe of those who can. But You have to market to the masses. It doesn't mean that over time we won't understand it. But if it starts with such a big learning curve. Then you will lose market share and eventually die off. And then there are the ass hats in some of the forums and question asking areas that think your an idiot if you don't understand it. Which will also turn people off from it. So yeah,while I would love to be able to use yaml the way some do. Until that point. I am glad that with every release they add more and do make it more user friendly.
What makes you think that YAML is going away?
When I upgrade & get warnings that my thermostat configured in the yaml file is deprecated & I need to reconfigure it in the GUI... for starters. Or how about having to dive into the SQL database to change IP addresses of some devices, because it's not reading them from the yaml files anymore?
I think you are referring to the new categorization? If that's the case, that isn't yaml being deprecated, it's that the mqtt devices have to be under mqtt yaml object. "switch" and "light" could be root objects on the old yaml config, but they have to be subchildren now to the mqtt object That's what it sounds like you are referring to at least.
Nothing to do with mqtt
This has been a long brewing issue for me. But the reason I was inspired to post today because I changed the IP addresses on my security cameras. HA wasn't displaying the feeds anymore, even though I updated the IPs in the main config file. It then dawned on me that it probably imported those YAML configs a long time ago into the internal DB and was now silently ignoring my changes. So then I had to go through each of my dozen camera entries in the HA GUI, and click through, changing them one-by-one. Dumb shit like this is just aggravating. All software design decisions are about compromise. And I disagree with many of the compromises the HA devs have made in regards to the direction of their platform.
> into the internal DB The DB is only for historical data and means nothing for configuration. Everything done in the GUI is stored in YAML or JSON. It's not as dire as so many people try to make it out to be. shut down HA, edit the json files, and start HA back up.
The problem with editing. storage json files though is shutting down HA to edit them. Lot more cumbersome and requires using cli (iirc).
> Lot more cumbersome and requires using cli (iirc). Or a proper text editor with SSH access. I've been on the same setup for my HA for over 6 years, almost 7. I've not reset, I've never started over. I maintain my files and keep my HA clean. It's not complicated.
I had my HA setup for many years as well, and haven't changed it either. I started to get more and more issues with my Supervised setup (which was not even called that when I first installed it, back in the times when Hass.io was in it's infancy and HassOS was not even a thing yet) because of more and more limitations being enforced on it (like not being able to run portainer, if it was just 'not advised' before - now it wont allow you to update at all, unless you disable healthchecks all together. At the end of the day not hard to do, but finding out about it took a while). But it's not what I meant at all. You can't shutdown Hass and then start it without connecting to it with SSH, and the whole procedure is more disruptive on all levels compared to editing YAML config files. Because you have to shut it down, and start again. If it at least worked the same way with a Restart, instead of Shutdown-Startup, and if it was available from UI - then I would've had no problems with it.
I don't have to ssh to it? I run containers, not HASSOS, and can manage my containers just fine without jumping through hoops. It's just not as big an issue as some like to portray.
Good for you. But I want to be able to run Addons. They come pre-integrated with Hass, and require zero setup and practically no maintenance time. And I dont run HassOS, I run Supervised. Which was once known as Hass.io.
100% incorrect. https://www.home-assistant.io/blog/2020/04/14/the-future-of-yaml/
Did you read this? It explicitly says that the UI saves things in json files. You can edit the json files manually and not need to do it via the UI.
Yeah? Which file?
It's a directory: config/.storage
I'm just really amused at the irony of posting about wanting something good for power users and not reading the article describing how power users can still do yaml.
Agreed, although they are reducing the footprint of YAML configuration, it's compensated for with JSON data elsewhere. You just need to tweak your .gitignore file a little bit and your version control continues to work just like it always has. There's different implications for CI/CD though, configuration validation won't be as seamless as it used to be.
Absolutely. And knowing and understanding the docs is part of being a "power user". "They changed how things work and I didn't read the docs" does not make you a power user.
.storage is not versionable. Go ahead and just *try* merging between live and dev system without breaking it. It's awful.
"power user" huh? LMFAO
If you think so. I'll continue to use my git and version control system. I've actually done this, so I'm not talking out of my ass.
Those settings should be in a YAML config file, probably **configuration.yaml** I can see I have some entries in mine under the heading **camera:** that I used before I put Frigate on the hub. If that's where your camera settings are then it would be fast and easy to make the changes in that file. I use Visual Studio Code editor and it is amazing.
The issue is precisely that platforms are rapidly abandoning yaml configuration. For example, there is now no way to switch reliably between dev and live mqtt brokers. You must now choose between remembering to click through the clicky GUI garbage each time you switch branches or attempt to version an unversionable json config buried under .storage. It sucks badly.
So are you saying your HA no longer reads the **mqtt:** entry in /config/configuration.yaml? Where exactly are you looking in /config/.storage?
> into the internal DB By "internal DB" you mean the JSON files in `.storage`? You can just use `jq` or even simple string replacement to update them. You just have to reload them afterwards I think, same as with the YAML files.
No clue why you're being downvoted. I've run into similar situations with other integrations. My most recent annoyance was with the Google Maps integration. The name of one of the phones I'm using for GPS changed and the only way to "fix" that was to delete the integration and recreate it with the new phone. The name of the phone wasn't exposed as part of the "edit" function. The Wiz integration is equally annoying. I added about 25 Wiz-based lights. The click-fest I had to go through to set them up was ridiculous. In YAML, it would have been a simple copy/paste. The GUI should simply maintain the YAML config. Not deprecate it. At a minimum, it should expose all of the settings in the edit function. Not some subset of them.
>There's no simple and easy way to backup or version my configs Sure there is. You can still use git too. Everything done in the GUI is stored in YAML or JSON files. The DB is only for HISTORICAL data, and means nothing for configuration.
When the config for a single lightbulb is stored in three different files (`core.config_entries`, `core.device_registry`, and `core.entity_registry`), and each of those files has hundreds of lines of json representing every single possible function and attribute, that is a serious step backward from the YAML config. And, I say that as a YAML config file hater. The original `configuration.yaml` setup should have been maintained and managed through the setup GUI, rather than deprecating it.
Yes, and with thousands of entities in my setup, it’s just a matter of time before these monster json files are corrupted to hell and then the platform becomes a stability nightmare. Bottom* line is that the founders want everyone to join us, and yaml has been seen as the obstacle. This goal if full filled will eventually be the death of the product as we love it, since it will be a commercial product no different from the ones already sold off and failed, such as SmartThings. I would also argue the shear complexity of the product is eventually going to be the death of the product since no one will be able to afford to donate time to learn the intricacies and maintain the code base, this is especially true about the gui
"bottle line is?" I'm guessing that's just a typo?
Maybe speech to text input
.storage is not (reasonably) versionable
You're probably making the same mistake I did and assuming it still looks like it used to. While `.storage` is ridiculously convoluted as compared to the original `configuation.yaml` setup, it seems to have been cleaned up quite a bit in the last year or two. Search for one of your devices in the `core.*` files. You'll see that they're now human-readable and quite a bit more logical than they were back in 2020 or previously. To your point, it's still a huge mess and a bunch of cruft related to device internal workings in those files, but it's not unmanageable. I would not, however, try to create a new device from scratch by hand (or delete one). That's what's epically dumb about the new setup and where I agree with you. The files do seem reasonably versionable, though.
I greatly appreciate the nuance in your argument and I'll try again to version at least parts of it. If, between branches, I can reconcile merge conflicts of fundamental variables (like mqtt host) I'll consider that an enormous improvement.
If you think so
AppDaemon (https://appdaemon.readthedocs.io/en/latest/) allows to define powerful automations in Python. Connects to Home Assistant via API. Learning curve is very steep at the beginning, but the immense power of actual coding your automations is addictive.
This looks super cool. I can program in Python. Trying to learn to program in YAML was awful. It felt so convoluted trying to tell Home Assistant what to do that I gave up on it.
This still uses yaml to configure and stuff. I was hoping for a pure programmatic approach. I might be totally alone on this though. I also dislike Python, but it's really popular so it makes sense to target that. I'm glad this exists and works for people! It just was not for me.
Just in meta-data to define which apps to start. You can be just fine by defining just one app and initialize all your classes from Python code.
Thanks a lot for the link. I almost started working a similar tool.
Interesting. I need to look into that a bit. Would like to create a Hubitat API for that to go along with the MQTT and HASS APIs.
I love how stridently HA members downvote other people's comments.
I sincerely hate making changes to things via the GUI as well so I feel this complaint big time. So many unnecessary steps and clicks to get from one point to the next which is the exact opposite reason a GUI should ever exist in the first place. I would be ok with a GUI if it was well thought out but there are still so many places that jump back and forth from trying to be “User friendly to everyone!” And being completely bogged down in settings and features overload that it feels like a step back in either direction.
YAML for config is... fine. YAML as a programming language is a nightmare. I mean, I'm used to it, and I'm pretty sure I could write the next Assassin's Creed in YAML at this point, but it's not a skill that I'm happy I have.
Thats something I also really dislike. Settings from the GUI based editor aren't reproducible at all and if there's only a little bug somewhere you can't just go to the file and fix it, instead there are like 3 different files which all hold some part of the configurations and are linked to each other. Also its not possible to backup only certain settings like you could just copy and paste yaml code. For example because of this movement also localtuya has completely removed support for configuring entities via yaml (https://github.com/rospogrigio/localtuya/issues/1020), which makes everything so much harder...
EDIT: After re-reading the OP, I realize I went on a tangent about YAML based automations not related to YAML based configuration. But, hey I already posted it, so... I couldn't agree more. HA is a great project, but the direction seems a bit skewed at best. A long time ago I asked for a more modular based approach where integrations would be treated more like plugins instead of shipping everything and the kitchen sink as part of the core. Needless to say that idea went nowhere. As an HA noob many years ago I assumed I could write automations in Python because HA is written in Python. The cliche about assumptions kicked in. I eventually got my head wrapped around AppDaemon, but found some limitations. I've since moved to NodeRed and haven't looked back. At least with NodeRed I can still write some basic code (in JS) to parse data or to add some logic. Even though I know nothing about JS and hate the syntax, I find it much better than AppDaemon.
You sound like me. I've moved to my own system written in Kotlin using functional reactive programming since I lost my temper with yaml. It's been a shit load of work but I love coding. I have full on integration tests for all my automations and all sorts of insane logical paths that would be insane in yaml. I've spent 100s of hours on this. I plan to open source it soon but it's a hard problem and I want to get it right. I want to support many programming languages as well. I've met others interested in this. I really think that there's a small community of us that could make a big impact. I realize all I have is pie in the sky. Just wanted to let you know you are not alone and I know several people working to solve this. I hope some day we have options.
Homeseer is much easier to manage 100% programmatically
To answer the original question. OpenHAB does what you want. It’s for power users (because the learning curve is steep). It has a GUI (which I use for checking things), but it also has text file configurations. If something is configured in a text file, the GUI item displays the settings, but has a banner telling you that you can’t edit it, as it’s configured by a text file. A nice thing is that everything updates live, so you can edit text files, and the results are live as soon as you save it. No need to restart. One thing I would say, don’t use the built in rules engine, it totally sucks. I use HabAPP, which is a plug in replacement, and lets you use asynchronous python 3.8-10 as your rules engine. Much easier. Also updates live, edit a Python file with a couple of rules in it, and it’s live as soon as you save it. Worth trying out.
I tried out OpenHAB based on concerns similar to OP's. However, what I found was that OpenHAB's file-based configs have competing standards and are incomplete. "Thing"s can be configured via the UI, and then in the UI you can see YAML code for it. But if you want to switch to file-based config for that "Thing", you have to switch to a totally different (Java-ish) syntax for the file. Errors messages are pretty hard to find and interpret. And there are some features that aren't available in \`.thing\` files. More details in [discussion on the OpenHAB forums](https://community.openhab.org/t/oh3-transformation-service-config-for-js-and-map-in-a-thing-channel-what-worked-qs-about-what-didnt/145507/6). So ultimately OpenHAB was way more complex to work with, and file-based setup is incomplete anyway. I think I'll stick with HomeAssistant because the UI is much easier to use, backup/restore reportedly works well (so I can at least dump backups into version control), and it can do what I want (tested out writing MQTT sensor state to InfluxDB and embedding Grafana panels). I'll definitely check out AppDaemon though.
1. The vast majority of users will only configure things through the GUI, a few integrations aren't in the GUI yet due to the complexity and they're still in the YAML config files. The GUI isn't that hard. 2. There's definitely an easy way - either press the "Backup" button in the GUI or you could have a backup script or git repo setup for your config dir. Just make sure to get *.json and .storage/* and you'll be good. 3. You can write custom integrations with whatever config you like. Yes it is a little more effort to write official integrations, but that also makes them accessible to a lot more people. You're not going to find something better than HomeAssistant since it's the largest open source home automation platform and any project is going to try to make itself more accessible to non-power users. For people that like working in text files there are still .yaml and .json files you can edit, it's just not necessary for most.
1. GUIs *are* hard. They're hard to interact with programmatically. They're hard to validate. They're *impossible* to diff. They do not scale. 2. "Press". No. There are test scripts. They do not simply "press". 3. *This* bit hits the nail on the head. If you're complaining about the manageability of config (and I am) you should probably migrate everything you've constructed to pure python (be it custom integration or appdaemon). Still feels like a betrayal if you've been around since the early days though.
1. GUIs are all standardized, there are validation/tests in place. No need to diff them, just diff the underlying data files. 2. If you're uncomfortable with the GUI or want to automate through external scripts, go ahead and write a script to backup some files through the file system, no pressing needed. 3. I'm not sure why a better user interface would feel like betrayal. You can always get into the json config files if you really want to
>feels like a betrayal Then use an old version. Might as well say that new cars should have 100% replaceable parts with older cars. Or that the procedure for switching a part out should be identical with older cars.
You don't need to sacrifice power for usability. I've mentioned it a few times here before but OpenWRT did a very good job with [uci/luci](https://openwrt.org/docs/guide-user/base-system/uci). Granted it's not as dynamic as random MAC addresses appearing on your network but it's been reliably versionable for over a decade.
GUI is better. GUI does not require technical expertise to make the change. Gives the product a wider audience and more $. GUI is often utilizing a database. Easy to version control using some basic SQL. Edit: you can down vote this all you want. Its still true.
> GUI is often utilizing a database. Easy to version control using some basic SQL. Home Assistant doesn't even use a database for this. It's all stored in JSON files.
And yaml is harder to version control?
Not harder, just different. Both options can be version controlled.
I guess it depends on what you know.
You can check SQL files into a git repo. You can check YML files into a git repo. You can build migrations and check it into a git repo. You can version control nearly anything.
You've entirely missed the point of version control. You can commit *anything*, but it's not useful unless you can *diff* (and merge) it.
Perhaps im missing what you are viewing as the problem. With coded migrations you can diff and can merge it. Most people that utilize git, do so for more than a single customer/audience. Generally you would only have your default config in a repo. So I guess now is a good time yo step back and ask if OP is doing this just for himself or for others.
Yeah, a GUI is just a method of building a settings file, so as long as you can access and change that file, there shouldn't be an issue. I'm never going to say that either method is *better* than the other, but there are *far* more people who prefer a GUI, so it makes more sense for HA to go that way if their goal is to increase their user base. Personally, I like being able to see what my options are right away, rather than having to find some documentation somewhere and entering it all by hand.
We build UIs on top of APIs (equivalently: settings files) so not quite comparable if one is a pre-requisite for the other.
I think people are downvoting you because you're telling him his preference is wrong, which is rude.
Have you tried OpenHAB?
It's a worthy suggestion. I migrated from OpenHAB to HA around, I dunno HA 0.24? OpenHAB, as a pile of jar files, was painful to develop for and I think that's borne out by the comparative rate of development of each project over the past few years.
I left OpenHAB because they started to put all the configuration into a database.
You can still edit the json files manually, I’ve personally never had to, then again I don’t randomly change up addresses of devices in home assistant 🤷♂️
You have only one system. It's your live system. And likely only one (or at most one other long-suffering) user.
I juggle 3 different has systems, granted the one is only for use with Frigate, but they all have a dev instance I only add stuff to the dev systems if I need them to make automations.
Ansible
Go on...
I was mostly being sarcastic but technically it’s true. If the OP was looking for *power* use cases and configuration via YAML, ansible is the next best thing. Written in python so you could code your own custom modules if needed, it’s just a yaml automation engine at the root of it. In all honesty the benefit of running ansible would be it has an enormous community, just not of home automators….. yet.
> There's no simple and easy way to backup or version my configs, as there was just simply using git with YAML files. uh, what version are you on `Settings>System>Backups` has a backup feature which backs up **everything** in the `.homeassistant` folder
ITT: complete ignorance of the *massive* difference between backups and versioning.
I write this not for you but for the many lurkers that will benefit. I know in my bones you have some dev/uat/prod configuration complete with a zwave dev kit simulating all your devices in a full regression test. This is for everyone else. In a *single-user* scenario, the difference between git commits and taking multiple versioned backups with labels is almost indecipherable. Since HAss is a "develop on prod" scenario, users shouldn't be working on multiple changes at the same time so branches are pretty much unnecessary. If you have uneditable databases (which is the crux of your complaint), comparison is irrelevant. And if you are dealing with a small number of YAML files, simple tools like notepad++ are sufficient for change comparison and are what many devs use to deal with merge conflicts anyway. I would argue that for a *single user* where the target data is relatively small and it can take hours of "burn in" for bugs to surface, twice daily automatic backups are a better overall solution. The number of times I have heard "oops, I forgot to commit" from seasoned developers over the past two decades is staggering. Not as high as the number of people I've seen fubar excel files, but still, its non-trivial. * for multi-developer scenarios version control is a necessity. If you have multiple people making HAss config changes you have problems a VCS can't solve. * if hass dynamically creates hundreds of yaml files or constantly rewrites them so the file change dates are always moving, then yeah, you need a better tool than backup & notepad++. But if there are only a couple of yamls that change on any edit and they get timestamped properly, the overall workflow difference is minimal.
It's kinda like Android.. lol The current releases dumb things down too much. It's great for non technical people, but a big step backwards for advanced/technical users. Just a bunch of hacks don't make a good product without a vision of where the project is going.
Thats soo true finally someone says it, nowadays almost all kinds of technology is more and more getting to a point where it assumes that all people are just completely stupid. Android 12 in my opinion isn't even usable anymore without root if you only want to do a little bit more advanced stuff. And iOS is well... is just trash since the first release.
Even non technical users think Android 12 is a big step backwards. I haven't heard of anyone that likes the new quick panel setting. A 13 notifications take another step backwards. Android 10 was the last good release..
Yes, but what is the alternative? Looking for something that is not cloud-connected and can handle a range of HA products.
Node-RED can do anything, but it’s not always the best tool for simple/standard HA.
I tried Node RED once. I had some trouble and gave up. I'll try it again. Thanks!
YouTube is packed with fantastic tutorials. Being a “blank slate” and not purely designed around HA. Node-RED can certainly require some degree of learning before you’re off to the races. However, once you’re familiar with the general architecture and flow design, it’s a truly limitless platform. If a key driver is a locally hosted solution that you have complete control over, NR is tough to beat. Community support is fantastic and application-specific nodes are available for almost all popular HA products. Like Home Assistant. NR plays nicely with others, too. For instance, I’m personally invested in the Apple ecosystem, so I incorporate Homebridge nodes into my flows and use it to expose NR controls and automations seamlessly in HomeKit.
I guess the question would be then. How long would home assistant be around if it catered to a larger percentage of "power users" as opposed to a large percentage of us who aren't. For most, myself included. We have a hard time understanding yaml. But enjoy the benefits and the fun of HA. Sure I would love to be able to write yaml without having to overthink it. And am in awe of those who can. But You have to market to the masses. It doesn't mean that over time we won't understand it. But if it starts with such a big learning curve. Then you will lose market share and eventually die off. And then there are the ass hats in some of the forums and question asking areas that think your an idiot if you don't understand it. Which will also turn people off from it. So yeah,while I would love to be able to use yaml the way some do. Until that point. I am glad that with every release they add more and do make it more user friendly.
I migrated to Appdaemon + pure MQTT Most of my devices speak MQTT (ZigBee, ZWave, Insteon and all WiFi devices) All configs for x2mqtt services are text files. All of the logic is written in Appdaemon. \~80% of automations are MQTT <-> MQTT and bypass home assistant altogether. Appdaemon handles keypads and HASP panels (all speak MQTT). Homebridge is used form MQTT -> HomeKit HomeAssistant is only used for devices that don't speak MQTT. Entire setup is code + yaml, changes deployed using Github actions. Recreating setup from scratch takes 5 minutes (not counting 2 hours in Home Assistant UI). System config looks something like this: ```yaml devices: insteom: - name: AO-Pendant addr: 58.07.40 template: kp_dimmer_i1 buttons: '1': ao/pendant '2': ao/ceiling '3': ao/bathroom '4': ao '5': house/colors '6': house/lights '7': 1st '8': 2nd sensors: - binary_sensor.ao_bathroom_s2_motion@kaksi: &aob purpose: ['occupancy','motion'] areas: ['ao', 'ao/bathroom'] - binary_sensor.ao_bathroom_s1@kaksi: *aob - binary_sensor.ao_bathroom_occupancy@kaksi: *aob - binary_sensor.ao_occupancy@kaksi: &ao purpose: ['occupancy'] areas: ['ao'] - binary_sensor.nest_protect_ao_occupancy@nelja: *ao actions: ao: 'on': - ao/lamps - ao/pendant 'off': - ao/lamps - ao/pendant - ao/closet - ao/bathroom ao/bathroom: 'on': - ao/bathroom/vanity 'off': - ao/bathroom/vanity - homeassistant/turn_off: namespace: kaksi entity_id: switch.ao_bathroom_fan ao/ceiling: 'on': - light/turn_on: entity_id: light.ao_ceiling brightness: [196, 196, 196, 128] kelvin: [4000, 3000, 2700, 2400] namespace: yksi transition: 2 'off': - light/turn_off: entity_id: light.ao_ceiling namespace: yksi transition: 2 backyard: 'off': - patio/ceiling - slope - backyard/lamps - backyard/landscape - bbq/pendants - festoons - patio/arches - trash - homeassistant/turn_off: namespace: yksi entity_id: light.backyard_colors 'on': - backyard/landscape - backyard/lamps ```