Skip to Content
Niagara 4Email service (Gmail)

How to Set Up the Email Service in a Niagara 4 Station Using Gmail

Configure the Niagara 4 Email Service with smtp.gmail.com on port 587 (STARTTLS) and a Google app password, then route alarms to an email recipient.

Email is still the simplest way to get BMS alarms in front of people, and Gmail or Google Workspace is a common choice for small sites and integrators. Google's security changes, however, mean that the "just enter your Gmail password" method no longer works. This guide explains how to set up the Niagara 4 Email Service with Gmail properly, how to send alarms and reports by email, and how to fix the errors engineers meet most.

How email works in Niagara 4

Email in a Niagara 4 station has three parts:

  1. Email Service, added to the station's Services, which holds one or more outgoing email accounts (SMTP).
  2. Email recipients, typically an Email Recipient in the Alarm Service, linked to one or more alarm classes, which formats alarm messages and sends them through the email service.
  3. Other senders, such as scheduled reports or program objects, which can also send through the service.

The station connects outbound to an SMTP server. It does not need any inbound ports opened.

Before you start: Google account requirements

Google no longer allows third-party applications to sign in to Gmail SMTP with an account's normal password ("less secure app access" has been retired). You have three realistic options:

Option What you need Best for
App password A Google account with 2-Step Verification enabled; generate a 16-character app password for the BMS Small sites, a dedicated BMS Gmail or Workspace account
Google Workspace SMTP relay A Workspace administrator configures the relay service, often restricted by the site's public IP Organisations on Workspace
Another SMTP provider Your organisation's mail server or a transactional email service Corporate sites

Use a dedicated account for the BMS (for example [email protected]) rather than an engineer's personal account, so alarms do not stop when that person leaves.

Creating an app password

  1. Sign in to the Google account that will send the alarms.
  2. Enable 2-Step Verification under Security if it is not already on.
  3. Open App passwords, create a new one with a recognisable name such as "Niagara BMS", and copy the 16-character password.
  4. Store it in your password vault. You will not be able to view it again.

Gmail SMTP settings

Setting Value
SMTP server (host) smtp.gmail.com
Port 587 with STARTTLS (recommended), or 465 with SSL/TLS
Authentication Required
Username The full email address of the sending account
Password The app password, not the normal account password
From address The same email address (Gmail rewrites other From addresses)

Step-by-step setup in Workbench

Step 1: Add the Email Service

  1. Open the station in Workbench.
  2. Open the email palette (Window > Side Bars > Palette, then open the email module).
  3. Drag the EmailService into Config > Services if it is not already there.

Step 2: Add and configure an outgoing account

  1. Expand the EmailService and add an outgoing account (SMTP) from the palette if one does not exist.
  2. Open its property sheet and set:
    • Hostname: smtp.gmail.com
    • Port: 587
    • Transport / security: STARTTLS (or SSL/TLS if using 465)
    • Account / username: the full Gmail or Workspace address
    • Password: the app password
    • From address: the same address, optionally with a display name such as "Site BMS"
  3. Save the station.

Field names vary slightly between Niagara 4 releases, but these are the values every version needs.

Step 3: Add an email recipient for alarms

  1. Open the alarm palette and drag an EmailRecipient into Config > Services > AlarmService.
  2. Set the recipient's To addresses (separate multiple addresses as the property sheet indicates), subject format and message body. Include useful fields: source name, alarm class, value, time and the alarm text.
  3. Link the alarm classes that should send email (for example Critical and High) to the recipient. In the AlarmService wire sheet, link each alarm class's alarm output to the recipient's input.
  4. Set the recipient's time ranges and days if alarms should only be emailed at certain times.

Step 4: Test

Generate a test alarm, for example by temporarily changing an alarm limit on a test point, and confirm the email arrives. Check spam folders the first time. Then restore the alarm limit.

Designing useful alarm emails

  • Send only alarms someone will act on. If engineers receive hundreds of emails a day, they stop reading them. Route low-priority alarms to the console only.
  • Use alarm classes by priority and audience: for example Critical-Engineering, Comfort-Facilities, Maintenance-Weekly.
  • Write subjects that work on a phone: "CRITICAL: Boiler 1 lockout – Main Plant Room".
  • Include return-to-normal notifications where they help close out incidents.
  • Consider SMS for critical alarms out of hours; Niagara SMS services can send through cellular routers or modems.

Sending reports and other email

Alarm notifications are the most common use, but the same email service can send:

  • scheduled reports, for example a weekly energy summary or a monthly alarm report generated by the station
  • history exports as attachments for energy managers who work in spreadsheets
  • notifications from logic, using program objects or components that send a message when a condition occurs, such as a plant running outside occupied hours

Use separate recipients and subjects for these so people can filter them, and keep attachments small: large exports are better delivered from the supervisor or a database.

Email alarm design checklist

Before handing over a site, check:

  • every critical alarm class reaches at least two people, by email and, for out-of-hours, SMS
  • nuisance alarms have been fixed or removed from email routing
  • recipients' time ranges match the people's working patterns
  • the sending account is dedicated, documented and its app password stored securely
  • the controller's network route to the mail server is approved and documented
  • a test alarm has been received by each recipient group

Troubleshooting

