A PLC, RTU or host application can use a 4G LTE modem to send direct SMS alarms for equipment faults, threshold violations and communication failures. This requires an SMS-capable modem or cellular module, compatible SIM service and carrier/network support; LTE data connectivity alone does not guarantee that SMS is available. The difficult part is not creating the text message. It is deciding when the alarm is valid, who receives it, how repeated notifications are controlled, what happens when the cellular path is unavailable, and what evidence proves that the alarm process worked.
That makes SMS alarm design a control-system problem first and a modem problem second. The field application should define the trigger, persistence or debounce rule, recipient, message content, retry policy and escalation path before the hardware is commissioned.
Build the alarm as an end-to-end state path: field condition → validated alarm → message request → modem response → retry, recovery or escalation. Do not treat “the SMS command was accepted” as automatic proof that the intended operator received and acted on the alarm.
An SMS is only one stage in the notification process
A useful implementation leaves evidence at each stage so a missed alert can be traced to the process logic, application, modem or network rather than becoming an unexplained field complaint.
1. Verify SMS and command support before writing the alarm program
Start by confirming how the host will control the modem. A device can be a perfectly valid LTE modem and still be unsuitable for a project if the intended PLC, RTU or application cannot access the command path required to create and monitor SMS requests.
The project team should establish three facts before building the rest of the logic.
Confirm that the selected modem provides a documented host-controlled method that fits the planned application architecture.
Determine what the application can record when a message request succeeds, fails or cannot proceed because the modem is not registered.
Separate message generation, modem acceptance and any available delivery-status evidence instead of combining them into one “SMS sent” flag.
Typical host-controlled SMS send sequence
For a modem or cellular module that implements the 3GPP text-mode SMS commands,
the host typically confirms network registration and SMS availability, selects text
mode with AT+CMGF=1, starts an outgoing message with
AT+CMGS="recipient", sends the message body and terminates the entry
as defined by the modem’s AT command manual. A successful request can return a
message reference, while failures may be reported as +CMS ERROR.
Treat that as a protocol pattern rather than a universal copy-and-paste command sequence. Registration queries, character-set handling, SMS service-centre settings, end-of-message control, response formats and delivery-status support can vary by cellular module, firmware, SIM service and network. Verify the exact implementation for the selected modem configuration before deployment.
A bench test is more valuable than assuming the workflow from a product label. Use the intended host, modem and SIM, send a controlled text and capture what the application can actually observe. That establishes the evidence available later during commissioning.
2. Make the SMS represent a real alarm, not every raw field change
One of the fastest ways to make cellular text alerts unusable is to connect them directly to raw events. A contact can chatter. An analog value can move above and below a threshold. A communications poll can fail once and succeed on the next cycle.
None of those automatically deserves an operator notification.
A sensor changes state, a threshold is crossed or a communications check fails.
Apply debounce, persistence, a defined communications timeout or another process-appropriate condition before the event becomes an alarm.
Once validated, store a stable active state that can drive notification, logging, reminders and recovery.
Create the first SMS only when the validated alarm enters the state defined by the operating team as requiring action.
At a remote pump station, for example, the high-level switch may remain active for several minutes. The PLC should not issue an SMS every time the program scans that input. It should validate the event, create one high-level alarm and then let the notification policy decide whether a later reminder is justified.
The same principle applies to equipment-room temperature and communications-loss alarms. A short excursion or one failed poll may not justify waking an operator. The alarm should reflect the site’s operational tolerance, not the update frequency of the PLC program.
3. Treat recipients, message content and repeat limits as one policy
Once the trigger is reliable, the next task is to make the notification useful to the person receiving it. Sending every alarm to every number creates noise without creating clear responsibility.
The exact format depends on the site, but the recipient should be able to identify the location, asset and condition without translating an internal PLC tag such as “Alarm 17.”
Recipient groups can also follow the operating structure. A process alarm may go first to operations, while a device or maintenance condition may belong to another team. Escalation should only add people when the condition or response time justifies it.
Repeat suppression is equally important. The first notification, persistent alarm, reminder, escalation and return-to-normal event should be treated as separate states.
There is no universal reminder interval. A high-consequence equipment trip and a low-priority maintenance condition should not inherit the same escalation rule just because they share the same modem.
4. Keep the process alarm separate from SMS delivery failure
The alarm can be valid even when the cellular network is unavailable. That distinction must remain visible in the event history. Otherwise a technician can see that the process fault happened but still have no evidence explaining why the text was not received.
One process alarm can produce two communication outcomes
Record the request time, modem response and any delivery-status information genuinely exposed by the implementation.
Keep the alarm record, capture the communications failure and follow the defined retry or escalation policy rather than silently discarding the event.
Retry rules need limits. One failed attempt may not be enough for a critical event, but an uncontrolled loop can release a burst of stale messages when network service returns.
Decide in advance how many retries are allowed, how long the application waits between them, whether the alarm is still relevant after it clears, and whether a persistent failure should trigger another notification path.
5. Test the complete alarm path before site acceptance
A phone receiving one test message is not a complete acceptance test. The project should prove the trigger logic, repetition control, network-loss behaviour and escalation path under controlled conditions.
Trigger a known condition
Confirm when the raw event becomes a validated alarm and verify any debounce, persistence or communications-timeout rule.
Follow the first notification
Check the selected recipient and message template, then record the SMS request and modem response available to the host.
Keep the condition active
Prove that the system suppresses uncontrolled duplicates and that any configured reminder occurs only when intended.
Remove the cellular path
Under controlled test conditions, confirm that the system records network or send failure rather than treating the notification as completed.
Restore service
Verify the retry decision for both an alarm that is still active and one that cleared while the network was unavailable.
The resulting log should retain enough evidence to answer basic questions later: when did the alarm become active, which recipient was selected, when was the SMS requested, what did the modem report, was the modem registered, how many retries occurred, and when did the condition recover?
6. Match the 4G LTE modem to the host that will send the alarm
The hardware decision becomes clearer once the control path is defined. For this application, the useful distinction is not “which modem has the longest specification list?” It is which modem gives the intended host a documented command path and the interface needed by the project.
Two E-Lins modem directions are especially relevant here because their official product documentation states AT command support. They are not ranked as better or worse; they fit different host-interface requirements. AT command support alone does not establish SMS command support, so confirm the exact cellular module, firmware, SMS command set, SIM service and carrier support for the ordered configuration.
M300 4G IoT Modem
The M300 is the more direct fit when the host architecture expects a USB modem and the application will control the cellular module through supported AT commands. That makes it relevant to PC-based controllers, industrial computers and other host-driven alarm applications.
M400 IoT 4G Modem
The M400 direction is relevant when the project needs more interface flexibility around the host connection. E-Lins documents AT command support together with RS232, RS485 and USB interface options, allowing the integration method to be matched more closely to the controller architecture.
If the project requirements differ from these two host-integration directions, continue through the industrial 4G modem for project deployment category rather than forcing the application into a model with the wrong interface or control method.
Confirm the modem against the real alarm workflow
The useful question is not only whether a modem “supports SMS.” E-Lins should be given the host type, interface, trigger logic, recipient requirement and expected behaviour during network loss so the exact configuration can be checked before deployment.
7. Prove the alarm behaviour before the site goes live
The acceptance test should leave enough evidence that another engineer can understand why an SMS was generated, why a second one was or was not sent, and what happened when cellular service was interrupted.
SMS alarm acceptance check
- Trigger: confirm the exact condition that creates the active alarm.
- Validation: verify debounce, persistence, reset or communications-timeout logic.
- Recipient: confirm who receives the first notification and who receives escalation.
- Message: check that site, asset and alarm state are understandable outside the PLC program.
- Repeat suppression: hold the condition active and prove that duplicate messages remain controlled.
- Network loss: confirm failed communications are recorded separately from the process alarm.
- Recovery: test what happens when service returns while the alarm is still active or has cleared.
- Evidence: retain alarm time, recipient, send request, modem response, network state and retry history.
The purchasing rule can therefore stay simple: define the alarm behaviour first, then select the modem whose documented command and interface capabilities support that behaviour.
Frequently asked questions
Can a 4G LTE modem send alarms without cloud software?
How can repeated SMS alarms be limited?
What should happen when the cellular network is unavailable?
Which events should be recorded for SMS alarm acceptance testing?
Send the project requirements before asking for the final modem configuration
The fastest route to a useful recommendation is to show how the alarm system will behave in the field. That lets the modem be checked against the real control path instead of being selected only because a specification mentions SMS.
With those points defined, the E-Lins team can confirm whether M300, M400 or another industrial modem configuration better matches the project.
