NuGet packages are a beautiful addition to your .Net development environment so you can add third-party libraries to your projects with ease.
For .NET (including .NET Core), the Microsoft-supported mechanism for sharing code is NuGet, which defines how packages for .NET are created, hosted, and consumed, and provides the tools for each of those roles.
Making use of a (privately hosted) NuGet feed is also the perfect way to distribute and version your own libraries within your company projects. Then, these libraries are only accessible by you and your friends.
Due to the fact, Azure IoT Edge modules are just docker containers, you can not simply reference other projects in the same solution. This is because of the separate docker container build and push mechanism outside the scope of the projects/solution.
Recently, I did some projects using (private) GitHub repositories to both generate, host, and consume NuGet packages.
Microsoft Build 2021 is a virtual technology conference scheduled for May 25-27. Microsoft Build is designed mainly for developers who write and support applications for Microsoft Azure, Windows, SQL Server and other applications/software platforms from the company.
Because it’s an digital event (just like last year) registration is free.
Of course, there are also Internet of Things (IoT) related sessions.
Normally, most of these sessions (Except the RSVP ones where typically involve customer interaction) are recorded and available online for registered users. So, that is the second reason to register 🙂
Here is a list of what is scheduled right now regarding IoT:
Communication using UDP is fast and supports broadcasting to several IP addresses at once.
There are some disadvantages (it has no handshaking dialogues, and thus exposes the user’s program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection) but if you can cope with that at a higher level, UDP is a handy tool in your protocol toolbox.
In this blog post we will see how UDP messages can be received on the Edge with this demonstration IoT Edge module:
Because each UDP message is different (here we send text messages but this could also be binary values, depending on your challenges), this module is just a reference which explains how it works.
As you can see, the messages are build up in three parts:
The actual message body, generated by (your) logic in the device. This part could be encoded so only the receiver knows how to handle this. Normally this is a JSON message format, though.
(Application) properties, message enrichment on the device to provide context about the messages. This acts as a property bag, also added by the developer. The values are directly accessible for routing purposes.
System properties, added by the IoT Hub. This gives technical context about the incoming message from the perspective of the IoT Hub
So users can choose to add values in the body or to add values in the application properties.
Still, every byte put in the message sent by the device results in a longer transmit duration and extra costs (number of bytes communicated, potentially more message chunks handled by the IoT Hub).
So, values already found in the system properties (eg. the device name or module id) can be left out in the body. This results in a smaller message.
Microsoft also provides message enrichment on the IoT Hub. This can take away some of the pain too.
It also makes it possible to route messages further down the road in other Azure resources which receive these enriched messages.
Back in 2018, the Azure Stream Analytics team announced Anomaly detection for Azure Stream Analytics. And, it was also supported on the Azure IoT Edge. In November 2018, I was allowed to demonstrate this at the SPS IPC Drives in Nuremberg:
Since then, anomaly detection has become a first citizen of Azure Stream Analytics.
Azure Stream Analytics Anomaly Detection is able to ‘automatically’ detect spikes, dips, and trends in a stream of values. This is based on math and all you need to do is to specify how many values you expect and how sensitive the detection must be. It is in fact Machine Learning, in the end. So it is a prediction with a certain certainty…
And it’s just part of the Stream Analytics query language. So on the edge, we can deploy a Stream Analytics module (the engine of stream analytics). This is a fixed module from Microsoft.
All you have to do is feeding it a query, inputs, outputs and, user-defined functions if available:
We can define all this in the cloud, inside a stream analytics job and we can even test it. Those parts are then packed as a blob and put in blob storage. The Stream Analytics job can then download it and run it.
The inputs and outputs of the Stream Analytics job can be attached to the normal Azure IoT Edge routing mechanism.
But there were also smaller gems. On of them is “30 days to learn it“. You can complete the IoT Developer challenge and get 50 percent off the cost of a Microsoft Certification:
Implement and maintain the cloud and edge components of an IoT solution. Learn how to connect devices, move workloads to the edge, and build scalable, enterprise-grade, secured IoT solutions on Azure to increase performance, reduce costs, and optimize operations. It’ll only take about 15 hours to discover how to securely connect IoT devices to the cloud, build the intelligent edge, and develop solutions with Azure IoT Central.
There are more certificates to earn. See the site for all eight challenges!
All sessions are available now in the session catalog for you to watch. Below, I summerized all IoT related sessions.
Persisting incoming telemetry in a local database is useful for multiple purposes. One of them is creating a custom dashboard eg. written in Blazor.
In this blog, we explore how to deploy the popular InfluxDB. This open-source time-series database is specialized in Internet of Things usage. And on top of that, let’s explore how Grafana can be deployed on the edge too. Grafana is an open source analytics and interactive visualization web application.
We see how it can be connected to the Influx database:
As you see here, we need a custom Azure IoT Edge module (called ‘writer’) that is capable of writing incoming telemetry to the Influx database. There, the telemetry is picked up and displayed by Grafana.