Notification Providers
Three connection types exist only to send messages out: SMTP, Telegram and WhatsApp. They carry no tags and appear in no binding — they are credentials with a name, referenced by the notification pipeline nodes and by alarm notification.
They live under Connections → Notification, alongside the protocol connections, so their credentials get the same encryption, the same audit trail and the same "secrets never return to the browser" rule as a PLC password.
All three belong to the Notification module, wherever delivery is triggered from. → Licensing & modules
SMTP
| Field | Notes |
|---|---|
| Connection Name | e.g. Prod SMTP (SendGrid). |
| SMTP Host / Port | 587 for STARTTLS, 465 for implicit TLS. |
| Security | STARTTLS (587) · Implicit TLS / SSL (465) · None (plaintext). |
| Authentication | PLAIN · LOGIN · CRAM-MD5 · No authentication. |
| Username / Password | Required unless authentication is None. Many relays want the literal word apikey as the username and the key as the password. |
| From Address | Required — it is the envelope sender, so it is never left undefined. |
| From Name | Optional display name, e.g. QUBIQ Alerts. |
Use None (plaintext) only for a relay on the plant network itself. On anything crossing a network boundary, plaintext SMTP puts the account password on the wire.
Telegram
| Field | Notes |
|---|---|
| Connection Name | e.g. Ops Telegram Bot. |
| Bot Token | Create a bot with @BotFather and paste the token it gives you. |
| Default Chat ID | Optional. Used when a pipeline node does not name a recipient chat. -1001234567890 for a group or channel, or @channelusername. |
A bot cannot start a conversation. Somebody has to message it first, or add it to the group or channel you intend to notify — a token that is correct but has never been spoken to looks exactly like a token that is wrong.
What the status says Changed in 1.0.7
A Telegram connection's status is what the gateway has observed, not only whether the token
works. The two are different questions: a valid token on a reachable api.telegram.org passes the
credential check on an instance that is receiving nothing at all, and until 1.0.7 that was all the
status reported — so a bot quietly losing every message read connected.
| Status | Means |
|---|---|
| Receiving — last update 3 minutes ago · 12 in · 5 out | Messages are arriving; the counts are messages in and messages sent. |
| Connected and waiting — no updates received yet | Up, and nobody has messaged the bot since it started. |
| Another instance is polling this bot token | See below. Messages are going to the other one. |
| Telegram is holding N updates that this instance is not receiving | Telegram has messages queued for the bot and they are not reaching this gateway. |
| Polling is failing: … | The last attempts errored; the reason follows. |
| Not polling for updates | Nothing is polling this bot. |
A send-only bot counts too: every message a pipeline node delivers adds to out, so a connection that only ever sends no longer looks as inert as one that is down. The same status appears under every pipeline node bound to the bot. → Connection status under a node
One bot token, one installation
Telegram delivers a bot's incoming messages to exactly one poller per token and cuts off the other. Two gateways sharing a token — a test server cloned from production is the usual way — each receive some messages, and neither receives all of them. That is behind most reports of "sometimes the message is not received".
Changed in 1.0.7 When the gateway finds another instance polling its token, it stops for five minutes rather than fighting, says so once in the log and in the status, and resumes on its own once the other side stops. Before, the two knocked each other off about twelve times a minute, indefinitely. The fix is always the same: stop the other instance, or give each installation its own bot from @BotFather.
The same rule inside one gateway: two Telegram connections with the same token cannot both poll. The second is skipped and the log names both connections.
Also in 1.0.7, an idle bot no longer drops its connection on the slightest network latency. A quiet bot was the one most likely to miss a message, because its long poll ran to the full deadline and raced it.
Disabling a Telegram connection
Disabled stops the bot being polled at all. Changed in 1.0.7 Before 1.0.7 a disabled Telegram connection went on polling for the life of the process — so switching it off on a second server, the obvious cure for a shared token, did nothing. The bot still appears on the Messaging tab of each user's profile, marked as disabled rather than vanishing — a bot that silently disappears reads as a deleted connection — and a join link cannot be created for it.
WhatsApp
WhatsApp goes through Twilio.
| Field | Notes |
|---|---|
| Connection Name | e.g. Twilio WhatsApp (main). |
| Account SID | From the Twilio console. |
| Auth Token | The account's auth token. |
| Sender Number | The E.164 WhatsApp sender, e.g. +14155238886. Either this or a Messaging Service SID is required. |
| Messaging Service SID | Optional, used instead of a sender number. |
| Twilio Sandbox | On a trial account, turn this on to use Twilio's shared sender. |
| Default Template Content SID | Usually required — see below. |
Many Twilio accounts refuse a freeform WhatsApp body outright (Twilio error 21654). The fix is a
Content SID from your own Content Template Builder. Copy one from your account — a SID taken
from documentation or from another account will not work.
Editing a secret
All three follow the platform rule: leaving a secret field blank on edit keeps the stored value. The placeholder says Leave blank to keep. A secret is required only when the connection is first created.
Secrets are encrypted at rest and are never returned to the browser — the form shows that a token is present, not what it is.
Disabling a provider
Switch Enabled off and nothing sends through that connection. Changed in 1.0.7 A pipeline node that uses it fails with an error naming the connection, rather than quietly not notifying — before 1.0.7, a disabled SMTP connection went on sending mail, because the senders build each message fresh and never read the flag. → A node on a disabled connection fails
A connection can now also be created disabled: saving a new one with the toggle off used to store it enabled.
See also
- Connections overview
- On-Call Roster node — pick recipients by who is on shift, rather than by name
- Configuring alarms