True Push Notifications Using Ignition

Aug 26

Ignition’s Perspective Module has a lot of functionality. From location tracking on mobile devices to multiple monitors on workstation computers, Perspective scales to meet any need you can find.

The one limitation we have found when using Perspective for a mobile-first solution is the lack of an integrated true push notification system. To be completely fair to Inductive Automation, this isn’t a limitation on their side from a technical perspective. While it could be done, Inductive Automation would need additional infrastructure—including hosting a server for the entire Ignition community—to generate push notifications with their native mobile apps.

Why Push Notifications Instead of Standard Ignition Notifications?

Here are a few reasons that you might want to use push notifications over the standard Ignition Alarm Pipeline using SMS/Twilio/Email notifications.

Not everyone at a facility has an email address, but most people have smart phones
- In high turnover environments, or when operators never use computers (other than the plant floor HMIs) not everyone will have an email address to send alerts to. Push Notifications fix this.
People with smart phones may have texting limits, and Twilio isn’t free to use at the corporate level
- Unless you are providing people with smartphones, you might run into issues where numbers get blocked due to the number of texts going out. And if you have thousands of users, even low cost options like Twilio will be costly over the long run. Instead, Push Notifications are free.
All of your users might not have accounts in your system
- If you are selling software as a service—or will have users all around the world—all the users may not be able to connect to your system using the native Perspective app. Using Push Notifications with custom mobile apps lets you get data into their devices without having to set up any backend infrastructure on the network side.
Most people are already comfortable with push notifications, and installing an app with a user account creation page is less of a hurdle than adding Ignition gateways and projects for many users.

How Push Notifications Work

At a base level, push notifications are pretty simple. You get a device ID from the user’s mobile device(s) that ties into their user account in your system. Then you generate push notification triggers that hit the relevant notification service backend—which handles sending the data to the device, which generates a notification for the user.

The backend system for iOS Devices is called the Apple Push Notification Service, and Firebase is the backend for Android apps.

You can certainly dive into the documentation and generate your own notification engine, or you can use any number of services (both open source and paid) to handle the interactions with the notification systems—reducing the overall development required to implement this functionality.

How to Get Started with Push Notifications

Get Developer Accounts
Develop the Apps
Deploy the Apps
Manage the Data

To get started, you first need to set up a developer account with Apple, and a developer account with the Google Play Store.

Once you have these set up, develop an app for each store. You can do this using the native development tools for both platforms (Xcode for iOS and Android Studio for Android apps) but then you need to manage multiple technology stacks and codebases.

Instead, at Corso Systems, we use a platform called React Native that allows you to write one app and deploy it to both platforms. This reduces the overall ramp up time on the mobile development side, and has a lot of overlap with React as a framework allowing us to build non-mobile app websites as well without having to learn an entirely new technology.

After you have developed the apps, you need to deploy the apps. You submit the apps to their respective app stores, get them reviewed, fix any issues, then release them into the wild.

Once your users can download the apps, you will need to manage the data. This is where the rubber really meets the road.

Users and Security

To manage notifications, your users need to create an account in your app and collect the relevant device ID from their device. This information will be stored in a database with their user information, and used to generate the notifications.

This means you will need some form of user authentication. This can be flexible depending on your needs, however we tend to use Active Directory at companies who also use Windows, or Google Workspace. Alternatives like Keycloak can be used for companies who need a 3rd party option.

Once your users create accounts and you grab the device ID, you simply need to pass that into the notification pipeline with the notification information.

Actually sending the notifications is covered in the relevant docs for each platform, or you may choose to use a system like Expo to handle the data flow.

Generating the Notifications

For our customers using Ignition as a backend system, we typically put push notification functionality on tag change scripts and alarm event scripts. In each script, we tie in the user schedule and alarm pipeline rosters, then determine which users need to receive a notification when one is generated. We then collect the device type and device ID for those users and generate notifications, sending it to both notification services using their APIs as an HTTP Post with the relevant information included in the headers and data of the call.

This process will generate the notifications, alerting the users. They can then interact with the notifications as needed to acknowledge alarms, capture relevant data, or go over to a machine to adjust a setpoint