For mobile Native Apps, will push notifications be possible for alarms? If not can you add the feature?
We absolutely want to do this, but to get true push notification to work is a bit tricky, because for it to work, your gateway would have to route alarm notifications through the internet to a server that we owned and maintained. This means there some added complications, technically (route to the internet), financially (some sort of IA account required), and legally (SLAs, etc)
What about support for other Third Party Push services like Pushbullet or Prowl?
If I understand correctly, those have their own apps, right? So it wouldn’t really be pushing a notification that would bring up our app? I admit I’m not very familiar with their services.
There really seems to be three ways to go about it… 1) Roll your own, with all the REST APIs out there today it would be easy to just hook your own notifications through scripting, but that puts all the burden on us. 2) Module integration with 3rd party, this seems the best of both worlds as the module can have deep integrations, but also expose functional to be extended through scripting. 3) Native Ignition Push notification. This is certainly the cleanest and most elegant, but like you said complicated to maintain.
For option 2, I have worked with https://pushover.net/ before. It gives you a simple REST API to push notifications. The requests are paired up with an API key to connect to an account. Going this direction, the concept would be almost identical to the Twillo module.
…ACTUALLY, it looks like Twillo now supports Push Messaging… perhaps it is as simple as an update to the existing module. https://www.twilio.com/notify
I think most notifications support custom URL/Callback, so the push notification don’t necessarily need to come from the Ignition app, the Ignition app just needs a URL handler or something so when clicking on the notification it properly opens the Perspective app.
Exactly what I was thinking @ryanjmclaughlin got there first.
Ok, so we’ve already got that. The native apps have a custom url callback of
perspective://host:port/project (for HTTP)
perspective://host:port/secure/project (for HTTPS)
So you could certainly use one of these roll-your-own services. I still think that we should do it ourselves though - I don’t like the idea that you’d have to install a different app to get notifications.
If we wanted to send a text message which had a url callback to open a specific project in the native app what would the format of that text message looklike?
So to add to this, push notifications for alarms would be a really powerful and important feature. For my application (oil and gas) we have a control room that emails out tickets when issues arise, it would be ideal for us to just send a perspective notification to the users. I am not sure how or if a custom text notification would be different than an alarm notification but figured I would mention it.
Any news on this? Especially with Ignition Perspective?
I personally use an app called MQTT Push client.
And then in alarm pipelines send string to mqtt tag.
In mobile side subscribe to to that tag.
The app automatically push notifications that massage in my phone.
Push notification is definitely something we’re aware of and want to implement but it won’t happen soon. It requires us to run a 24/7 service in the cloud and while we’ve got our eye on offering various cloud services in the future we’re not there quite yet.
Good afternoon Kevin,
Has there been any movement on supporting native Push Notifications in Perspective?
If not, is there a suggested service or method to do this?
No, nothing has changed since this post.
I don’t think we have any suggested or endorsed service but the others who suggested workarounds might.
Checking back in on this a couple years later. Is there a plan to implement Push Notifications directly in the Ignition APP? This would be a powerful tool for our sites to implement for operators on the floor at a large site.
So far I've only seen co-app soluions that would use something like ntfy.sh | Send push notifications to your phone via PUT/POST and require a second app on the phone.
Sadly not much has changed. It's not not planned, but we still don't quite have it together enough to start building features like this that require running a high availability cloud service counterpart.
@Kevin would it not be possible to build something that is more homegrown and run out of the ignition install server itself? the ntfy.sh has the capability to be run locally from your own server, just freeware and the second app are some watchouts our company has for long term support.
Another app we use for this king of scenarios no subscription https://pushover.net/
Not exactly what you wanted (and me too) but might get your attention.
In my mind a proper solution for this, and for other cloud-based notification profiles I have in mind, doesn't involve you guys needing to expose your Ignition Gateway to the internet for it to work.
These services you are suggesting take the place of or our missing cloud service, at a literal cost, and creates a dependency on the rando company running these for what could turn out to be "critical" parts of your SCADA infrastructure...
I know the prevalence of all these push notification services make it look like an easy problem, but doing it right is a little more difficult.
Another thing to consider is that, unless things have changed, what you are allowed to use push notifications for is limited.
When I looked into this last, for example, delivering all your alarm notifications by push notification isn't actually allowed. What you can do is send a push notification that tells that app it needs to wake up and go fetch because there's some new batch of notifications or status available. But this means your gateway is reachable by the phone, so it only works if you're on the local network, or if you host Ignition in the cloud. What I'd rather see is that we run our own cloud-based service in the middle that both the gateway side and the app side talk to and make all this work seamlessly.