Send HMI alarm emails to a phone as text messages

Can an HMI alarm reach your phone as a text message?

Yes, if your carrier runs an email-to-text gateway. The panel sends the alarm email to an address built from the 10-digit mobile number plus the carrier's text domain, and the carrier delivers that mail to the phone as a text message. The gateway is a mail server the carrier operates. It accepts a plain email, takes the body text and hands it to the network as a text. The panel needs nothing new. If it composes an email for an alarm today, the same email goes to a second address, and that address happens to be your phone. The address shape is public and the same across carriers: number, then the @ sign, then the carrier's text domain.

What do you need before you change anything?

You need four things: an alarm that already sends email to an inbox, the 10-digit number of the phone that should get the texts, the gateway domain from your carrier, and a recipient slot in the alarm notification settings. Assemble them before you open the project, so the change itself stays small:

• A working email alarm. If the alarm does not send mail yet, set that up first; PLC email alerts from a Boolean event shows the base configuration.
• The 10-digit mobile number of the phone that should receive the texts.
• The carrier's current gateway domain. Get it from the carrier's own instructions, and ask about message-size and account restrictions at the same time.
• A recipient slot. Most alarm notification setups accept several addresses per alarm; if yours accepts one, record the inbox address before you touch anything, so you can put it back.
• A mail route out of the plant. The panel has to reach a mail server or relay for any of this to move.

How do you write the phone number as an email address?

Write the mobile number as 10 digits with no dashes, spaces or parentheses, add the @ sign, and end with the gateway domain your carrier gives you. The whole address then reads like an ordinary email addressed to the phone. A United States number is written as 10 digits, so the address is number@domain with nothing else in the number part. The carrier's own page is the one to trust for the domain, because carriers open, rename and close these gateways over time. Before the first test, and again any time texts stop arriving, ask the carrier two things: whether email-to-text is still offered for your number, and what the current domain is. If the message comes back as undeliverable mail, the domain is usually the reason.

How long can an alarm text be?

Keep the alarm text at or under 160 characters, spaces and punctuation included. A message written only with the letters, digits and symbols of the GSM 7-bit alphabet fits in one text message up to that limit. A message longer than that arrives as two texts or gets cut off at the gateway. Which of the two happens is the carrier's call, so read the test message to see what yours does.

Characters outside the basic set, such as typographic quotes, change the encoding and cut the single-message limit well below 160. Stick to plain letters, digits and ordinary punctuation in the alarm template. Send one test, then read what lands on the phone, because whatever the gateway carries, subject included, is what has to fit. The words themselves are the panel's alarm text; writing operator text for HMI alarms covers choosing words an operator can act on.

How do you add the phone as a second alarm recipient?

Add the gateway address beside the email address that already works, in the same alarm notification recipient list, and change nothing else. The trigger, the acknowledgment logic and the mail server settings all stay as they are. The steps:

1. Record the current notification settings: the recipient addresses, the mail server or relay the panel uses, and the alarm rows that send mail. A photo of the configuration screens is enough.
2. Fire the approved test alarm once and confirm the inbox copy still arrives. This is the baseline you protect.
3. In the alarm notification settings, add the gateway address as an additional recipient for the alarms that should reach the phone, and leave the inbox address in place.
4. If the setup allows only one address per alarm, add a second alarm entry for the same trigger and give the copy the phone address, leaving the original entry untouched.
5. Change nothing else. The trigger conditions, the acknowledgment logic and the mail server settings stay exactly as they are.
6. Save the project and download it to the panel the way you normally do.

Can you show me a worked example of the full path?

Here is a 60-character alarm text that fits the limit with room to spare, followed by the arithmetic you can repeat for your own message template. A bottling line jams at the filler. The alarm event writes this body text, and the panel mails it to the inbox address and to the phone's gateway address at the same time:

ALARM: Filler line 3 jam. Station 12. Clear jam, then reset.

Count the characters in pieces and add them up: ALARM: is 7, Filler is 7, line is 5, 3 is 2, jam. is 5, Station is 8, 12. is 4, Clear is 6, jam, is 5, then is 5, reset. is 6. That is 7 + 7 + 5 + 2 + 5 + 8 + 4 + 6 + 5 + 5 + 6 = 60 characters, all of them plain letters, digits and ordinary punctuation from the standard set, so the message fits in one text with 100 characters of headroom under the 160 limit. The result: one alarm event, two recipients, the inbox gets the full email and the phone gets one 60-character text. If the line is later renamed and the template grows past 160 characters, the text arrives split or shortened, which is the signal to trim the template.

How do you test it and tell where a message dies?

Fire a real alarm, watch for the email and the text, and if either fails, split the path into four stages so you can see which hop dropped it: panel to mail server, server acceptance, gateway acceptance, phone delivery. Test from the real alarm event, because a message sent from a desktop mail client can reach the phone while the alarm's own recipient row is wrong, and the alarm event is the only test that exercises the whole chain.

1. Panel to mail server. The panel hands the message to its outgoing mail server. The panel's send log or mail diagnostics cover this hop; when the panel reports a send error, the DNS-first check for an HMI panel email send error is where to start.
2. Mail server acceptance. The relay accepts the message for delivery. If your mail route runs over a cellular router, sending HMI alarm emails over a cellular router walks the same hops one at a time.
3. Gateway acceptance. Send a short manual email to the gateway address from the same mail system the panel uses. If the manual message lands as a text and the alarm's message never does, the fault is in the alarm's recipient row, not in the carrier.
4. Phone delivery. The carrier turns accepted mail into a text. Nothing at the panel speeds this up or reports on it.

A sent entry in the panel's mail log covers the first hop only. The other three sit outside the panel, which is why the manual gateway email in stage 3 is the useful divider: it separates an alarm-configuration fault from a carrier fault in one send.

When should a text message not be the only alarm you rely on?

Treat the text as a convenience copy and keep the ordinary email alert in place. A text crosses your mail server and the carrier's gateway, two hops you do not control that can hold the message for minutes or drop it with no error reaching the panel. Keep a local indication, a stack light or a horn, for any condition that can hurt someone or wreck the product, and keep the inbox alert for every alarm that also goes to the phone. Retest after any mail system change and whenever texts go quiet. If the carrier closes the gateway, pull the phone address from the recipient list and carry on with the email path, which has no carrier hop in it.

Recommendation: Add the carrier's gateway address beside the working inbox address for alarms where a few minutes of delivery slack is tolerable, keep each alarm text at or under 160 characters with plain characters only, and remove the phone address the first time a test produces the inbox email but no text, because that pattern points to a closed or filtered gateway rather than a panel fault.

Questions