Just reread some of the above dialogue and I believe we're talking a related issue here.
I don't have this rigged up to be triggered by a Rule or anything just yet, I'm using your Device Notification button in the Device Config page. So you suggested to @albertjmulder that he put in an empty line or two at the start of the message. Of course that field under Device Notification doesn't allow for that so I just put an "s" followed by a bunch of spaces and then "sending email from HE". My Subject was HE Msg Relay, and what came out of that exercise was a concatenated subject line...but still no first line content in the email.
Ah okay - I have not looked at HEmail in a long while but will do so now. One thing from my other email device (Hubitat-DoNs) was the ability to add the subject/body IN the notification text itself. That way you could have one device and use it for a wide variety of dynamic notifications. Maybe I could add that functionality here as well.
Just wanna say, given all the brouhaha I've read over having this feature/not having this feature in HE after the demise of hosted SMS...your on-board solution seems short, sweet, and elegant enough to get the job done.
So are you referring to mail server account info loaded into the Device fields in the HE environment itself...or are you more highlighting that the message content is going "in the open". The latter is a manageable risk.
So I just added an HEmail device and set it up to point to my mail server and the body comes through. I am going to take another look at the sending process. Maybe there is an additional thing I can do to make it better. Also will look into making the subject/body dynamic via entering a JSON string in the notification text as an optional way of sending a subject and body - will leave the default as the current functionality.
As I noted, when I look at the raw source for the email I do see the line I put in for "text" (content) showing as the next line imediately after the SUBJECT. Refer to that above. When I inspect other emails the same way I do not see the "content/body" of the email in readable characters in that same location of the header info.
So at least the Device Notification field (as sent with your button on the Device page) appears to be sent in a manner that is PERHAPS interpret-able as a continuation of the subject ???
Maybe @albertjmulder can update on what he's seeing in his use.
So I made some updates for you to check out. I added some blank sends between the subject and body and also at the end as well. I removed an extra telnet close call that was unneeded and kicking off an erroneous error msg.
I added ability for text to be a json string with "Subject" and "Body" elements to allow for greater flexibility. Example - put this in the "Device Notification" box as a test:
{"Subject":"Subject 1","Body":"This is the body of the email, can use HE variables here (and in the subject line) too.."}
Whoops, I saw your changes on GitHub and was already in the process of loading the new Device Driver into a second hub I have.
I haven't tried the variable bit you added but the blank send(s) must have done the trick. I now have the body/content showing up where expected in the email.
I still saw the same error msg in the Events tho. "Disconnected. receive error: Stream is closed" followed by a "Disconnected, email sent". Maybe I picked up an intermediate copy before you pulled the extra Telnet session close outta there.
THANKS ! Donno how to send kuddos but you deserve them. Will try the variable Subject when I can.
That may the the "quit" I'm sending that closes the session before I actually tell it to close. Just posted another minor update that moved the logdebug around.
error entry as previously outlined is still showing prior to last "Disconnected", doesn't impact success of send
not sure how this worked itself out but before your work these email sending attempts would work to my standard email but when I tried to send to my cell they were getting bounced by my cell provider's use of barracuda. Could be coincidence but it is all working now!
For completeness and maybe (some) improved efficiency just uploaded yet another minor update to remove erroneous error message after sending, simplify messaging.
Note: under the device/events there is an event that appears called "receive error: Stream is closed" - this is normal expected behavior after the session ends. There should be no more errors appearing in the debug logs.
So I added this driver, and it has been working wonderfully. Only problem I've had is that since there's no "Date:" field in the SMTP header, the emails have been showing up in my mobile inbox as received sometime in 1969... which means they're not sorted with all the other received emails.
I think I fixed it as follows:
in the section that creates some definitions, I added the last line:
def msgData = "${state.EmailBody}"
def emlBody = ""
def emlSubject = ""
def emlDateTime = new Date()
Then, in the section where the actual SMTP Data is constructed,
def sndMsgs =[
"MAIL FROM: ${From}"
, "RCPT TO: ${To}"
, "DATA"
, "From: ${From}"
, "To: ${To}"
, "Subject: ${emlSubject}"
, "Date: ${emlDateTime}"
, ""
, "${emlBody}"
, ""
, "."
, "quit"
]
I added the Date: line.
Apologies for not knowing how to add this stuff to the github, I'm a network engineer, not a software coder.
I just got this up and running last night with a Postfix container on Docker as an internal relay to Gmail. This part was easy, the Postfix container took some work.
Just want everyone to know there are other deployment options available if they don't have a Raspberry Pi.
Those errors were typically happening at the end of the telnet session when I forced closed it. I removed that a while ago instead relying on just a quit command being sent.
Can you manually telnet to your postfix box with the same commands as in the driver?
