Cold chain alerts that still leave the building when the internet does not
A temperature excursion is only useful if the right person reads about it in minutes. SMS Deliverer turns the alarm your monitoring system already raises into a text message sent from your own SIM card, on a PC inside the site.
What a cold chain SMS alert is
A cold chain alert is a text message that reaches a named person when a fridge, freezer, cold room or reefer drifts outside its allowed range. The message has to arrive on a phone the on-call person already carries, without an app, a login or a data connection.
Reaches a phone, not a dashboard
SMS lands on any handset, including the basic phone in a pocket. Nobody has to install an app, sign in, or be on the same network as the site.
Sent from the site
The gateway, the modem and the SIM sit inside the building. That is the point: the alarm path does not depend on the internet link that the site may already have lost.
Proof per recipient
Each message carries a delivery report from the carrier, so you can show which on-call number was reached and when.
The gateway is not the thermometer
SMS Deliverer has no probe input and does not decide what "too warm" means. Your logger, BMS or monitoring platform owns the threshold, the delay and the escalation ladder. The gateway owns delivery: it takes a message that system hands it and sends it over a SIM.
How an alarm becomes an SMS
Five steps, from the probe to the on-call phone. Steps 1 and 2 run in your monitoring system; the rest runs in SMS Deliverer.
Your system detects the excursion
A probe reads 9 °C in a 2–8 °C cold room for ten minutes. The threshold and the debounce time live in your logger or BMS, exactly as they do today.
It hands the message to the gateway
Either an HTTP POST to the local API, or a row inserted into the SQL outbox table the listener watches. Both are on your LAN; nothing leaves the building at this point.
The gateway queues and encodes
The message is written to the local outbox, encoded for the modem and addressed with the TON/NPI values the destination needs. A template can carry site, asset, reading, duration and ticket number.
The SIM sends it
The connected GSM/LTE modem or Android phone submits the message to the carrier. One modem sends one message at a time; a modem pool or several phones send in parallel.
The report comes back
The carrier returns a delivery report per recipient. Delivered, failed and pending states are stored in the local database next to the message that produced them.
| Trigger path | What your system does | Good fit |
|---|---|---|
| HTTP API | POST the recipient, text and sending device to the local endpoint | BMS, SCADA or monitoring software that already speaks HTTP |
| SQL listener | Insert a row into the outbox table; the listener sends it and writes the result back | ERP, WMS and older systems that write to a database |
| Mail-to-SMS | Send an email to the local address the gateway watches | Alarm platforms that only send email |
| Scheduled batch | Queue a scheduled send from a CSV or Excel list | Daily digests and proof-of-life tests |
The HTTP API and the SMPP roles are documented on the setup guide. If your alarm platform already speaks SMPP, the built-in SMPP server accepts it directly.
What the on-call person sends back
A one-way alert tells somebody that something happened. A two-way thread tells you that somebody is dealing with it.
Replies arrive in the same inbox. The answer to an alarm lands in the gateway's shared inbox next to every other inbound message, and can be forwarded to a webhook, an email address or a Telegram group.
Your system decides what the reply means. The gateway delivers the text; it does not parse "ACK 12" or close your tickets. Send the reply by webhook to the BMS or ticketing tool, and let that tool record the acknowledgement.
Escalation stays where it belongs. "No reply in fifteen minutes, then call the area manager" is a rule in your monitoring platform, not in the SMS gateway. Keep the ladder in one place.
A worked example
- Probe in cold room 3 reads 9.4 °C for ten minutes.
- The BMS POSTs:
Cold room 3 at 9.4 C for 10 min. Reply ACK 3312. - Two on-call phones receive it; both get a delivery report.
- The technician replies
ACK 3312. - The webhook writes the acknowledgement into the BMS ticket.
When the site loses internet
This is the part that decides whether the design is worth anything on the night the link goes down.
| Capability | Without an internet link | Why |
|---|---|---|
| Alarm from a local BMS or logger | Still sent | The PC, the modem and the SIM are on site; the message travels on the mobile network |
| Text to the on-call phone | Still delivered | The recipient's phone only needs mobile coverage |
| Replies and delivery reports | Still received | Both travel over the carrier network to the local SIM |
| Local audit trail | Still recorded | Messages, states and timestamps stay in the local SQL database |
| Alarm from a cloud-only platform | Blocked | If the alarm source itself is remote, it cannot reach the gateway during the outage |
| Webhook to an internet endpoint | Blocked | An outbound webhook needs the link the site just lost |
| Remote support and updates | Blocked | Nobody can reach the PC until connectivity returns |
The honest limit: local sending protects the last hop to the mobile network. It cannot help if the system that detects the excursion is itself in the cloud and cannot reach your LAN.
Set it up, then test it before you need it
Six steps, all on the site PC. The trial works with the same hardware, so the test costs nothing but time.
Choose the sending channel
A USB GSM/LTE modem with an external antenna for a plant room or server cabinet, or an Android phone where a phone is easier to place. The modem is driven over its COM port with AT commands, so the device is your channel rather than a rented service.
Check the SIM where the modem will live
Coverage inside a cold room or a basement is not the same as coverage at the office desk. Test signal at the mount point before running cable.
Send two test messages
Install the software, detect the device, and send to both on-call numbers. Confirm the delivery report for each, not just the arrival on one phone.
Keep alarms outside quiet hours
The product supports scheduling and quiet windows for campaigns. An alarm queue must not inherit a marketing quiet window; give monitoring its own campaign and rate limit.
Connect the monitoring system
Point the BMS at the HTTP API or the SQL outbox table, and map the fields: site, asset, reading, duration, ticket number.
Fire a real test alarm
Raise a genuine excursion through the normal path and follow it end to end: message, reply, webhook, ticket. Repeat it monthly as a proof-of-life test.
Capability and limits
What the gateway does, and what stays with your monitoring system, your carrier and your SIM plan.
| Area | What it means in practice |
|---|---|
| Sensor input | None. The gateway has no probe port; thresholds, delays and hysteresis are configured in your logger, BMS or monitoring platform. |
| Escalation | Defined in the monitoring or ticketing tool. The gateway delivers messages; it does not decide who is next in line. |
| Delivery guarantee | Carrier delivery reports are the proof, not a guarantee. A message can be rejected, expire, or arrive late; the report says which. |
| Throughput | One modem sends one message at a time. A pool of modems or several Android phones send in parallel, bounded by the SIM plans and the carrier's rate limits. |
| Sender identity | The recipient sees your SIM's real number. Alphanumeric sender names depend on the carrier and the account, so do not build a workflow that requires one. |
| Offline operation | Local network only. There is no cloud console, no remote dashboard and no remote support while the site link is down. |
| Media | SMS only. MMS needs the Android channel and the Ultimate edition; a temperature chart is better sent by email than by MMS. |
Related reading: out-of-band IT alerting for the same local-send argument, clinic reminders for two-way patient messaging, and the Windows software overview for the sending engine itself.
Questions buyers ask
Does the software read temperature sensors?
No. It has no probe input. Your logger, BMS or monitoring platform reads the sensor and decides when a reading is out of range; the gateway only sends the message that system hands it.
Can it send an alarm when the internet is down?
Yes, if the alarm source is on the same local network. The gateway, modem and SIM are on site, and the message travels over the mobile network. A cloud-only alarm platform cannot reach the gateway during an outage.
How does the on-call person confirm the alarm?
They reply to the message. Replies arrive in the shared inbox and can be forwarded by webhook or email to your BMS or ticketing system, which records the acknowledgement. Keyword parsing is up to that system, not the gateway.
Can I prove that the right person was notified?
Each message has a carrier delivery report with its state and timestamps, stored in the local database. That shows which number was reached, not whether a human read the text.
Which edition do I need?
Sending SMS, scheduling, inbound replies and delivery reports work in every edition. The HTTP API and the SMPP roles are part of Ultimate; the SMPP server is useful if your alarm platform already speaks SMPP.
Is there a per-message fee?
No platform fee. You pay once for the license and your carrier charges whatever your SIM plan costs. Bulk pricing and SMS bundles are between you and the operator.