You are a developer and want a simple tool to create virtual devices and test IoT flows?
If so, this post is probably for you.
When working on IoT projects, sooner or later, you will need to test the integration of the “device side” with the “solution side”. There are many alternatives for this (UI-oriented or command-line-oriented).
Azure IoT Explorer is probably one of the most known among Microsoft's tools. It is a graphical tool covering a large set of features and IoT flows. However, it is a desktop application.
Microsoft has also developed an IoT Plug and Play Mobile App. It is very easy to use. Nevertheless, it is focused on Azure IoT Central.
I was missing a more generic tool, a bit more versatile and keeping the same level of simplicity. So, why not create a mobile application implementing most of the common IoT flows and allowing to simulate not only one virtual device but many of them? That was the beginning of Azure IoT Mobile Device.
Before going deeper into the application, let's remind first some basic concepts about IoT solutions. This will help to understand better what the application is for and what it does.
An IoT Solution might include many Azure services. Most of the time, they include at least:
These services are usually completed by many others (not an exhaustive list):
Obviously, each project is unique, and the list of the truly used services depends on the requirements of each solution.
In this post, we will only use an Azure IoT Hub DPS (DPS) and a linked Azure IoT Hub. The idea is to avoid being dispersed and keep our attention at the application level. If you are interested in IoT architectures, you can find more information here.
DPS works together with at least one Azure IoT Hub. Its role is to simplify the provisioning mechanism with guarantees in terms of security, availability, reliability, and scalability.
In very simple words, “provisioning” is the action that takes in charge:
You will find here more details about Azure IoT Hub DPS and the provisioning process.
Once the provisioning is done, the devices can communicate with the assigned IoT Hub in a secure way. It is important to mention that the IoT Hub can also interact with the device (Cloud To Device flows, C2D), which unlocks very interesting possibilities.
When it comes to the application, I have considered different alternatives and technologies to implement it (Microsoft and not Microsoft). In the end, the set of technologies that offered the best value (features, tools, learning curve, productivity, etc) were:
The application has only been tested on Android phones. There is no particular reason for this; just a logistic problem since I do not have the required material to work on iOS.
Tools and IDEs:
Azure IoT Explorer covers a large set of features. Those used in this context are focused on C2D flows and controlling the telemetry collected at Azure IoT Hub level (see the screenshot below). The documentation provided by Microsoft Learn describes all the steps to install, configure and use the tool.
You will see later in the post how to use Direct Methods. The other features are quite simple to understand.
As mentioned earlier, Microsoft has already published a mobile application to create virtual IoT devices based on IoT Plug and Play and focused on Azure IoT Central. Azure IoT Mobile Device’s approach is different and more oriented to Azure IoT PaaS services. There is no “better or worse” discussion here. The approach is just different.
IoT Plug and Play is an interesting concept having for purpose to simplify as much as possible the user experience and help to connect a device to an IoT solution. We could say that it is similar to the PnP we know with hardware (at least, conceptually). IoT Plug and Play uses DTDL (Digital Twins Definition Language) to describe the interface (contract) of a given device type.
Azure IoT Central is also based on IoT Plug and Play, which allows very easy and fast device/solution integration, going until the automatic UI rendering based on the described DTDL models.
Despite the attractivity of this approach, sometimes it is not enough, and you need to use other alternatives. This is where Azure IoT Mobile Device finds its place and can help.
We have already seen that the application needs some prerequisites to work properly:
To create these services, you will need an Azure Subscription. If you do not have one, you can get one for free here. You can also use a free Azure IoT Hub if its use remains under the limits described in the next link.
If you want to use all the IoT features (C2D, Device Management, etc), do not use the Basic tiers.
All the needed services can be created either directly through the Azure Portal or using IaC (Infrastructure as Code). The latter offers these different alternatives:
We will provide here an Azure CLI-oriented approach but any of them is valid.
rg="aiot-md-rg" location="westeurope" iothub_name="aiot-md-iothub" dps_name="aiot-md-dps" enrollent_id="aiotmdegr" #Resource group creation az group create --name $rg --location $location #IoT Hub creation az iot hub create --name $iothub_name --sku S1 --resource-group $rg --location $location #DPS Creation az iot dps create --name $dps_name --resource-group $rg --location $location scope_id=$(az iot dps show --resource-group $rg --name $dps_name -o tsv --query "properties.idScope") #Link between the DPS and the IoT Hub pk=$(az iot hub connection-string show -n $iothub_name --policy-name iothubowner --key-type primary -o tsv) az iot dps linked-hub create --dps-name $dps_name --resource-group $rg --connection-string $pk #DPS Enrollment group az iot dps enrollment-group create -g $rg --dps-name $dps_name --enrollment-id $enrollent_id enrollmentgroup_pk=$(az iot dps enrollment-group show -g $rg --dps-name $dps_name --enrollment-id $enrollent_id --show-keys -o tsv --query "attestation.symmetricKey.primaryKey")
$scope_id and $enrollmentgroup_pk contain the needed values for the provisioning settings in the application.
Keep them for later steps.
The provided commands create:
An enrollment group represents a group (logical) where devices will be managed and authorized for provisioning in the same way.
At this stage, we can already run the application. Let’s mention again that in real projects, the architectures will be richer and more complex. Also, it is highly probable that after many projects you will have to deal with many DPSs and IoT Hubs, similarly to the diagram below:
One of the purposes of this mobile application is to help in this scenario by offering the possibility to interact with more than one DPSs and, also, implement many virtual devices.
The application allows to:
If you want to try the application, you can install it from Google Play.
The home screen enumerates the simulators. A simulator is nothing else than a provisioned virtual device with all the settings to initialize the simulated flows. Another view will list the devices and give access to the settings of the devices.
To create the simulators, it is necessary to cover the next steps:
The application allows to configure as many DPS instances as desired. This might be practical if you need to test different environments or different projects.
For now, the security type of the DPSs’ is limited to “Symmetric Keys” and the enrollment type is “Group”.
To add a DPS configuration, you only need to go to “DPS Settings” and click the “Add” button.
The application will ask for the information below:
All these values are also available at the Azure Portal.
These settings are manual but I am already thinking of different alternatives to try to improve the user experience.
The settings below are not editable in the current version:
Once the required information has been provided, you can save the settings and go to the next step.
The provisioning step covers many actions for you:
The application persists the connection string in insecure ways for production-oriented use. This is not a big concern at this stage, where the application is more a tool and/or a pedagogical example. However, if at some point the application goes further, these types of secrets have to be stored in more secure ways.
To provision a device, the application will request:
The “Simulator” button will unlock once all the settings have been provided.
Note that if the device is provisioned properly, a green icon is displayed at the right of the "Connection String" label. You will find this same icon in all the application to distinguish visually the devices (and the related simulator) ready to be used (provisioned and with a connection string).
At this stage, we already have a configured DPS and a first provisioned virtual device.
You will also see the new device in the list of provisioned devices.
If you add not provisioned devices, they will also be visible in the list but without the green icon.
If you try to provision an already existing device, the DPS will send in return the existing connection string. No error will be raised.
The application covers a complete set of IoT features:
If you want to use the File Upload feature, it has to be enabled and configured at IoT Hub level. Otherwise, the application will raise an exception (expected and normal behavior). This requires creating an Azure Storage account, a container and configuring the IoT Hub to store the uploaded files into it. Step-by-step details are described at the provided link.
The IaC code seen previously in this post does not enable this feature.
If any of these features are not familiar to you, follow the provided links for each feature. You will find all the necessary information at Microsoft Learn (either at the regular documentation level or at the great IoT Show channel).
The interval to send telemetry can be configured (value in seconds):
In case you do not have a way to send the Direct Method requests, you can use Azure IoT Explorer.
The payload takes the new interval (in seconds).
Talking about Direct Methods, the application includes a generic handler.
No special actions are implemented after those Direct Methods are called. The requests are logged and displayed at C2D level, which allows to test and control that the mechanism works.
The name of the Direct Methods and their signature are not important. You can use whatever you want.
Remember that the simulator needs to be connected, running and with the checkmark "C2D-DM" checked.
As you can see in the screen below, the application displays a short trace of the requests.
The message structure can be defined with a configurable JSON Schema. When tapping on the button "Message structure", the application will ask you to locate the file containing the JSON Schema and it will display its content.
This schema will be used to generate random JSON messages. The randomization mechanism is very rudimentary in this first version.
C2D Messages (C2D-M) and Twin Desired Properties (C2D-DP) work in a similar way to the generic Direct Method handler.
Whatever you send to the virtual device, it is logged and displayed at the C2D logs level.
If C2D-Read TP is checked, Device Twin Properties are read and displayed at start time.
Once all the settings have been provided, they can be persisted with the “Save” button. You can also change them whenever you want. Stop the simulator to make the changes.
Keep in mind that the device needs to be provisioned (green icon) to start using the simulator. The application will guide you through the process, keeping you safe from doing inappropriate operations.
The running section of the simulator (yellowish) is just below the configuration section (blue).
It includes simple logs of D2C and C2D flows but enough to see how your "new IoT phone" is interacting with an IoT Solution. This is, by the way, a simple way to observe how impressively well are designed the underlying technologies (SDKs, Azure Services, etc).
The About screen includes:
In case you need to reset the application and clear all the settings, it can be done through the button located in the “About” screen.
I hope this application either helps you as a developer or gives you new ideas. This is also an example of the perimeter covered by the large catalog of services, technologies, tools, and IDEs offered by Microsoft and their level of integration.
What is next?
An interesting upgrade of the application could be to use IoT flows to collect technical telemetry of how the application is being used. There are already other solutions to achieve that. That said, this type of flows is pretty natural in IoT and the application contains all the components to implement it.
Another nice feature would be to simplify the input of the DPS settings (ex: QR codes, etc).
Feel free to reach out and provide any feedback, your thoughts, whatever ;).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.