PushingBox API: Real Time Notifications for IoT Devices – Part 2

In previous blogs we introduced FileMaker’s support of iBeacons and the PushingBox API. We now cover the integration of a FileMaker App that will make use of the new RangeBeacons Script Step to search for an iBeacons UUID. When the UUID is found, you can use the PushingBox API and Pushbullet to send notifications to both Chrome and iOS devices. This functionality can also be used to send a file or photo to Chrome; it can also be used similarly to perform a script or other actions with the “Insert from URL” script, or to send variables in your notifications that are read from a sensor or device.

First, we will demonstrate sending a notification via the Insert from URL script step with the PushingBox service.

Follow the steps in the previous PushingBox post to set up the scenario and action.

Here we will set up an example that sends notifications on the temperature of a room using Pushbullet and the PushingBox HTTP API method where variables will be used for $room$ and $temperature$. The full message and title are: The $room$ temperature is $temperature$ degrees

image1-22

Remember that you will need your Pushbullet Token and Pushingbox DeviceID to make this work. This is the unique key that identifies the scenario you want to launch. The DeviceID can be found on the Scenario Page. You can also create more arguments to define custom notifications text using your own variables.

image2-24

Within FileMaker we can accomplish the notification with a single Insert from URL script step where the details of the script step are:

image3-26 copy

Below are the results on…

Chrome:

image5-28

iOS (iPad):

image6-30

iOS (iPhone):

image7-33

We will now use the App to scan for an iBeacon and send a push notification and file (to Chrome) when found. The scripts are:

image8-36

image9-39 copy

This will search for an iBeacon UUID and perform a script to send the message and file. Since the app uses the RangeBeacons Script, it is performed from FileMaker Go 15 as shown below performing searching for the iBeacon.

image11-41image12-43image13-45

The results on Chrome and iOS are featured below. You can see in the desktop notification that a zip file was successfully sent with the notification.

image14-47image15-49

The scenarios and possibilities with PushingBox are vast and when combined with the emergence of connected devices and the support of iBeacons via FileMaker Go 15. Revolution11 staff have been busy coming up with many different scenarios that will fill the needs of our clients!

Go to Part 1 of this subject.

Download a PDF of this blog here: PushingBox API Pt2

 

PushingBox API: Real Time Notifications for IoT Devices – Part 2

PushingBox API: Real Time Notifications for IoT Devices, Applications and Web Services – Part 1

PushingBox is a cloud service that sends notifications based on API calls — you can trigger the service by HTTP request (GET/POST) or email. PushingBox is called from almost anything, e.g., Arduino, Spark Core, IFTTT, email, SmartThings, an HTTP request or your own script. Dozens of services, such as emails, Tweets, SmartWatch notifications, Push Notifications (iOS, Android, WindowsPhone), Windows8 Notifications and MacOS Notifications can be utilized.

In a previous blog post, Revolution11 introduced iBeacons, Apple’s protocol that allows mobile devices (iOS and Android) to pick up signals from small sensors using the Bluetooth Low Energy (BLE) protocol. The uses for iBeacons are endless, and as our consumption of “stuff” from mobile devices increases, sensors such as iBeacons will deliver rich contextual content from everyday objects.

In this example, we combine iBeacons with PushingBox API and Pushbullet to send notifications to iOS devices and Chrome browser with a FileMaker solution.

Set-Up:

1. Go to https://www.pushingbox.com/ and sign up for an account. Notifications are created from an API call to the services supported by PushingBox. Next, configure the service you are sending the notification from. You can do it at the My Services page.

2. Add a service:

PB1

3.  Select the Pushbullet service:

PB2

The Pushbullet Service dialog box will prompt you to name the service and enter the access token used in the API call.

4. Download Pushbullet at this point by clicking on the link (1)

PB3

5. Signup for a Pushbullet account and Create an Access Token (2).  You can use a Google account to sign into the PushingBox and Pushbullet accounts making it simple and quick.

a. Enter the access token back in the Pushbullet service.

PB4

