Almost a year ago, I wrote an article on this topic. Since it appeared in my search results for the same question again (that’s why I am blogging - not enough, to be honest), I took the opportunity to review the article and post an updated version with an improved script.
It’ll still update installed modules and remove older version in the C:\Users\<username>\Documents\PowerShell\Modules folder, but in a more userfriendly way :-)
From time-to-time I am updating all installed PowerShell modules on my dev-machines. This can lead to a large amount of used disk space, as old versions are kept on the drive. In this post, I want to share the scripts for the two tasks. After updating modules, I noticed a large amount of data is stored in my C:\Users\<username>\Documents\PowerShell\Modules folder. To be specific, the folder eats up 3.1GB of space. Therefore I needed a cleanup script as well :-)
The Azure Resource Manager uses management endpoints to receive requests. This service is resilient and deployed to all regions and offers control plane operations, which are sent to management.azure.com. Talking to any endpoint is fine and you do not need to use a region-specific URL if you deploy to Azure with ARM, Bicep or Terraform.
In case you want to send a request to a region, this post shows you how you can do this.
This sample for an IoT Edge module sends data from a (local) MQTT server via edgeHub to an Azure IoT Hub.
IoT is the combination of data. For that, data from multiple sources are sent to a central platform for further analysis. In case of an existing MQTT broker, this module let’s you subscribe to multiple topics and leverage the IoT Edge store and forward mechanism for uploading data to IoT Hub.
Azure IoT Edge, like every other software, needs to be updated to keep track of a) new features, b) remove bugs, but also c) install security fixes.
But where do you find information about the latest versions and patches?
Major releases are currently named with “1.1 LTS” and “1.2”. The version history can be found on the Microsoft Docs page Azure IoT Edge versions and release notes.
I’ve forked Marlin to adjust the configuration and persist it in my own repository. Now Marlin released version 2.1.
Naturally, I wanted to use 2.1 as well. But the new branch was not available on my fork :-(
Let’s see what we have in a local clone of my repo:
This sample shows how to use custom code in a module to use message routing from another module (a simulated temperature sensor in this case), analyse the incoming messages and send them to a local blob storage module.
You can find the full source code on my GitHub repository: ReneHezser/Edge-Filter-Blob-Solution.
The solution contains of three containers (IoT edge modules). The Simulated Temperature and Blob Storage on IoT Edge are 1P modules from Microsoft, whereas the FilterModule has been adjusted to upload certain messages to a local blob storage.
The recommended way to run
Azure IoT Edge on Windows (EFLOW) is by installing IoT Edge in a Hyper-V VM.
But how are you going to access for example
The VM has an IP that might change every time the VM is starting.
[03/04/2022 14:26:17] Successfully created virtual machine
[03/04/2022 14:26:17] Virtual machine hostname: MY-EFLOW
[03/04/2022 14:26:20] Querying IP and MAC addresses from virtual machine (MY-EFLOW)
- Virtual machine MAC: 00:00:00:00:00:53
- Virtual machine IP : 172.19.33.153 retrieved directly from virtual machine
With Connect-EFlowVM you can SSH into the VM via PowerShell and check the IP again.
Device Streams is a feature to access IoT devices via IoT Hub. The IoT Hub acts as a proxy and no direct ingoing connection needs to be established.
Disclaimer: Azure IoT Hub currently supports device streams as a preview feature.
To be able to use device streams on an IoT Edge device (which is hosting Docker containers), there are two options:
IoT Edge 1.2 brings a (currently in preview) MQTT broker, that can be used by local modules or external applications. A SAS token will be needed for authentication.
If you want to use the broker from within an IoT Edge module, you can generate the SAS token by calling the workload API. The current SDK does not offer this functionality, as the MQTT broker is still in preview.
The sample I’ve created uses the SecurityDaemonClient class from the event-grid-iot-edge SDK as reference and is written in C#.
Me: Yeah! Another Simulated Temperature Sensor solution.
You: Hold on. Why do you create another one again?
Me: Well, mine is more flexible than the existing ones.
You: OK. Show me
Me:
"SendData": true, "SendInterval": 500, "InstanceCount": 10
You: 🥺
Me: This module gives you the flexibility to have multiple sensors sending from one module. This can be configured by the InstanceCount. The existing solution allows you to set the send interval in seconds only. With this solution, you can specify this in milliseconds.
That was a painfull learning today 🙁 Best is to blog about it now, so hopefully somebody reads this before (or during) troubleshooting a similar issue.
My home server was running crazy and did not server any requests. Oh well, it decided to reply my ping but not really allowing a SSH session.
So I needed to drag a TV downstairs to connect it via analog cable (fortunately I still found one), connect a keyboard and see that a process mono-sgen was eating all CPU 🙁 But what does it belong to? A ps -ef revealed that it belonged to duplicati – which is my backup solution.
Using temporary session tokens sounds like a good way to e.g. import data from S3 in Azure Data Factory, like it is described here Copy data from Amazon Simple Storage Service (S3) – Azure Data Factory | Microsoft Docs. Azure Data Factory can use secrets stored in Azure KeyVault for authentication (see here Store credentials in Azure Key Vault – Azure Data Factory | Microsoft Docs).
This post shows a way to find out how many IoT (Edge) devices have been provisioned by a specific enrolment group within the last x minutes.
The solution could be much simpler if I just wanted to know how many devices are registering themselves. In this case the build in metrics are enough to get that information.
The use case required a more sophisticated solution that is able to reflect the tenants, identified by tags.
In this post I would like to show some tweaks you can (and might need to) apply to influence the behavior of your IoT Edge device, when it comes to message retention on devices that are limited in resources.
The setup of this scenario is not uncommon, as it uses a module to retrieve telemetry from machines, parses them in another module and sends the messages to an IoT Hub.