Introduction to the IoT Edge SDK, part 4

We have already made great progress understanding and using the Azure Gateway SDK.

What do we have right now? We can send telemetry data from multiple ‘offline’ devices and accept commands from the IoT Hub.

The data we send is well-formatted JSON so we are good to go.

But I am a bit worried. While reading all documentation regarding the transformation from Azure Gateway SDK towards the IoT Edge SDK, it is clear that multiple types of messages are sent to the IoT Hub. For example, I can imagine that a Stream Analytics module generates other data.

And let’s look at a more ‘close to earth’ example. The gateway itself is a potential device too! But I do not want to mix data coming from the gateway and from sensor devices.

Of course, we recently got the ability to route messages using the message sent. But what about using the properties? This keeps the message content clean.

Will this be working?

Continue reading “Introduction to the IoT Edge SDK, part 4”

Triggering Microsoft Flow using an Azure Function

For a recent Azure IoT workshop, we were looking for a nice ending of the Azure IoT pipeline. Because after introducing IoT Hubs, Stream Analytics, Event Hubs and Azure Functions, we wanted to show the real power of IoT.

Normally, we show a bunch of charts in PowerBI. You have seen it in my previous blogs, it’s so powerful. But this time, we wanted to do something else, something snappy.

Well, we came up with Microsoft Flow. At first, I was a bit sceptic. Will this help us to ‘sell’ Azure IoT?

Well, see for yourself… Here is an example on how to send, conditionally, an email to an email address you provide.

Continue reading “Triggering Microsoft Flow using an Azure Function”

Closing the Windows IoT Core feedback loop using Azure Functions

Windows IoT Core is my preferred solution for the proof of concepts I build. The IoT stack is both easy and powerful and it’s a good choice to build real world solutions on too.

Getting telemetry in the Cloud using Microsoft Azure IoT Hub is easy also. And in my previous blog, I showed that adding live charts for BI only takes a couple of minutes.

There is one other thing that is very typical to IoT Hub. And that is sending commands back to devices. I use Azure Functions for that purpose.

In this blog, I will show you how to make use of this new, cheap and handy feature in Azure.

Update: Azure Functions is still in preview. I fixed some blocking issues in this blog due to current changes in this Azure resource (and this is a good thing).

Continue reading “Closing the Windows IoT Core feedback loop using Azure Functions”

Introduction to Tessel combined with Azure EventHub

Last month, during the Azure Bootcamp, I was introduced in programming the Tessel.

This device is a fairly cheap IoT programming board and for me, the most remarkable feature was that it was running on JavaScript.

WP_20150425_004

Yes, everybody with the basic understanding of JavaScript can start programming the Tessel.

My main goal for  that day was putting some effort in Azure EventHubs but first I did the ‘hello world’ of the Tessel called Blinky.js

// Import the interface to Tessel hardware
var tessel = require('tessel');
// Set the led pins as outputs with initial states
// Truthy initial state sets the pin high
// Falsy sets it low.
var led1 = tessel.led[0].output(1);
var led2 = tessel.led[1].output(0);
setInterval(function () {
  console.log("I'm blinking! (Press CTRL + C to stop)");
  // Toggle the led states
  led1.toggle();
  led2.toggle();
}, 100);

It was not that intuitive to get this working (I had to install node.js etc) but the convenience of JavaScript is very nice. So just follow the scripted examples.

Then I tried out and combined two other hands-on labs:

These HOLs helped me to explore how I can send messages to the EventHub. And I was surprised how easy it was to send JSON data into the EventHub. And now I can imagine how the EventHub is just a VERY BIG bucket in which Azure MessageBus messages are off-loaded. And I can image how the data can be investigated by StreamInsight for a couple of days before the data gets steel and is deleted.

So finally, just for fun, I came up with this continuous probing and sending:

var https = require('https');
var crypto = require('crypto');
var climatelib = require('climate-si7020');
var tessel = require('tessel');
var climate = climatelib.use(tessel.port['A']);

climate.on('ready', function () {
  console.log('Connected to si7005');
});

climate.on('error', function(err) {
  console.log('error connecting module', err);
});

// Event Hubs parameters
console.log('----------------------------------------------------------------------');
console.log('Please ensure that you have modified the values for: namespace, hubname, partitionKey, eventHubAccessKeyName');
console.log('Please ensure that you have created a Shared Access Signature Token and you are using it in the code')
console.log('----------------------------------------------------------------------');
console.log('');

var namespace = 'SvdvEh-ns';
var hubname ='svdveh';
var deviceName = 'mytessel';
var eventHubAccessKeyName = 'SendRights';
var createdSAS = 'SharedAccessSignature sr=[...]';

console.log('Namespace: ' + namespace);
console.log('hubname: ' + hubname);
console.log('publisher: ' + deviceName);
console.log('eventHubAccessKeyName: ' + eventHubAccessKeyName);
console.log('SAS Token: ' + createdSAS);
console.log('----------------------------------------------------------------------');
console.log('');

var SendItem = function(payloadToSend){
  // Send the request to the Event Hub
  var options = {
    hostname: namespace + '.servicebus.windows.net',
    port: 443,
    path: '/' + hubname + '/publishers/' + deviceName + '/messages',
    method: 'POST',
    headers: {
      'Authorization': createdSAS,
      'Content-Length': payloadToSend.length,
      'Content-Type': 'application/atom+xml;type=entry;charset=utf-8'
    }
  };

  var req = https.request(options, function(res) {
    console.log('----------------------------------------------------------------------');
    console.log("statusCode: ", res.statusCode);
    console.log('----------------------------------------------------------------------');
    console.log('');
    res.on('data', function(d) {
      process.stdout.write(d);
    });
  });

  req.on('error', function(e) {
    console.log('error');
    console.error(e);
  });

  req.write(payloadToSend);
  req.end();
}

setImmediate(function loop () {
  climate.readTemperature('f', function (err, temp) {
    climate.readHumidity(function (err, humid) {
      console.log('Degrees:', temp.toFixed(4) + 'F', 'Humidity:', humid.toFixed(4) + '%RH');
      var payload = '{\"Temperature\":\"'+temp.toFixed(4)+'\",\"Humidity\":\"'+humid.toFixed(4)+'\"}';
      SendItem(payload);
      setTimeout(loop, 5000);
    });
  });
});

This code was enough to see how the EventHub was filled with data. I had no time to check out StreamInsight. But it seems very easy to write some SQL-like code to get the right information out of the hubs.

The biggest problem was the administration of all the namespaces, keys, connection strings and secrets of both the MessageBus and the EventHub. Sometimes I had to cut/copy/paste parts of connection strings but that was not that intuitive.

And the Tessel? It was real fun to play with. And the complete humidity/temperature sensor was easy to plug in (had to fix the code because it was referencing another module type). But somehow I missed the spider web of wires and components and the accidental reboots of the RaspberryPi 🙂

A special mention goes to the free service bus explorer. It was very exciting to see messages coming in live. Very useful for debugging too.