6. Create a “scenario” and add an action to which the service will use and eventually write the text to send. The action is essentially the customized information you will use in your scenario.

a. Go to “My Scenarios” and give the service a name of your choice and click “Add”

b. This is step is where you will get the DeviceID used in the API call. Select “Manage”

PB5

7. Select “Add an Action” and note your DeviceID:

PB6

Pushbullet or any other scenario you’ve set up will be available to add an action too.

8. Select “Add an action with this service

PB7

From here you can create the message you want to send or use variables if you want to send some customized information with your scenario.

PB8

Here we are creating variables for use in a FileMaker solution, in this example we create variables:

$MessageTitle$

$RSE_Message$

Be on the lookout for our next blog post where we will create the FileMaker solution and integrate it with iBeacons, PushingBox, and Pushbullet Web service. Revolution11 is continually seeking innovative solutions for our clients.

Download a PDF here: PushingBox API

PushingBox API: Real Time Notifications for IoT Devices, Applications and Web Services – Part 1

Using Sensors To Get Information Sent To Your Mobile Device

ibeacon copyiBeacon and Other Bluetooth Low Energy Sensors – Getting Information from the Physical Environment with Mobile Devices


FileMaker recently announced support of iBeacons with FileMaker Go. iBeacon is Apple’s protocol that allows mobile devices (iOS and Android) to pick up signals from small sensors using the Bluetooth Low Energy (BLE) protocol. In the case of the iBeacon protocol, devices can be associated with “things.” A sensor can be attached, literally, to any physical object, and by utilizing the unique identifier broadcast from the sensor, information about the object is fetched and sent to your phone.

For instance, a sensor is attached to a piece of art in a gallery and users passing by can quickly retrieve information about the specific artwork. You could also place a bunch of sensors on every item on every pallet of inventory on a truck, and the person receiving that inventory could tell if something was missing before even unloading the truck. Unlike barcodes or Quick Response (QR) codes, sensors do not have to be “scanned,” they are broadcast and have a range of about 70 meters, with the range on some sensors being configurable to greater or lesser distances. Users do not have to configure anything or make a connection to start receiving sensor data – simply open the app and nearby sensor information will be delivered to the device.

graphic-1

graphic2

graphic3

While iBeacon fulfills a specific need, it is not the only game in town. Increasingly, these specialized sensors have the ability to broadcast many protocols at once. Google has a competing protocol called Eddystone, which can broadcast four different packet formats (and with some sensors, you can use all four). Additionally, you can take advantage of all of this sensor goodness with a variety of web services:

UID – This is pretty much just like Apple’s iBeacon Protocol where sensors broadcast a unique identifier picked up over Bluetooth for mobile devices

URL – This format broadcasts a URL across the Google platform (in Google Play and in Google Chrome); these URLs are displayed without the user having to download any software

TLM – This format broadcasts Telemetric data such as battery voltage, beacon temperature, light and motion

EID – This format is for more secure implementations requiring a random unique ID, where the meaning is derived from the cloud resolver hosted by Google

It is also possible to broadcast custom packet formats from sensors.

All of these sensors come in a variety of form factors and capabilities. You can get coin-sized sensors, sticker-type sensors, and even sensors that can be embedded in clothing and washed. Imagine the ability to solve many business needs with sensors that can track movement, relay their location, give temperature readings, monitor light and motion, and retrieve information. It is now easier than ever to incorporate data from the physical environment with your business solutions.  The Revolution11 team is excited to incorporate the sensors when solving client needs — the uses for iBeacon and the other protocols are endless.

Download a PDF of this blog: iBeacon Sensors

Using Sensors To Get Information Sent To Your Mobile Device

Utilizing Twilio and ThingSpeak API in IoT Applications

blog graphic

Rapid Systems Engineering Lets Your Devices Talk To You

Rapid Systems Engineering recently posted about how they combined our solution that utilizes Twilio to automatically send notifications with ThingSpeak API and Infrared Sensors to create automatic messaging and data collection whenever any motion is detected out in the field.

You can read about it here.

Utilizing Twilio and ThingSpeak API in IoT Applications