Well, after doing a pip install pyyaml you at least can convert it very easily:
import yaml
with open("output.yaml", "w") as fo:
with open("input.json") as fi:
yaml.dump(json.load(fo))
The other direction is almost the same. That way you can use your favorite cli-text-editor to modify the file in yaml. 
Edit:
If you like vim, have a look at this: https://github.com/elzr/vim-json/issues/62
I did read the whole blog post. If I say I had dinner, it doesnât mean that I skipped breakfast 
No, my âexact questionâ was about migration. If I make a backup, I donât necessarily have a(n easy) way to restore.
Hereâs my request again reworded to try and capture it in a different way that might be clearer.
I want to see a how-to that walks me through how to take a working HA setup from one device to a new one.
I have a Raspberry Pi 4 in the mail and when it gets here, I want to move my config from my Pi 3 to this new system.
Currently, I can git clone my config repo and then copy over the secrets.yaml to get nearly all the way there.
I honestly donât know how to restore from one system that uses UI-setup config & .storage to a new one. I would like to see the docs on that.
By the way, what I do not want is a comment like âwell, it depends what the user wants as a backup systemâ. If the intention is to make everything more user-friendly, then a user-friendly way to migrate to a new system should be considered as part of how this new way of doing things works.
Is that clearer, @cgtobi?
Iâm not complaining or avoiding reading, Iâm asking for the kind of help that potentially thousands of others are also interested in. Thanks!
You do a complete backup of the $CONFIG directory on the pi3 and restore it on the pi4.
rsync -avPp $CONFIG/ pi4:/$CONFIG
I think this gets at the heart of it though. Should adding integrations require directions? How many devices/services/software that you buy today require you to read an instruction manual to use or operate?
I just set up Grafana in docker without looking up any directions, and it works great, and the UI allows me to do whatever I want. Integration flows allow users to be guided through, without the need to lookup YAML directions (which they should be able to follow, but still). I think the points about separating config entries (in .storage) and the data/states is a good one though, that would make it safer for people backing up those files and keep âliveâ data away from what should be relatively static data.
In the end, I think this is a good compromise between flexibility and usability, but that feature parity should be kept (options for integrations available in YAML should be kept in the flows).
Why is it needed? Probably the same reason that you choose to help others learn HA - because you want more people to be able to enjoy the thing you enjoy.
But if Home Assistant was easy enough in the first place, you wouldnât have needed someone to help guide you, and you wouldnât have needed to teach someone else. Why put the burden on the community to support each other when it can just be made simpler in core? That is the entire point. The problem can be fixed at the source.
When your initial experience with something is super frustrating, trial and error, making mistakes, most people just give up completely and decide itâs not for them and not worth their time. First impressions are extremely important. Itâs not a good idea to overwhelm someone right off the bat.
And the fact is, you canât even really create any meaningful automations until you first have integrations in your setup. You cannot automate your lights if youâve never completed step 1 of integrating your lights. Thatâs why I consider integrations one of the most crucial aspects to really provide a good experience on, because so much of the system depends on them.
If we can get these new users set up with all their devices and services quickly, they are much more likely to ride out that initial frustration / learning curve, because at least they feel theyâve already made some progress. And if they have some basic automations done in the GUI / Automation Editor, there is less pressure to feel they have to learn everything YAML on day one, they can be eased into it over time.
Jesus I have had secretaries who cannot use word properly. âWhat is a style?â âI canât get this numbering rightâ âWhat do you mean âdid you save it as a document or a templateâ?â. These are meant to be professional document creators and they use word like a glorified typewriter. Donât expect anyone to read instructions. Donât expect people to do any more than it takes to get through in the easiest way possible. Donât even be surprised if they use twink on the bloody screen!
I donât necessarily have a problem with that. Perhaps someone who isnât willing to do the reading and the work should go with something like SmartThings. My initial experience, along with thousands of others (Iâm sure) was super frustrating, but you learn and you get help, and from the help and learning you get better and can achieve more by yourself and you build relationships with others in the community. Thatâs a good thing.
HA doesnât have to cater to everyone, and shouldnât. That was never the goal of this project. The tag line on the home page statesâŚ
"Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts". That last part is key - this project has grown and become what it is today because of tinkerers and enthusiasts, not from people going clickâŚclickâŚdone.
I donât believe that any features should be removed because someone canât follow documentation telling them how to integrate their Yeelight, Wemo switch or Hue Hub.
Read. Learn. Make mistakes. Ask questions. You will be better for it.
Itâs not just about that though, itâs about easing the burden on future development, and avoiding breaking changes in the future (which cause huge problems for the community, power users and newbies alike) at the expense of people who like to backup with git instead of snapshots.
One thing Iâve noticed in this thread a few times is that people are against the UI because changing a setting for an existing integration such as an IP address involves going into .storage to fix it (or removing the integration and adding it again). Iâd imagine it would be possible to add the ability to change settings in the UI for an integration thatâs already set up so that going into .storage wouldnât need to happen.
You already can with many of them by clicking the icon in the upper-right, itâs up to the integration author to enable it though.
Thatâs not what this is about though, itâs about being told YAML will never be removed, and then it gets partially removed. One starts to wonder what will be the next thing that is removed under the guise of âeasing the burden on future developmentâ as you have stated, or similar reason.
I keep going back to it, but the only motivation I can see for placing things in hidden folders that arenât supposed to read by humans, removing long used features and making things so simple that my Dog could set up HA, is money. Iâm yet to be told that is not a motivating factor.
I think itâs more about managing the future and keeping things sane rather than money, Iâve never gotten the feeling that Paulus or anyone else working for Nabu was in this to get richâŚ
If they are, theyâre doing it wrong.
LOL
I didnât know what that was so I googled it on my work pc 
At first thanks for original post. Well written, easy to read and understand, well organized covering all needed aspects.
I understand arguments of both sides. Especially for pro users, GUI can be slowing down factor. I guess there should be tools allowing non standard tasks like bulk changes (ie removing 200 devices at once etc) or other other advanced operations over the storage.
GUI is good thing to have but must be reliable covering all needed/basic features. I have in my mind how I struggled with removing entity from the system or renaming it (I mean renaming entity, not itât friendly name). I know it is not alway up to visualization layer itself, but in a component responsibility, but the difference is something a user doesnât care if a feature doesnât work.
Another thing is GUI organization. Currently, there are parts which are simply counterintuitive. like entities customization. Who the hell wants to jump between entity popup and customization page just to set icon? Iâm assuming it was easier to reflect data layer directly, without any further transformation to visualization one. But this is obvious mistake often done by programmers: gui is to provide consistent and intuitive experience to a user. Not to visualize data.
Ahh and please revise GUI design / implementation. I donât know what monitors you are using, but the size of gui elements is too big. I really donât need to have 3cm big letters. Simply reconsider css styling to make it more convenient of various display sizes.
As a recapitalization: Iâm for announced change but would expect improvements in GUI and extra tools for advanced users.
with regards
Fair enough. Point taken.
Restoring from backup works just the same way, as @nickrout explained one possible way, you copy you .homeassistant folder. That should be it.
Again, there is a difference between having a full backup and just some share files on GitHub.
I backup to my private git repo and thatâs about it. Of course I also have a backup of that self hosted git server etc.
This thread is unfortunately not the ideal place to discuss backup strategies as it easily gets lost in the noise. So feel free to open a new thread to share ideas.
I have to say that I find myself agreeing with an awful lot of what @kanga_who says in this thread.
This project (listening to the story Paulus recounts - in âState Of The Unionâ I believe) was created with an almost absent minded desire to play around with automating a light - Iâm sure that idea sounds familiar to you all .
So all this talk of expanding the audience and making it easier⌠Why do âweâ even care about that? (I ask this as a philosophical and very high level question.)
I donât suppose âbeginnersâ are on the whole likely to ever contribute to âThe Projectâ and that is of course more than OK, but where is the benefit to âThe Projectâ in having simply a sheer weight of numbers of âpassiveâ users if not to contribute to the income stream?
And again I say, how is basing the income stream on Amazon and Google, putting âlocal control and privacy firstâ?
I am afraid it is now not a rhetorical question. Iâd like an answer. How do you reconcile those two things?
(For the record, I donât actually care one bit about it because of course I/we all have the option of not using Amazon or Google and of not subscribing to NabuCasa. All the brilliance of HA will still be available to me - yes, for free.)
I am not making any judgements on the principle of making money out of HA I just think there needs to be a bit more openness and recognition that this is now the case.
And finally,
Nor have I and I trust that that is true, I actually donât question their motives at all, but letâs just acknowledge that with money, everything changes.
And getting ârichâ is a subjective thing. Supporting you and your family doing something you absolutely love makes you richer than the vast majority of the worlds population 
Very true!
Why we care about making it easier is not only to expand the audience but also if not foremost to improve the usability for everyone.
And contribution to the project as a whole does not have to be the form of code, documentation or support of other users like so many in this community do, but also by asking question, raising issues and showing what HA can be used for. The beauty of Open Source is that everyone can use it, can contribute back, but doesnât have to.
That quote that @kanga_who posted sums that up perfectly in my opinion. The project is driven by geeks like us but it doesnât limit its use to only this particular group of users.
Great summary!
The one thing that has perplexed me in this thread is what also bothers me. Why are things moving to JSON? YAML is meant to be a configuration markdown where as JSON is more for data transmission. Why are we going against that? Also because of that I do like YAML for us use with configuration files.