Tell me more Internet of Things — Part 6— Google Cloud — User input & push subscription
How to push notification to the users using webpush package. Changing the app engine app and adding a separate cloud function
Part 1 | Part 2 | Part 3 | Part 4| Part 5 |Part 6 | … | Part n
We want our app to recognise interesting or certain limits from the device sensors and the ability to send them as notification to us. As we have only developed a web application we need to have the browser (in our case chrome) listen in the background for any messages from the device. In addition, we won’t have them send from our device directly to us, this will be done in the cloud function. To make things even more complicated we could potentially open the app on different devices which could lead to the users decision to get notified on different devices.
In our implementation we will limit that to one subscription for every registered device. Example — I open the app on my mobile and want to get notified there. Then I open it on my laptop and the subscription will change to the laptop if I activate it there.
Further we may like to get some feedback over the event from the user
For later implementation: This logged data should be used later in an system identification or diagnostic identification to predict or suggest events. This maybe done with simple linear interpolation or up to machine learning of highly nonlinear models.
Implementation summary
In our implementation we are creating a new
- Cloud function — which subscribed to the pub/sub from all registered devices. Once the
- Threshold — for a particular device is exceeded the cloud function looks into datastore for the subscription details from this device and pushes a notification via
- Webpush package — to the dedicated service worker of the dedictated browser.
- The app engine — has a new route which once the notification is clicked the user can enter feedback about the event
- The datastore — contains the subscription details and is as mentioned connected to the registered deice KIND from datastore.
- You can subscribe — to a and device event by simply opt in via the chart button.
Cloud function
For trigger detection and webpush
Only for better serviceability and in order not to overload the existing pubsub triggered cloud function we create a new one. But we could have used the existing one and extending this function.
This would be our trigger backend function only pushing this notification to the dedicated browser (Chrome) if certain thresholds are surpassed.
The entire concept of notification push delivery is based on service workers implemented in the frontend browser working even in the frontend device without the need to open the browser. Chrome supports this quite some time and we are building on this excellent tutorial
https://codelabs.developers.google.com/codelabs/push-notifications/#0
In order not just repeat this tutorial I try to explain the concept with my own words. You might have noticed recently an increase in those tiny notification request which you can either block or allow (depending on your site settings). Once you allow the side to send you notification it can do it without you opening the browser. On a mobile device that would mean you could get all the notification (without having an android app service but just the browser).
As seen in the second screen I just allowed the service to be added and in the console some logging can be seen. Even before the allowance was given the service worker was registered and the executable javascript here sw.js has been added to our front-end repro. Then once an event get routed to the service worker we can see a pop up notification as below.
Once we click this notification we get redirected to a page where we can leave the events feedback:
Which then should be written to Big Query and Datastore databases for storage (and later data analytics). Beside our new cloud function just triggering the push in case of exceeding our threshold we need to add a few lines and files to our app engine app. We like to add the notification enabling and disabling entry on the chart page. Here we just add a few lines and load our main-push.js javascript for handling the subscription. In order that our javascript file can be loaded in pug we need to add in app.js a public place for our files in the back end. That let us reference our front end javascripts to be loaded once pug renders the views.
So we trigger our notification service by opt in using a button on the chart page. Above the pug code. The only text changes once we disable or enable the service clicking the button.
We could create a seperate subscription KIND (database) as every subscription to every seperate browser on different devices (OS) can get seperate subscription. We just add the subscription details to our registration (tmmiot_device) device kind.
So everytime the browser subscribes to the notification it will override the old subscription details which leads to the new device will get the notification.
We added a new route “/subscribe” for adding the subscription information to the existing KIND for device registration to users.
Inside the cloud function once a threshold is exceeded the function checks whether there is a subscription for this device and if successful send via web-push the notification to this device / browser service worker.
In this implementation it is only possible to have one subscription per device. Which means you could either get the notification on your mobile device or your laptop but not both.
I like your comments, corrections and suggestions 👌.
