Monitoring critical equipment -- problem sending alerts outside internal network

[Bob_Schor]

We have an expensive piece of equipment where cooling is important.  One weekend, the filters in a water cooling line got clogged, cooling failed, and damage resulted.  We are installing flow meters in the coolant lines, I'm designing a monitoring/alerting routine, and am also wondering how to sound an alert (the previous outage occurred on the weekend -- an e-mail or text message alert to various operators could have averted the damage (as the overheating takes about a half day to do real damage, so week-ends are a case of "unfortunate timing").

I investigated sending e-mails via LabVIEW, and found two sets of routines, one involving LabVIEW's SMTP routines (found in the current LabVIEW Examples) and another involving .NET routines (developed about a decade ago, but still apparently functioning in certain situations).  I tried using these to send to my Gmail account, but got foiled by two-factor authentication (LabVIEW wasn't recognized as an authorized e-mail sender, or something like that).

Inside the organization, we use Outlook.  While typing up this Request for Help/Suggestions, I realized I could try sending the message via Outlook (rather than through an outside e-mail service) to e-mail addresses outside the Institutional Firewall (so the intended Recipients could receive it even if not connected through VPN into the internal Network).  I will try this tomorrow (when at work) and will also welcome suggestions from other Forum users who have encountered and solved similar one-way alerting transmissions, and will report my findings.

Bob Schor

[MichaelBalzer]

I've used LabVIEW's SMTP VIs for emailing on alarms (system reboots) via an internal mail server without any issues. Hopefully your internal mail server behaves the same way. I've also done both email + text messaging (using AT commands over a serial port to a mobile device) which provides redundant notification methods if the email server or internet connection is down.

For more extensive alarm notifications there's Win911, where alarms are automatically escalated if there was no acknowledgement of the alarm (send email/sms -> make VoIP call). Last I looked it talked via OPC with LabVIEW + DSC module.

[RavensFan]

I've been using the SMTP VI's in LabVIEW.

For e-mails coming from devices off our network, we've been using g-mail also.  Some keys were setting up TLS and port 587.  The extra authentication of gmail has been a nuisance.  I know just recently I came across a link in the google account that says" Access for less secure apps setting has been turned on".   I'm not exactly sure how I found that.  But it might may help you.

Another thing to do is try to send a test message through the account.  Then open up your g-mail account in the browser and see if there are any messages about "a new device" or something like that trying to access the account.  Then take whatever steps they give you to verify that it was acceptable.

As for devices on our network, it's been a while since I had to set up one of them.  Maybe even before our company was sold from one company to another, so IT settings may have changed.  But I believe I was able to use the company's SMTP mail address as long as I provided it with a FROM address of a valid e-mail address.

[Bob_Schor · Accepted solution]

OK, I now have it working.

As I "guessed" last night when writing the initial post from home, the main problem was using Gmail as the SMTP Service, as I got messed up in its Security.  I surmised (and both Michael Balzer and RavensFan agreed) that I might succeed with my organization's SMTP Service, so this morning I asked one of the Server Admins if we had one, and what port/protocols it used.

I then tried the shipping LabVIEW Example program, Send Email using SMTP Client.  It doesn't work -- someone at NI forgot the Principle of Data Flow, and forgot an Error Wire.  The corrected version is shown below (it's a "pure picture", not a Snippet, so it is "version-independent").  Now it will work as the nice Documentation suggests, closing the Session before (instead of after) the Session is configured.Add missing Error Line

Bob Schor

[Bob_Schor]

Chagrined admission -- after railing against Express VIs, I noticed that there was a Send Email Express VI that basically does what the cited (but flawed) Example Code does (but hides, within itself, such things as the SMTP Server, Port, Sender's Email, and Login Info), and it does it without errors and taking rather little Block Diagram space.  A Better solution ...

Bob Schor

[billko]

---

@Bob_Schor wrote:

Chagrined admission -- after railing against Express VIs, I noticed that there was a Send Email Express VI that basically does what the cited (but flawed) Example Code does (but hides, within itself, such things as the SMTP Server, Port, Sender's Email, and Login Info), and it does it without errors and taking rather little Block Diagram space.  A Better solution ...

Bob Schor

---

Not really.  You rail against MOST Express VIs, not ALL of them.  This Express VI, you learned, can be categorized as one of the few Express VIs worth using.  And as an added bonus, everyone here benefits from your discovery.  🙂