.NET Core on IoT: Quickstart Apps


This is a set of articles about developing and running .NET Core apps on the Raspberry Pi whether running Win 10 IoT-Core or Raspbian. This article summarises the .NET Core apps as used in the Azure IoT Hub SDK Quickstarts.

The apps used in the .NET Quickstarts are all .NET Core Console apps. For each there is a Device app which is the IoT device end of the pipe and a Service app that typically runs on a desktop. An Azure IoT Hub provides the connection between the apps which require the Hub’s connection details. It is quite simple to build and run the apps once you have set up an IoT Hub. If .Net Core is set up locally on th desktop they can built and run locally from the command line or cross compiled for a remote target and the built app then be copied to the target and run there. Targeted (cross compilation) builds can also be built using Visual Studio. Note that a build in Visual Studio Code is just a command line build (in a VS Code Terminal). For an IoT device such as the RPi, .Net Core can be set up there, the console app copied to the RPi and command line built.The app is then run there.

The Quickstart apps are:
Nb: The links on the app names are to the code on GitHub. You can get the complete zip file for all apps here. Also, the links here are to the C# versions. There are other versions available.

  • Telemetry Ref on MS Dox
    • simulated-device Device end: The app that sends simulated temperature and humidity data from an IoT device to the Hub.
    • read-d2c-messages Service End: Reads the Telemetry messages from the IoTHub.
      The simulated data is sent as name value pairs in a JSON string. Medta information is also prt of the message sent by teh device, including alerts when they occur. The service app expects to receive a JSON string of specofic structure.
  • Device Streaming Ref on mS Dox
    • device-streams-echo-Device Device End: Gets a string from the hub when it receives one. Echos (streams) it back
    • device-streams-echo-Service Service End: Sends (streams) a string to the hub and gets the response when sent to the hub.>br> Device Streaming can permit a more adhoc mode of communication where commands and/or data is sent from the service to the device as a string. The device interprets the string as commands and/or data and then performs the command with the data or performs a fixed command with the data. It then returns the result embedded in a string.
  • Telemetry 2 Ref on MS Dox
    • simulated-device-2 Device End: Beside simulated telemetry as above, the app listens for direct method calls from the hub to set the telemetry interval.
    • back-end-application Service End: The app makes direct method calls to the device to set the telemetry interval via the IoTHub and listens for acknowledgements.
      The telemetry API permits commands to also be sent from the service which are responded to by the device in a more structured manner than Device Streaming.
  • Device Proxy through streaming Ref on MS Dox
    • device-local proxy application Device End: Connects to IoT Hub using SSH. ie. Can get through a firewall.
    • service-local proxy application Service End: Streams to the device via the hub. Listens on a custom port that can be connected to using an SSH client app set the custom port.
      You can remotely interact with the Device from the Service end (i.e. run commands there) using the command line in the SSH Client. You can also RDP into the Service end.

AzureIoTHubToolbox

In my app AzureIoTHubToolbox, I encapsulated the functionality above, except for the Proxy functionality, into .NET Standard libraries and then consumed that in a UWP app. The Toolbox can perform both ends of the pipe simultaneously. I then reformulated the Device apps to use this library. So the Toolbox app can perform the Service end of the pipe communicating with the Device running elsewhere. Finally I then extended the functionality as follows:

  • Telemetry: The service end receives the data as a generic structure. The data is transmitted from the device as JSON name value pairs but the device does not expect any particular pairs. It displays all those received. In that way it is a simple matter to add sensors at the device end.
  • Device Streaming: Initially extended at the device end to Uppercase the string that is sent back. It was then extended, as options, to send back simulated data based upon the coded request received. There is also an option to get temperatures for which the device queries on the internet, the temperature of a number of capital cities! To be extended getting real sensor data.

The AzureIoTHubToolbox is available in The Store and as source on GitHub. There is now also a presentation about it as part of the Azure Advent Calendar. The landing page for this presentation is here

 TopicSubtopic
  Next: >  
   
 This Category Links 
Category:IoT Index:IoT
  Next: > .NET Core on IoT
<  Prev:   .NET Core on IoT