For technologists, DIY'ers and coders, CLI first or CLI parity means you can use common dev tools to build, integrate and track changes.

UI first means you have to build an awful lot of extra cruft to emulate parts of an already solid + flexible toolchain.

EDIT: I should mention that includes text + file based config too...

Locking the ability to set up a smart home behind the ability to code and do a heap of DIY if a big part of the problem.

> It's not as though you'll be rolling it out across multiple environments.

Definitely not for home use, but I could imagine a place for an open source server to manage a commercial property too. I'm admittedly a total outsider at property management, but I could imagine someone who operates several hotels, office buildings, or maybe even a school district wanting a building automation solution that doesn't lock them into a particular vendor. They'd have enough rooms and hallways with identical equipment that populating it via files, CLI, or an API might make sense.

That would be fantastic, it's true.

I missed the manual config at first, and being able to quickly fix things, but it turns out it's not so bad, and I think because of:

1 - Most setups are done once

2 - Stability and quality has improved in recent years, and you don't have to fix or mess with it as much

That said, I very much like being able to edit the yaml for automations and the lovelace UI. I like being able to flip back and forth between visual and code from the UI itself. Best of both worlds, especially because there's a lot of automations that are like 60% copied from another one. Being able to use a text editor (that has autocomplete!) to change entity names as opposed to clicking through several layers of UI for each one is awesome.

Aside from easily rolling out (parts of) my home automation to multiple environments (like my parents home, office, etc). The real use case for non-UI first is that with home automation software you often have to roll it out on the _same_ environment very often. Be it a corrupted SD card, broken state after software update, database bit rot, hardware RMA, etc, there are many reasons state gets corrupted or lost. So you either need to rely on a backup (if possible and hope it's up to date and works with the version you have installed) or configure everything by hand, again and again and again, via the UI, step by step, hope you don't forget that one setting you didn't write down. I rather have my home automation setup be build and deployed reproducible from a (VCSed) source.

Ah yes agreed, but I was thinking more of an export/import mechanism, that can be version controlled, diffed, etc, than full on cli- or programming-first interactions.