I needed to do something with SMTP today and seen I have to do it by the config file.
Something that bugs me is it seems this would be extremely simply to add into a UI interface. Is there a reason why this hasn’t happen? Or is it because it’s one of those things no one remembers or really pushes for?
Probably as if you’re enough if a sysadmin to want email notifications via SMTP, YAML isn’t that much of a big deal.
I suspect most folk use another messaging platform, such as the HA phone app, so there’s not the dev interest to take the integration to Platinum.
I set my SMTP notifications up with YAML a few years ago. Just yesterday, I added two new things that I wanted to receive email alerts for. Before I enabled those new alerts, I wanted to check the email recipients list. Long story short, I spent about 10 minutes combing through the web UI’s options looking for the SMTP config before remembering that it is one of the only things still in YAML on my HA instance… 
I think SMTP is a perfect example of things which should be set up in a configuration file rather than the UI.
It’s not something you do often, so you’ll probably need some sort of notes or documentation anyway. But it’s one of those things you probably will want to copy-and-paste to make a new entry. That’s so much easier than stepping through a dozen click-pulldown-select-type-click steps, and having to remember exactly what you entered last time.
I’m sorry, but shifting everything to the UI is making things much harder in a lot of ways. In a config file like YAML or whatever, everything is there, visible at once. You can find things, you can compare things, you can copy and paste things. You can copy the file, or parts of the file, off to keep as a record of what you’ve done before, or plan to do in the future, or share with other users.
Having to step through multiple UI steps to do one thing, especially something repetitive you need to do over and over, is slow and error-prone. Likewise, being able to do a mass find-and-replace in a file is much easier than opening each object one by one and, again, going through all the clicking and selecting.
I’m all for making things easy for beginners. But not at the expense of functionality. People who actually use HA every day should be a higher priority than those who are just taking a casual first glance.
It was attempted 2 years ago, however there issues with the notify platform. I believe those have been fixed with the introduction of the notify entity. So all it needs now is someone to do the work.
Because this integration requires a connection to an outside source and username/password, this would likely transition to a UI only integration.
This could easily offer a migration as well. There aren’t too many options so they’d all fit in the UI.
TLDR: Just need someone to do the work to bring it to the UI.
IDK my problem with it and why I had to is things like Gmail native thing doesn’t support images.
Like I hooked up my robot vacuum and figure if it got stuck or whatever, it can email me what happen and the map showing me where it is. I spent 2 hours on this before I figured out the native gmail integration won’t accept images.
Looking around I’m far from the only one that ended up having to use SMTP purely for this.
I’m asking because I don’t know if I’m missing something.
But isn’t your stance wrong? Like isn’t the only thing needed for a UI to work is basically the
And then for power users, what is to prevent them from using what they are using now?
Like I don’t understand why the hard stance against a UI approach and what it would break.
Fair question. No, I don’t think I’m wrong. But I also don’t think I have all the answers, nor do I speak for everyone. Just my take.
First of all, what prevents power users from continuing to use what they’re using now is simple: Becaue it’s sometimes taken away, replaced by something less functional, and some would say, inferior.
Right now I can take whole automations, whole chunks of config files (such as an SMTP definition) and copy it, paste it, edit it, do bulk find-and-replace functions on it, and even post it to this forum, or to an AI bot, to help debug it.
None of that works with multi-step, click, point, select, type UI processes.
Admittedly, it’s a personal preference. My own preference is not to “dumb down” a configuration process just to make it less intimidating for new users. Especially when that means removing existing functionality. Take this to the extreme and you end up with a system which is very easy to learn but does nothing. The value of HA is that it can be built into something very complex and capable. Trying to make it so simple that anyone can jump in and use it on day one is not going to help anyone.
I was thinking they would just do both. Like SMTP is pretty much not going to change as far as I can tell. The support for it in the config is already there. But this other will just act more than less the same.
Like the system can point to whichever. Kind of like how you can make buttons or other things directly in the config or through the UI
Maybe I’m oversimplifying it.
Anyways, thanks for the reply
That’s not the way it works. Integrations migrated to the UI config flow lose the ability to be configured in yaml. Existing yaml for that integration is migrated into the UI & original code is ignored when this happens.
In fact, as soon as you upgrade to the HA version with UI support, you’ll see a warning telling you something like:
"Configuring <your_integration> using YAML is being removed. Your existing YAML connection configuration has been imported into the UI automatically.
Remove the <your_integration> connection and authentication keys from your configuration.yaml file and restart Home Assistant to fix this issue."
Don’t get me wrong. Making thigs easy is good.
The problem is, making things less complicated may not be.
This isn’t unique to HA. I go back to the days of green-screen terminals. Some poor user had one job to do; move a stack of papers from the “In” box to the “Out” box. They had to enter the data into that screen. The fewer times they had to move the cursor, type, hit Enter, answer an “Are You Sure” prompt, open a new screen, whatever, the better. I had users with stopwatches who would call and tell us how many milliseconds per transaction a change would cost them. Time is money.
Unfortunately making things efficient for experienced users can result in a longer learning curve for beginners. It’s tempting to explain each and every step on-screen, to lead the user step by step, explain all the reasons they might want to select different options. Sure, it takes a little longer, but this way anyone can do it, and casual users won’t complain that it’s too complicated.
But if we’re not careful, what used to take an experienced user seconds will now take minutes.
Here’s another example from history: Before turn of the millennium, Micro$oft had some great office software. They used to do time-and-motion studies, watching actual users do actual work, trying to minimize the number of clicks, drags, prompts and new windows. Users became very efficient with those programs, and actually looked forward to new versions as new features were added and existing ones made easier.
But then something changed. No more studies of how people used the software. Every version had to have a New! Exciting! look. “Designers” had taken over the update process. Menus were moved around, functions were renamed or buried, key actions were replaced by multi-click menu pull-downs, and the whole thing was made more appealing to “influencers” and beginners who didn’t really have any use for the more complex functionality. Users now almost universally dread Micro$oft version updates.
I don’t want to see HA go down that path. Of course HA can be improved. And of course we want it to look new and trendy to attract beginners. But not at the expense of committed users who have built complex systems that do exactly what we need them to do.
THIS.
And when people lose the ability to config through code… They get QUITE hacked off about it. It’s not as easy as just. Someone throw it in the UI.
Op in short. This isn’t windowws. There are some construct considerations that need to be made and something like email isn’t just a set it up for the user thing. It’s setting up an integration. Which then falls into archetecture considerations.