The header on every alarm text does not come from the HMI. The panel sends email, and whatever converts that email into a text message, usually a carrier email-to-SMS gateway or a mail server channel, adds the header and pays for it out of the 160 characters a single SMS carries. Change the destination address or the gateway's settings; never hunt for the header in the HMI project.
Every alarm text from the panel arrives with the same block of text on top: a From line, sometimes a subject marker, sometimes a gateway's own name. That header is not in the HMI project, and no project edit will remove it. The panel's messaging function is email; it never touches a text message directly. The header comes from whatever converts the email into an SMS, usually the phone carrier's email-to-SMS gateway or the SMS channel on your own mail server. This page shows how to tell which of them adds your header, what the header takes out of the length limit of a text message, and where the formatting actually gets changed. If alerts do not reach a phone at all yet, set the delivery path up first; that job is covered in Send HMI alarm emails to a phone as text messages.
Why does every text from my HMI carry the same header?
The header comes from the gateway that converts the panel's email into a text message. The HMI itself only sends email and never touches SMS formatting, so the From and subject lines you see arrive from the middle of the delivery chain.
Follow the chain. The alarm event makes the panel compose an email. That email goes to a mail server, then out across the internet to a gateway that accepts it and repackages it as a text for the phone network. The panel's job ends when the email is sent; every character after that belongs to the mail server or the gateway. The fact that the header is identical on every alarm is the tell. Alarm texts differ from one event to the next, so fixed text at the top can only come from a program in the middle, which stamps the same opening every time it converts a message.
Can I remove the header in the HMI project?
No, the panel's documented messaging function is email only, so there is no SMS header setting to find: editing the alarm text, the sender address or the subject changes what the email contains, and the gateway still adds whatever header its own rules call for.
Searching the project editor for a header field comes up empty, and that is the expected result. The header is not something the panel created, so it is not something the panel can delete. One kind of edit does help: where the gateway copies the subject or the body into the text, the words you type are the words that arrive, so a shorter alarm line makes a shorter text. The prefix in front of it stays.
Which gateway is formatting my texts?
Look at the destination address and the header text together: a normal email address means a mail server or forwarding service converts the message, while a 10-digit phone number at the carrier's text domain means the carrier's own gateway does the conversion and adds the header.
The header itself tells you which of the two you are dealing with. Match what you see against this list:
- Header repeats your panel's own sender address: an in-house converter, the SMS channel on your mail server or a forwarding service, is echoing what it received. The formatting control lives on that server, not in the panel.
- Header shows a sender name you never configured: a third-party forwarding service stamps its own identity on every message, and its account settings or fixed format own the header.
- Text arrives garbled, with missing spaces or visible markup tags: the email left the panel in HTML or with characters outside plain ASCII. Gateways expect ASCII text-only mode; HTML formatting or non-ASCII characters garble the message or stop it arriving.
- Long alarms arrive cut off mid-word or as two texts: the header plus the alarm text ran past the length of one message.
- Nothing arrives after a destination change: the email-to-text address is wrong for that carrier or the gateway refused the formatting. Re-check the domain before touching anything else.
How much alarm text fits after the header, in a worked example?
A single SMS carries 160 characters in the GSM 7-bit format, so every character the gateway spends on its header comes straight out of your alarm text before the first alarm word is sent.
The 160 figure is the SMS format itself: one text message carries 140 bytes, and 7-bit packing fits 160 characters into them.
Worked example. A press shop emails alarms from a panel with a 16-character sender address, through a gateway that prints the From line at the front of every text. Count the header: From: takes 6 characters, the sender address takes 16, and the space between them takes 1, so the header uses 6 + 16 + 1 = 23 characters. The alarm reads Line 3 oven alarm: temp 192 C at 14:07:33 ack at panel, which is 54 characters. Header plus text comes to 23 + 54 = 77 characters, inside the 160-character budget with 83 to spare, so the message arrives whole.
What moves that result:
- A longer sender address costs character for character: a 40-character address makes the header 6 + 40 + 1 = 47 characters and leaves 113 for the text.
- Stacked alarms add up: two alarms in one email double the text to 108 characters, and 23 + 108 = 131 still fits; three alarms reach 185, past 160, so the gateway splits the message or cuts the tail.
- One character the gateway cannot map into the 7-bit set, such as an accented letter, forces the two-byte encoding, and one SMS then carries 70 characters. The 23-character header leaves 47, and the 54-character alarm no longer fits: it arrives truncated or split. Keep alarm text to letters, digits and basic punctuation.
How do I send a clean text from the panel?
Change who converts the message, not the message: point the panel's alarm email at your 10-digit phone number at the carrier's email-to-SMS domain, so the carrier's own gateway produces the text and its published rules decide what the header line contains.
- Get the carrier's email-to-text domain from its support pages for the phone line that receives the alarms.
- In the panel's alarm notification entry, replace the forwarding service's address with the 10-digit number at that domain.
- Keep the alarm line plain ASCII: letters, digits and basic punctuation, no HTML and no accented characters.
- Send one test and read which part of the email the carrier delivers as the text, the subject or the body; put the alarm words in that part and leave the other empty.
- Trigger a real alarm and confirm the text on the phone before relying on the path.
If the site routes alarms through its own mail server before anything leaves the building, get the mail side healthy first; the most common failure there and its fix are covered in HMI alarm email error: it needs an SMTP server, not a webmail address.
Recommendation: send the panel's alarm email straight to the 10-digit number at the carrier's email-to-SMS domain when a test text comes back clean and complete, because one conversion by the carrier beats a chain that lets two services add a header. Keep the mail-server route only where you control that server's SMS channel and can switch off the sender line; in both cases leave the old destination configured until the new one survives a real alarm trigger.
How do I test it before the alarms go back in service?
Send one test message from the panel and read it on the phone before the change counts as done: the header must be gone, the alarm text must arrive complete, and a real alarm trigger must still deliver.
Work through the checks:
- The text shows no echoed From line and no subject marker.
- The alarm words arrive whole and readable, with no broken characters and no markup.
- A real trigger delivers. Fire the condition the controller watches; the trigger side itself is wired up in PLC email alerts from a Boolean event.
- A second alarm fired while the first is still active also arrives, because stacked alarms change the character count.
- The old destination stays configured until the new one passes, so an alarm during the change still reaches a phone.
What if the header still will not go away?
Then the conversion is happening inside your own mail system, and the fix moves from the panel to that server's SMS channel: gateway software exposes a setting that decides whether the From address is passed into the text, and switching it off removes the echoed sender line.
The knob has a documented name in at least one mail server: its email-to-SMS channel documentation names the option USE_HEADER_FROM as the switch that allows the From: address to be passed to the SMS channel. If your echoed header is the sender address, that is the knob that stops it. The same kind of option exists on other mail servers under their own names, in the documentation for their SMS or messaging channels.
If the header comes from the carrier's gateway instead, the carrier owns the format and there is nothing on the panel to override it with. Test what its gateway delivers and judge the result as delivered: a clean, complete alarm text with a small sender stamp is a working alarm path.
Keep the working notification path configured while you change any of this. A header is cosmetic; a suppressed alarm is not. Make the change when someone can watch the line, and confirm the first alarm after the cutover arrives on the phone.
The decision, case by case: the header shows your own sender address, so turn off the From pass-through on your mail server's SMS channel; the header shows the carrier's own stamp, so test the carrier's email-to-SMS domain direct and keep it if the text arrives clean; the header matches neither, so send a test from the panel and read the text on the phone, because the received message names its own source.
Questions
Why does a long alarm arrive as two separate texts?
A text longer than one message is split into segments of 153 characters; 7 characters of each segment carry the reassembly information, and the phone joins the parts for display. Some carriers deliver the parts separately, or drop the tail when reassembly fails. Cutting the alarm text so header and message stay within one message avoids the problem.
Does any HMI send SMS directly, without email?
Check the manual's communications section for the messaging functions the maker documents. The panel family this article describes documents email sending only, which is why no header control exists in its project software. A different controller that documents an SMS function will name its own message-format settings in that manual, and the header question then belongs to that function.
What should I ask the carrier before I change the destination address?
Ask for the email-to-text domain published for the receiving phone line, and what the gateway does with the subject, the body, HTML formatting and characters outside plain ASCII. Carriers publish the address pattern and the formatting rules on their support pages. Send one test message through the new address and read the text on the phone before alarms depend on it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.