Connect Freescale Devices with ARM mbed Device Server and bip.io
I’m writing this from the plane while traveling home from the ARM TechCon 2015 conference. ARM has a vibrant community of IoT innovators, and ARM TechCon was a great event where wot.io were finalists for the Best IoT Product award and hoped for a repeat win to back up our 2014 Best of Show award. Congratulations to our partners at Atmel, though, for beating us out in the end. Of course, we like to think we helped nudge them ahead by featuring Atmel hardware as a part of our demonstration. We’ll get them next year, though ;-)
On the final day of the Expo, I happened to be chatting with some folks from Freescale—another wot.io partner and fellow ARM mbed Zone exhibitor, not to mention Best in Show and Reader’s Choice award winner! The folks from Freescale had seen how we were already routing sensor data from their devices to a complex array of data services, and wanted to know how difficult it would be for Freescale developers to harness a tiny sliver of that power—say to connect their devices to ARM mbed Device Server and another data service like bip.io—and most importantly, to get it working quickly and easily.
Unfortunately, the Expo hall was closing and we were packing up our respective booths; but I told him that what he asked should be easy since the work was really already done. I promised to pull together some sample code and instructions on the plane the next morning.
So that's just what I'll try to do in this post.
ARM TechCon Demo
The following is a block diagram showing the array of data services that we demonstrated at the event.
The full demo really deserves a post of its own. For now, I just want to outline the simplest possible way to hook up a Freescale device to ARM mbed Device Server and bip.io.
Connecting the FRDM-k64f to ARM mbed Device Server
In a previous post, we've already shown how to get a Freescale FRDM-k64f board running ARM mbed OS connected to an instance of ARM mbed Device Server. So just to keep things fresh, this time we'll start from an existing ARM example project.
The mbed OS Application
As expected, it was quite straightforward to update the existing example code to work with wot.io. (In fact, the code changes were quicker than the updates to the README!) You can find the source code on Github.
In source/main.cpp
we only needed to change the location of our mbed Device Server
const String &MBED_SERVER_ADDRESS = "coap://techcon.mds.demos.wot.io:5683";
and then, since our ARM TechCon demonstration server was not using TLS, we need to remove the certificate-related attributes and instead set the M2MSecurity::SecurityMode
to M2MSecurity::NoSecurity
when we create the register server object:
M2MSecurity* create_register_object() {
// Creates register server object with mbed device server address and other parameters
// required for client to connect to mbed device server.
M2MSecurity *security = M2MInterfaceFactory::create_security(M2MSecurity::M2MServer);
if(security) {
security->set_resource_value(M2MSecurity::M2MServerUri, MBED_SERVER_ADDRESS);
/*
security->set_resource_value(M2MSecurity::SecurityMode, M2MSecurity::Certificate);
security->set_resource_value(M2MSecurity::ServerPublicKey,SERVER_CERT,sizeof(SERVER_CERT));
security->set_resource_value(M2MSecurity::PublicKey,CERT,sizeof(CERT));
security->set_resource_value(M2MSecurity::Secretkey,KEY,sizeof(KEY));
*/
security->set_resource_value(M2MSecurity::SecurityMode, M2MSecurity::NoSecurity);
}
return security;
}
We should now be able to build our mbed OS application using yotta
. (see the README
for instructions). In my case, I think I'd better wait until I get off the plane before I start programming blinking devices with dangling wires to test this out, though.
Connecting to wot.io data service exchange
To view or otherwise transform or integrate our device data using http://bipio.cloud.wot.io, a popular web API automation tool available on the wot.io data service exchange, follow these simple steps:
- Sign up for a free account on bip.io if you do not already have one.
- Create a new workflow (called a "bip") and name it
freescale
. - Select "Incoming Webhook" as the trigger for this bip, as we will be instructing mbed Device Server to send it notifications via HTTP.
- For now, add a simple "View Raw Data" node and set its value to the "Incoming Webhook Object". This will allow us to see the messages being received from the device. Later on, of course, you can do much more interesting things with your workflow.
Setting a notification callback in mbed Device Server
Since we want to have mbed Device Server send device notifications to bip.io, we need to register a notifcation callback via the REST API. The general form of the API call is
curl -X PUT 'https://mds.example.com/notification/endpoint' -d '{"url":"http://callback.example.com/path"}'
to have notifications sent to "http://callback.example.com/path". But in our case, we will also need to supply some security credentials for the API call and some custom headers for the callback in order to make everything work for bip.io. In addition, once we have registered our callback, we need to subscribe to notifications for a particular resource. Recall that our dynamic button-press resource was identified as /Test/0/D
in main.cpp
. The final API calls have been captured in the script bipio_subscribe
for convenience:
#!/bin/bash
# Simple script to simulate a device sending
# sensor readings to a bip.io workflow automation
MDS_USER=freescale
MDS_PASS=techcon2015
MDS_HOST=techcon.mds.demos.wot.io
MDS_PORT=8080
BIPIO_USER=techcon
BIPIO_TOKEN="dGVjaGNvbjp3b3RpbnRoZXdvcmxk"
BIPIO_BIPNAME=test
BIPIO_ENDPOINT="https://$BIPIO_USER.bipio.demos.wot.io/bip/http/$BIPIO_BIPNAME"
BIPIO_HEADER_HOST="$BIPIO_USER.bipio.demos.wot.io"
BIPIO_HEADER_CONTENT="application/json"
BIPIO_HEADER_AUTH="Basic $BIPIO_TOKEN"
BIPIO_HEADERS="{\"Host\":\"$BIPIO_HEADER_HOST\", \"Content-Type\":\"$BIPIO_HEADER_CONTENT\", \"Authorization\":\"$BIPIO_HEADER_AUTH\"}"
echo "Sending subscription request to ARM embed Device Server..."
curl -X PUT \
-H "Content-Type: application/json" \
-d "{\"url\": \"$BIPIO_ENDPOINT\", \"headers\": $BIPIO_HEADERS }" \
"http://$MDS_USER:$MDS_PASS@$MDS_HOST:$MDS_PORT/notification/callback"
curl -X PUT \
-H "Content-Type: application/json" \
"http://$MDS_USER:$MDS_PASS@$MDS_HOST:$MDS_PORT/subscriptions/wotio-freescale-endpoint/Test/0/D"
echo -e "\nDone."
Now, with the FRDM-k64f board connected, we can run the bipio_subscribe
script to have notifications sent to our new bip. We can also view the "Logs" tab for our test bip to verify that notifications are being received, or the "View" tab of the "View Raw Data" to see the messages themselves.
That's it! That's all there is to it! Of course, we can modify our bip to do something interesting like manipulate the messages, send them as part of SMS or email messages, save them to Google documents or send them to any of the other 60+ integrations that bip.io offers.
Next Time
Next time, we'll tweak the demo a bit further to hook up to the newly announced ARM mbed Device Connector cloud service—a convenient tool to use during prototyping—and use our button-push events to interact with other services on the wot.io data service exchange.
I love composable data services.