A fresh start - choices

I’ve been playing with HA (docker) now for a few months. I have Google assistant set up, i have my MQTT server working, node-red docker etc.
I have some WLED devices, some Tasmota-flashed switches / power monitors, and I’ll be ordering some shelly dimmers if the reviews are good once the usual youtubers receive them.

So there seems to be many ways to achieve the same outcome with HA and with devices etc. and i’m not sure what paths to take.
I’m ready now to start getting serious with HA, which will mean removing all the ‘test’ devices etc that i’ve configured whilst I learnt the basics.

So far, i’ve used tasmota HA auto-detection (SetOption19 1). What’s your view on this? Should I use it for all devices or manually add each device in the *.yaml file? I can see benefit to doing it manually in yaml, but looking for advice. Some devices need *.yaml configurartion as they don’t support auto-detection. I’ve got a bunch or prevously auto-deleted devices that I now need to delete as they are no longer named what they were detected as etc.

Also, in Tasmota, do you usually set your topics to the device name, or the mac address? What’s the best choice?

And the frontend - since the whole UI isn’t drag/drop/click-click done and everything can’t be done without yaml, are you using *.yaml config files to configure the GUI, or are you using the GUI editor as much as possible and then manually editing the “raw config editor” to tidy up?

What is the recommended course to take for this stuff? As there’s 2 ways (GUI and *.YAML) i’m just not sure which path to take, and don’t want to redo everything in a year or two.

I have found that the most “manual” of choices (no MQTT discovery, YAML based lovelace/GUI) is where I end up eventually. That being said, starting with the more automated method doesn’t hurt anything, because there’s almost no work to do with the automated methods, so you’re just delaying the setup, not really doing any extra work.

Also, if you will likely have complex automations, or will need custom components and would like to avoid the difficulty of creating them with Home Assistant code, AppDaemon works wonderfully for me. I’m such a fan, in fact, that I joined the developer team. It’ll do it’s thing for simple automations as well, and you can use a combination of appdaemon and home assistant automations if you’d like.

The Shelly switches work great for me. So I’m excited about the Shelly Dimmers, too. I didn’t realize this was almost ready for release.

TASMOTA Autodetection: I don’t use it. I’ve had stuff in my config since before autodetection existed, and I never started. I’ve heard people complaining about it not working under certain circumstances, but I don’t have to worry about it!

MQTT topics: I usually set them to match the thing they control. I sometimes watch the stream of topics in mosquitto_sub, and I like to know immediately what I’m looking at.

Frontend: YAML all the way. I keep my config in a git repo for version control and the possibility of rollback. I had to edit everything manually since before the GUI option existed and I’ve never stopped doing that.

1 Like

Yes that’s what I’m thinking of doing. Do *.yaml files override the auto-generated files in the .storage folder? e.g. there is a person set up in the ‘person’ file in .storage folder.
Do I duplicate this in the configuration.yaml file to override the auto-generated stuff?

For lovelace YAML mode, you have to have this in your configuration.yaml file:

lovelace:
  mode: yaml

If I add that, what happens? Does it destroy all the current config and start using a config from a *.yaml file?

EDIT: I’m just reading the doc for this…

The old stuff doesn’t disappear, but it doesn’t get used anymore. It remains in the $/.storage/lovelace file.

Edit: At least it did several versions ago!

1 Like

I use the frontend for everything I can and only mess with yaml when I have to. This way I have less restarts (for integrations etc), and I understand how the frontend works when they make everything configurable through there. This method is easy to backup as well, even to git, I don’t understand the argument against it. The .storage directory is just a directory with json files in it. No different than a directory with yaml.

No it doesn’t destroy your config until you create a yaml file for your new layout.

What would be really useful is if the UI backed up the yaml file, then edited it directly when the UI is used to make changes. This way, there’s only one file to deal with, and it can be edited manually and with the UI.

Until then, from the docs, it looks like I can import the yaml to and from the UI / ui-lovelace.yaml file, and add/remove the lovelace: entry to switch between them.

A mix of json in the .storage folder and then yaml in the UI raw editor is a pain.

I agree, I’d also like it if the auto/UI stuff somehow interacted with or spit out yaml that I could then take as a template to edit my own config.

Re starting over, I built out my setup with HA in Docker (just because really), and have separate VMs for Node Red, MQTT, Grafana, etc. You could roll these all with HA via plugins or have HA by itself with all of these things off on one VM instead of individual ones like I do. I prefer this setup because invariably every 2 or 3 upgrades something happens and HA needs my attention just to get back to the level of function that I had BEFORE the upgrade. Breaking things out this way I minimize that by using MQTT as the middleware and doing all of the automations I can directly in Node Red. Since I haven’t had time to work on a pretty UI to put on tablets around the house, at this point the only thing HA is actually being used for is for integrations with things that I can’t get to speak MQTT directly.

-Joni-