Microsoft Ignite 2017: Getting Started with IoT; a hands on Primer

As part of the session we are supplied an MXChip IoT Developer’s Kit. This provides a physical IoT device enabling us to mock up IoT scenario’s. The device we are leveraging is made by Arduino. The device comes with a myriad of sensors and interfaces including, temperature and a small display screen. The device retails for approx. 30 – 40$ USD and is a great way to get started learning IoT.

When considering IoT one needs to not just connect the device but understand what you want to achieve with the data. Understanding what you want to do with the data allows you to define the backend components for storage, analytics or both. For example is you are ingesting data that you want to analyze you may leverage Azure Stream Analytics. For less complex scenarios you may define an App Service and use functions.

Microsoft’s preferred development suite is Visual Studio Code. Visual Studio Code includes extensions for Arduino. The process to get up and running is a little involved but there are lots of samples to get you started at https://aka.ms/azureiotgetstarted.

One of the more innovative ways to use the device was demonstrated in the session. The speaker created “The Microsoft Cognitive Bot” by leveraging the Arduino physical sensor and leveraging “LUIS” in the Azure Cloud. LUIS is the Language Understanding and Intelligence Service that is the underlying technology that Microsoft Cortana is built on. The speaker talks to the MXChip sensor asking details about the weather and the conference with LUIS responding.

The session starts with an introduction of what A Basic framework of an IoT Solution looks like as shown in the picture below. On the left of the frame are the devices. Devices can connect to the Azure IoT hub directly provided the traffic is secure and they can reach the internet. For devices that either do not connect directly to the internet or cannot communicated securely you can introduce a Field gateway.

Field Gateways can be used for other items as well such as translating data. In cases where you need high responsiveness, you also may analyze the data on a Field Gateway so that there is less latency between the analysis and the response. Often when dealing with IoT there is both Hot and Cold data streams.  Hot being defined as data that requires less latency between the analysis and response vs. cold which may not have a time sensitivity.

An ingestion point requires a D2C endpoint or “Device-to-Cloud”. In addition to D2C you have the other traffic flow which is a C2D endpoint or Cloud-to-Device. C2D traffic tends to be queued. There are two other types of endpoints that you can define; a Method endpoint which is instantaneous and is dependent on the device being connected. The other type is a Twin endpoint. With a Twin endpoint’s you can inject a property; wait for the device to report current state and then synchronize it with your desired state.

We then had an opportunity to sit down with IoT experts like Brett from Microsoft. Okay I know he does not look happy in this picture but we had a really great session. We developed an architecture to look at long term traffic patterns as well as analyze abnormal speeding patterns in real-time for more responsive actions.. “Sorry Speeders ; – )”.

The session turned pretty hands on and we had to get our devices communicating with an Azure based IoT hub we created. We then setup communications back to the device to review both ingress and egress traffic. In addition we configured Azure table stores and integrated some cool visualization using Power BI. Okay got to admit I totally geeked out when I first configured a functional IoT service and then started to do some analysis. It is easy to see how IoT will fundamentally change our abilities in the very near future. Great first day as Microsoft Ignite.