This is part of a series of posts related to My Internet of Things and MobileFirst adventure. An index to all posts can be found at the end of the first post.
When we left of in the last post, I had a Raspberry Pi that is capable of taking a picture using its camera and storing that picture in a file. It can also sense that a physical pushbutton has been pressed – a doorbell. I also have my Bluemix services configured to manage Push notification requests and to broker IoT messages. Let’s start wiring things together by configuring Push notifications.
Build an iOS app that can receive push notifications
Note: This app evolved and changed a lot as I kept changing my mind on how I wanted to do things. Again, you may not see why I decided to implement things the way I did until later. Just play along for now.
I’m writing a Native iOS app in Swift. I’ll share the entire app in GitHub at the end of this series, but for now I will just show you code snippets of the relevant parts.
To receive remote push notifications, mobile apps must register to receive them. There are really two parts to this, registering with the Apple Push Notification Service to enable the app to receive notifications and registering with IBM Push Notifications service to enable it to send the requests on behalf of the Raspberry Pi app.
Register for remote notifications with APNS
The following code defines two notification actions and registers them with APNS to enable the app to display alert boxes with these buttons, play sounds and update badge counts in response to remote notifications:
You call this procedure from the AppDelegate’s didFinishLaunchingWithOptions method.
Register the device token with IBM Push Notifications service
You know registration with APNS was successful when the system calls your AppDelegate’s didRegisterForRemoteNotificationsWithDeviceToken method, so here’s where you register with IBM Push Notification service, passing along the device token.
Again, realize that this is not complete code, but rather just the important parts.
Invoke a Push notification from the Raspberry Pi
I’m going to change up the Node-RED flows that I created in Part 4. The flow I had created caused the Pi to capture a picture as soon as the doorbell was pressed. I am going to have Node-RED only send a push notification to the app when the doorbell is pressed. The picture won’t actually be taken until the user requests it in response to receiving the Push notification on the iPhone app. No, I don’t think this is the best design either, but again, I am using this as an opportunity to learn as much as I can about IoT, so this design will enable me to eventually send MQTT commands from the app to the Pi.
There is a Node-RED node package that sends push notification requests to the IBM Push Notifications service. But what I found is that this node only accepts a simple string to use as the message alert string. The IBM Push Notifications service can optionally accept a JSON object that defines a number of other items. I would like to provide some of these other items in my Push message so I am going old school and using an HTTP node instead. This additionally illustrates how the IBM Push Notifications service can be invoked with a simple HTTP POST.
Raspberry Pi Node-RED flow
I modified my Node-RED flow to the following:
The “send notification” and “push” nodes are new and require a little explanation.
HTTP Request node
I did not customize this node at all, with the exception of naming it. The address, headers and content of the message will be provided in the incoming message from the function node.
Send Notification function node
- Line #3: The pushbutton will send a message (“1”) when pressed and a message (“0”) when released. Also, in order to simulate a button press for testing, I added a timestamp Inject node as an input to the node as well. I only want the node to be triggered when the payload is NOT 0 – meaning either the pushbutton was pressed (not released) or the message is a timestamp.
- Line #5: This request will use the HTTP POST verb
- Line #6: The URL address of the request. You will need to replace “your-appID-here” with the AppGUID from your Bluemix application
- Line #7: The appSecret HTTP header value needs to be the appSecret from your Bluemix IBM Push Notifications service.
- Line #8 – #22: This defines the payload message that will be sent to the IBM Push Notifications service. For a full explanation, click Model to the right of body at https://mobile.ng.bluemix.net/imfpushrestapidocs/#!/messages/post_apps_applicationId_messages.
Once Deployed, clicking on the timestamp node should cause the function node to create a message and the push node to send it. You can confirm by verifying the output of the msg node in the debug view. You should see a statusCode of 202 and a header x-backside-transport value of “OK OK”.
Assuming you have added the code above for registering for remote notifications and registering the device token with IMFPush to even a simple iOS app, you should also see the notification appear on your device.
Diagnosing problems with Push notifications is difficult. You either get the notification on the mobile device or you don’t. There are no diagnostic messages returned from APNS or log files created. The most likely cause of a push not finding its way to your phone is that the SSL certificate wasn’t created or installed properly.
The next thing is to set up the basics required for the app to request a picture and the Pi to respond by sending it to the app via IoT Foundation.
That will be the next blog post in this series.