A final wrap up and conclusion to these posts on Blazor and dotnet/iot


This sequence of blog posts has been focussed upon using Blazor with an Azure IoT Hub. It has covered using a Blazor app to submit simulated telemetry to a Hub, SensorBlazor. It also covered monitoring an IoT Hub for submitted telemetry and displaying that, BlazorD2CMessages. The question of whether an IoT Hub device, such as a Raspberry Pi, can be use Blazor to submit telemetry to a hub was investigated. The enabling library used in that consideration was the dotnet/iot library, as available on GitHub and Nuget, that makes sensors and actuators code-able in .NET Core apps. The desire was that the bindings in that library would permit a Blazor app running on a device to determine and submit telemetry to a hub. Whilst a Blazor Service running on a RPi can use the bindings to collect sensor data and submit it to a hub, a Blazor WASM Client app is sandboxed and cannot. The service approach though would be rather pedantic as a .NET Core Console app running on a RPi would similarly be able to get sensor data and directly submit it to an IoT Hub.



A .NET Core Console app running on a RPi can though submit telemetry data to a Blazor Service running on another device. That service is the exact same one that the device simulation uses. This does have some purposes though. The service can handle multiple devices and therefore acts as an IoT Edge Device. The service is where the Azure IOT Hub SDK is used. Also, the devices only need the URL of the service and credentials for POSTs to the service. Further, for security, their connection to the service could be by a local private network. Hence the devices can be quite secure, but if pilfered, would not reveal any connectivity information about the IoT Hub.

Several .NET Console apps have been implemented and published on GitHub as part of the Simulated IoT Hub Device repository as on GitHub. All submit telemetry to an Azure IOT Hub, (a couple are awaiting hardware for testing.):

  • SimulatedSensorConsoleApp: Sends sample data to this service for onforwarding to IoT Hub. By forwarding to this service, it does not need to know Hub Details. In that way, the Blazor Service acts as an IoT Hub Edge device.

  • SimulatedSensorConsoleAppBME280: Using BME280 sensor, get environment data. Needs a slight rework.

  • SimulatedSensorConsoleCPUCoreTemp: Gets the CPU Core Temperature (Note only works on Raspian, not IoT-Core). No circuitry required though.

  • SimulatedSensorConsoleDHT22: Read Temperature and Pressure with DHT22 sensor.

  • SimulatedSensorConsoleSht3x: Read Temperature and Pressure with Sht3x sensor. NOT YET TESTED

  • SimulatedSensorConsoleADS1115_ADC: Read ADC using an ADS115. NOT YET TESTED

Nb: These apps only require version 1.0.0 of the System.Device.GPIO and Iot.Device.Bindings as available directly from Nuget. The samples upon which these are based in the dotnet/iot repository require a later unpublished or preview versions.

The format for each app follows a similar pattern. It could be templated. Some of the code could be separated into a common library, or interfaces used etc.. It was easier though, for now, just to copy one of the exiting projects and make modifications, when adding a new app.


The Telemetry submission and retrieval code is base upon the Azure IOo Hub SDK C# Quickstarts Telemetry samples:

It would be also simple to add Cloud to Device functionality, and some “Edge” intelligence could be added the Blazor service. :)

  Next: > Blazor-IoT
<  Prev:    
This Category:Blazor
  Next: > Blazor-IoT Azure IoT Hub Interaction using Blazor on ... Arduino 
<  Prev: