Just got it set up via custom SMTP, and it's working great for notifications and full e-mail via the GUI! 
What would be really helpful is extending this capability to custom apps and device drivers so we can send email directly (body and subject) from Groovy and not just through the GUI. I can see multiple uses where I would want to be able to send a few variables and their values via an e-mail rather than a sendEvent().
there is a notify fx in groovy that you can prompt for the notify device and then let the user pick the device to be used
I’m very well aware of the notify function and already incorporate that in my code.
That wasn’t what I was asking for. I’m looking for the ability to send e-mail directly via the new device driver rather than relying on the notification app. These are not the same things.
When your custom app uses a list of capability.notification via something like this:
input name: "notificationDevice", type: "capability.notification", title: "Send notification to these device(s):", multiple: true
and then does something like
notificationDevice?.each {
it.deviceNotification(notificationText)
}
and one of the notification devices is an instance of this device, then the text is sent directly as an email. No other notification app needed.
This is how the existing community drivers that provide this same function (like LGKv3 Sendmail and GCal Search) work.
i am NOT talking about the notification app.. you add a selection in your app or device driver to pick a notification driver (like an instance of this device) and then there is a devicenotification() method that sends direct to that device like you asked.. it has nothing to do with the notification app..
ie
That’s still a notification. The e-mail for a notification has this as the subject:
Whereas an e-mail allows for both a dynamic subject and message body.
The latter was sent through the device GUI.
Yes, the method you outlined does not require the notification app but we’re still talking about two different things. Using only a notification makes all the subjects the same. Being able to dynamically send the subject and message is different.
If the GUI didn’t already offer it rather than a single “test” notification button, I know the driver can already handle a dynamic subject line. Making that available in Groovy opens up additional options for status e-mails, notification classes (subjects), archiving the e-mail, etc.
yes and no my version of send mail allows you to override that in the message itself if you wanted to use on app to do it
ie
new changes to be able to modify/replace the From, to , subject or add a cc header
the syntax is rh-Header: value,
for instance to replace the subject form the hardcoded subject in your configurtion would be: rh-Subject: New Subject, Remainder of the message
There must be a comma after each replacment header directive.
same for to rh-To:, From is rh-From,
to add a CC header, it is rh-CC: email@email.com etc.
Notes: if you had a list of multiple to address in the configure only one can be in the new replacment header so that would override the entire list.
other notes, order is important if you want to replace all headers (hence the rh-headername) you need to put them in this order:
rh-From, rh-T0, rh-Subject, rh-CC .
You dont need them all, but if any are there the must be in that order as that is the order they are processed.
Otherwise the will be left in as part of your actual message.
4.91 added option for the subject header to be rh-Subject: or just Subject: to be consistent with ritchierich code base so you have
have one notification send through both implementations.
v 4.92
the original header replacement above still works
but added an alternative message based on ritchierich pseudo xml at the start of the message
ie
{header: value, header: value}, this is the message
or
{header: value, header: value. Message: this is the message}
both work.
Legal header values for replacement are: Subject: From: To: CC: Message:
order is not important.
example:
{Subject: new subject, CC:kahn-zzspam@lgk.com, Message:newmessage here,To: kahn-saved@lgk.com, From: kahn@lgk.com}, this is a test
or
{Subject: new subject, CC:kahn-zzspam@lgk.com, Message:newmessage here,To: kahn-saved@lgk.com, From: kahn@lgk.com}
Not in the latest beta. 
Ah… holding out on me, huh? 
I’ll wait. 
How about for SMTP2GO??
The existing drivers that did this (I linked to 2 up above) let you override the Subject: line (in the notification text, which your app could arrange). If you look up above, I've requested the same override be added to this an additional feature. Coming soon.
For newer users, should have instructions or a link to the help doc on how to create new devices with this driver on the initial post. I know how to do it so wouldn’t apply to me but there’s no instructions on how to actually create this driver anywhere on this post for anyone that doesn’t know how to create one.
On that topic, there probably should be an app created or a better way in the GUI to create devices that uses a Driver without an app. I feel like all of these drivers like this or the Weather ones, etc. are created all of the time but they are really hidden away under the Virtual Drivers list. I think you should look into a better way like for a new user to find these. Really something like this should be an Built-In App if you ask me, 6 months from now a brand new user will probably not know this exists.
Even established users could easily miss drivers like this that are added if they don’t see it posted in this Community site, there should be a better way to see a list of what is available with Drivers that have no built in app.
Excellent point! Will see what we can do.
@bobbyD I believe an app to manage notification devices would be useful. Whether pushover, SMS, email, etc it could walk the user through the required inputs since these can be a bit confusing.
I got this working with Gmail but it was a painful adventure. I had to search for “app password” in the search box at the top of “Security and sign-in” section to access it. @bobbyD Thanks for making this available.
A screenshot or instructions on how do I add the driver would be very helpful.
Since this is a driver, I assumed it was a Device I could add so I searched the list of devices for email and smtp but neither returned any results.
@bobbyD I saw that you all added a Proton option in beta. Just wanted to show you what happened once I got it setup.
Error sending email using Proton Mail (beta): SMTP STARTTLS is not supported by this hub firmware
For some reason I cannot get this to work with my ms-exchange server.
Debug logging:
dev:107 2026-06-12 11:17:37.175 error Error sending email using Custom SMTP Server: SMTP 504: 504 5.7.4 Unrecognized authentication type
dev:107 2026-06-12 11:17:37.174 debug SMTP response: 504 5.7.4 Unrecognized authentication type
dev:107 2026-06-12 11:17:32.153 debug SMTP response: 250 SMTPUTF8
dev:107 2026-06-12 11:17:32.148 debug SMTP response: 250-CHUNKING
dev:107 2026-06-12 11:17:32.143 debug SMTP response: 250-BINARYMIME
dev:107 2026-06-12 11:17:32.138 debug SMTP response: 250-8BITMIME
dev:107 2026-06-12 11:17:32.133 debug SMTP response: 250-AUTH NTLM
dev:107 2026-06-12 11:17:32.128 debug SMTP response: 250-STARTTLS
dev:107 2026-06-12 11:17:32.123 debug SMTP response: 250-ENHANCEDSTATUSCODES
dev:107 2026-06-12 11:17:32.118 debug SMTP response: 250-DSN
dev:107 2026-06-12 11:17:32.113 debug SMTP response: 250-PIPELINING
dev:107 2026-06-12 11:17:32.108 debug SMTP response: 250-SIZE 104857600
dev:107 2026-06-12 11:17:32.102 debug SMTP response: 250-XXX.XXX.XX Hello [XX.XXX.X.XX]
dev:107 2026-06-12 11:17:32.090 debug SMTP response: 220 F5_Relay exch06
dev:107 2026-06-12 11:17:27.069 info Sending email using Custom SMTP Server to XXX@XXX.XX
Would need to know what settings you tried. It looks like it is saying it supports STARTTLS, which is the default auth on the driver for a custom config.
