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 — last update 2 hours ago | Up, and nothing has arrived for more than 30 minutes. A quiet bot is not a fault: only the wording changes, never the state. |
| Connected and waiting — no updates received yet | Up, and nobody has messaged the bot since it started. |
| Polling is failing: … | At least two polls in a row errored, the last within two minutes, and nothing has succeeded since; the reason follows. A single error that the next poll recovers from is never shown. |
| Not polling for updates | Nothing is polling this bot — it is disabled, or never started. |
| Another instance is polling this bot token 1.0.8 | No longer reported — see below. |
| Telegram is holding N updates that this instance is not receiving 1.0.8 | No longer reported. The gateway no longer asks Telegram how many updates it is holding. |
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
Failed sends are counted too. New in 1.0.8 A send that missed at least one recipient adds to a failed count with the last reason — · N failed (last: …), as in · 5 out · 2 failed (last: …). Before, only successes were counted, so a bot whose every send failed looked merely quiet. A failure does not change the bot's state: the bot can be perfectly healthy and one chat id wrong.
The status has one source. 1.0.8 The connection monitor's token check and the gateway's own polling health both used to write it, so the badge showed whichever arrived last and a healthy bot flickered. The polling health now feeds the monitor, which alone sets the state, and a report that stops arriving expires instead of pinning an old state.
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".
Removed in 1.0.8 Earlier releases tried: a conflict from Telegram parked the poller for five minutes as Another instance is polling this bot token, and a periodic check reported any update Telegram was holding as Telegram is holding N updates that this instance is not receiving. Both fired on a single, healthy installation — the first on the gateway's own restart overlap, the second on a message that had simply not been collected yet — and alternated with the monitor's "connected", so a healthy bot flickered. Both were removed. A conflict is now ignored and the poll retried; one poll wins within a cycle.
If messages go missing while the status reads Receiving or Connected, look for a second installation using the same token.
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.
When a send fails part-way Changed in 1.0.8
Telegram and WhatsApp send one message per recipient. Until 1.0.8 a send stopped at the first recipient that failed, and the node's retry then sent the whole message again — so everyone who had already received it got it again, once per retry, and everyone after the bad recipient got nothing.
Now:
- A failed recipient does not stop the rest. One wrong chat id no longer silences the whole roster.
- A retry goes only to the recipients that received nothing, and only when their failure is the kind that can pass — within the node's own retry budget.
- Once anyone has the message, the node is not re-run. The pipeline's node retry, which would send to everybody again, does not fire. A send that reached nobody keeps the ordinary node retry.
- The result says who received it, who did not, and who got the text but not the attachment.
Email is unchanged: one SMTP transaction delivers to every recipient or to none.
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