Guess we all just better get used to editing unreadable JSON files under .storage versus YAML. And /or watching a lot of click here, click there Youtube videoes to figure out how to do something that could have been described in a few lines on the forum…
13 Likes
I read the whole thing, but I came away with the impression that things like automations and scripts are still being allowed to exist in YAML, but it was not stated that that would be the primary method encouraged to be used in the future. Also, what about sensors? Some of my most complex and interesting customizations are sensors.
3 Likes
template sensors will stay in YAML I think, they want to add it to the UI too but more like how they did timers and input_* so hopefully in the future it means you won’t need to restart to add a template sensor 
If you use the UI editor for an automation it generates the YAML in the background. That YAML can still be edited by hand and can still be viewed / shared as needed.
As for sensors, is there even a GUI way to edit them today? I believe they would fall into one of these categories from the original post:
Integrations that integrate transports. These integrations allow users to define their own protocol, e.g., MQTT, serial, GPIO.
Integrations that process Home Assistant data and make this available to other integrations, e.g., template, stats, derivative, utility meter.
Integrations that provide automations, e.g., automation, device_sun_light_trigger, alert.
Integrations that help controlling devices and services, e.g., script, scene.
Integrations that expose Home Assistant data to other services, e.g., Google Assistant, HomeKit.
To me, the biggest take away is that configuration of integrations will be via the GUI (which is, frankly, better) and eveything else will still be YAML. Please help me to understand why this is an issue (and I’m asking honestly because I keep seeing posts about this and no one really had a solid reason).
6 Likes
What are you trying to edit in .storage?
I’ve moved many of my integrations from the YAML setup to the GUI setup and in all cases it was easier in the GUI. Are you seeing a place where it’s harder / less intuitive to setup via the GUI? If so, where?
2 Likes
No, but sharing the fact that you DO have an allergy sensor was useful.
I learned everything about homeassistant from others’ githubs, and would look and say to myself “hmm, where does sensor.xyz come from?” and then look through the rest of the configuration and find out what integration it was. Even inspired me on what hardware to buy.
I then shared my configuration with the same level of detail, and people could look at my lighting package and see what integrations I used and what automations controlled them.
My github then basically became a load of automations only as the configs moved to UI. I started getting messages saying “I’ve copied this and it doesn’t work…” and I had to reply with instructions for them to add the integrations that the automations depended on, whereas before they could have seen it in the same file they got the automation from.
I got fed up with it in the end and binned my github repo. I still get people begging me to put it back up, but I’m not happy to do so until I can think of a way of somehow maintaining a list of what things rely on a UI configured integration without making a frick load of extra work for myself, as unfortunately I have a lot of other things irl that take up my time too.
And as for
That’s not strictly true is it? Everyone driving these changes is on the payroll, and thus they aren’t providing these contributions for free, they’re being paid. All the ‘old school’ big names who were staunch yaml lovers haven’t been taken on as ‘staff’ and haven’t committed to the project in a long while. Presumably politics, but it’s weird to hear the “we do this for free” argument from people who are getting paid for their time.
26 Likes
Having been ‘one of those people’ (see for example the 0.108 release thread, I got many likes!), I must say I feel much better having thought about it a few days. I meant to post in the 0.108 thead but this presents a more opportune place.
Leaving scenes/automations/scripts available to use yaml, as well as still being able to do templating and commandline and utility integrations via yaml makee me feel much better about the direction this is taking.
Cheers all.
10 Likes
If I’ve understood it correctly, this is the summary:
YAML will continue to be an available means of configuring most everything except for integrations that automatically discover their devices.
That suits me fine.
The only thing I would like to see is the Automation Editor storing things in human-friendly YAML as opposed to the unfriendly YAML it currently produces (sorted and compressed).
17 Likes
I think this is a well balanced solution. Thanks devs.
2 Likes
I think this is the most well though out reply that I’ve seen and I think this actually makes pretty good sense. I suppose you would lose some of the context of the automation YAML if you weren’t aware of the integration and it is certainly less informative from a “what to buy” standpoint.
I wonder if there might be a way around these issues (I’m certainly not the person to come up with one but it’s an interesting thought experiment).
1 Like
Out of curiosity, why was JSON chosen for Storage Collections instead of YAML?
They’re functionally interchangeable but YAML is easier for people to read. Or is that why JSON was chosen … (an implied “Don’t Touch”).
14 Likes
That is the most succint statement you will ever see describing this situation right there…sums it up clearly in as few words as possible in my belief!
4 Likes
Well at least we aren’t having xml foisted on us.!
4 Likes
I avoid integrations unless it is the only option. They have not been reliable for me across upgrades or even sometimes reboots. One of my upgrade techniques depending on how long it has been since I have upgraded has been to just resort to wiping out .storage completely and reconfigure those few things I have integrations for. If HASS doesn’t come back up due to an integration issue, I don’t know what else to do. And then there are times I reboot and something disappears because it wasn’t communicating when discovery was run. Or it prompts me to re-auth stuff again even though it is still working.
As far as the JSON thing, I have only started exploring that, but if that is the only means I have to deterministically configure things then that is probably what i will do.
I mean I get it, trying to make it easier for people because YAML is a sucky space delimited syntax. And more people are going to find a GUI easier. And you can configure the GUI on any device, etc. But JSON and YAML are easily convertible, so I don’t get why you can’t have a GUI and YAML.
8 Likes
I’m stuck at the part where the representation of the config data is YAML and entered with a text editor versus the config data in JSON and entered with a fixed UI specific for the use cases. Talking UI vs YAML is chalk and cheese. Why not just have the UI spit out YAML for non-sensitive config, and to a different file/format for the Personal Identifiable Information?
9 Likes
Breaking changes
We all dislike them, those breaking changes when a new release is published. We all scan the release notes hoping you are not affected by any of them in that release.
There is a big upside on using configuration via the UI: Home Assistant manages that configuration part for you and handles the upgrades and migrations. Virtually removing the chances of hitting a breaking change, we all hate just as much.
its sad that for the UI config there has been taken action to automaticly check and migrate, and that that same action wasnt taken long ago for yaml.
i wouldnt have stopped updating if that was the case.
its still possible by the way, but probably will never happen.
3 Likes
I think it’s just a matter of including a list of devices and integrations that you use on your github page if that’s what you’re in to. Users do it already with lots of nice images and everything. The dev tools > info page even has a list of integrations in used to be copied. It could be made better and more easily copied.
3 Likes
The future of YAML is going to be exactly what the paid employees want…so all the rest of you whingers can just crawl in a hole and be silent!
6 Likes
I’d imagine it is because it’s not meant to be manually edited and because JSON can easily be converted to a native Python dictionary. However, I’m a Python beginner and more importantly not one of the devs so I could be wrong.
yaml as well.
5 Likes