Problem Likely cause and fix
Authentication failed (535 error) Normal password used instead of an app password; 2-Step Verification not enabled; wrong username
Connection timed out Outbound port 587 or 465 blocked by the site firewall; DNS not resolving smtp.gmail.com; no default gateway on the controller
TLS or certificate error Port and security mode mismatched (587 needs STARTTLS, 465 needs SSL/TLS); controller clock wrong; trust store missing the server's certificate authority
Email sent but not received Check spam; check the From address matches the account; check Google's sending limits
Emails stopped after working for months App password revoked (for example after the Google account password changed), or the account was suspended
Some alarms not emailed Alarm class not linked to the recipient; recipient time ranges exclude that time

Check the controller's network settings

A JACE or IONA needs a default gateway and working DNS to reach smtp.gmail.com. Controllers on isolated BMS networks often have neither. On a JACE 9000 with two network ports, set the default gateway on the first interface only. Outbound SMTP may also need approval from site IT.

Check the time

TLS certificate validation depends on the correct date. A controller with the wrong date will fail TLS handshakes. Configure NTP.

OAuth 2.0 email authentication (Niagara 4.13 and later)

From Niagara 4.13, email accounts can use email authenticators that match the authentication methods preferred by major providers, Microsoft 365/Exchange and Gmail (Google Workspace):

  • a basic email client authenticator (username and password, which is what the app password method uses)
  • an email client secret authenticator (OAuth 2.0 with a client ID and client secret)
  • an email client certificate authenticator (OAuth 2.0 with a client ID and client certificate)

OAuth configuration uses the provider's authorisation server metadata endpoint (for Gmail, https://accounts.google.com; for Microsoft 365, https://login.microsoftonline.com/<tenantID>/v2.0) and the scopes the provider requires. Note that the OAuth client credentials flow is supported only for incoming accounts, so outgoing alarm email from Gmail is still most commonly configured with an app password or the Workspace relay. If your organisation mandates OAuth, involve the Workspace or Microsoft 365 administrator early.

Google Workspace SMTP relay

For organisations on Google Workspace, an administrator can configure the SMTP relay service (smtp-relay.gmail.com), typically allowing mail from the site's public IP address without a per-account password. This avoids app passwords on controllers, but needs coordination with the Workspace administrator and a fixed public IP.

Using Microsoft 365 or an internal mail server instead

Many corporate sites do not use Gmail. The Niagara configuration is the same; only the server details change:

  • Microsoft 365: organisations usually provide an SMTP submission endpoint or a relay connector. Basic authentication may be restricted by the tenant's policies, so ask the Microsoft 365 administrator for the approved method, which may be an SMTP relay restricted to the site's IP or OAuth-based authentication on Niagara 4.13 and later.
  • Internal relay: many sites run an internal SMTP relay that accepts mail from approved devices on the network without authentication. This keeps controllers off the internet entirely and is often the easiest option to approve.

Whichever route you use, document the server, port, security mode, account and approval in the O&M manual.

Security considerations

  • Use a dedicated sending account with no access to anything else.
  • Store the app password in your password vault; it is stored encrypted in the station.
  • Remember that resetting a station's passphrase clears stored passwords, including email accounts, so you will need to re-enter it.
  • Avoid putting sensitive data in alarm emails; they travel to phones and inboxes outside the BMS.

Frequently asked questions

What SMTP settings does Niagara 4 need for Gmail?

Host smtp.gmail.com, port 587 with STARTTLS (or 465 with SSL/TLS), authentication with the full email address and a Google app password.

Why does Gmail reject my Niagara email password?

Gmail no longer accepts normal account passwords from applications like Niagara. Enable 2-Step Verification and use an app password, or use the Workspace SMTP relay.

Can Niagara send alarm emails to several people?

Yes. Add several addresses to the email recipient, or create several recipients for different alarm classes and audiences.

Does the JACE need internet access to send Gmail alarms?

Yes, outbound access to smtp.gmail.com on port 587 or 465, plus DNS. Alternatively, relay through an internal mail server.

Can I use Microsoft 365 instead of Gmail?

Yes, using your organisation's SMTP settings. The Niagara configuration is the same; only the server, port and authentication requirements differ.

Can I send email alarms without internet access?

Yes, through an internal mail server or relay that the controller can reach on the BMS network, which then forwards the messages.

How many emails can Gmail send for the BMS?

Gmail and Google Workspace apply daily sending limits. A well-designed alarm strategy stays far below them; if you approach the limits, you are sending too many alarms.

Why did my email alarms stop working?

Common causes are a revoked app password, a changed Google account password, a firewall change blocking outbound SMTP, or a station passphrase reset that cleared stored passwords.

Does the email service work on a JACE and IONA as well as a supervisor?

Yes. Any Niagara 4 station can run the email service, provided the controller can reach the mail server through its network settings and the site's firewalls.

Should I use port 587 or 465 for Gmail?

Either works. Port 587 with STARTTLS is the usual recommendation; port 465 uses SSL/TLS from the start. Match the security setting in Niagara to the port.

Can each alarm class email different people?

Yes. Create a recipient for each audience and link only the relevant alarm classes to it.

Need help from a Niagara engineer?

If this guide has not solved the problem, contact the Tyrrell Products technical team on 01942 732819 or [email protected]. Tell us the controller or host type, its Niagara version and what you have already tried, and we will help you get the system running.