Working on IoT global solutions is very exciting by the number of topics involved: functional valuable features, business value, devices, data, security, data analysis, AI, etc
Testing the solution with real devices is not always efficient and not even possible. So, sooner or later, IoT developers are confronted with the problem of needing devices but not having real ones.
This is where IoT developers start building their own applications or “IoT Simulators”. This is also where I see a lot of people (developers) coding all more or less the same thing in order to test their solution …. or if not exactly the same thing, at least similar enough to start wondering: “wait a minute, wouldn’t be helpful taking the tool I created for myself, clean it a bit, make it at least ‘deliverable’ and share it?” :).
IoT Simulators in the “market”
Many IoT solution providers or editors have provided:
pieces of code simulating partial behaviors of devices
small solutions but not covering all the important functional flows
whole simulation platforms (more or less customizable)
Most of them remain focused on data generation.
However, I still felt the need to go further and build a whole IoT simulator covering most common IoT use cases. This means data generation but also other C2D and D2C flows.
This led me to build a tool for my own needs that has become Azure IoT Device Simulator now.
a few Cloud To Device (C2D) interactions (Direct Methods, as Olivier Bloch and Troy Hopwood present here in the IoT Show)
For now, the main focus seems to be data generation though. Microsoft’s IoT Teams release updates very often. Keep posted to see how the solution evolves because I am pretty sure they will complete the solution iteration after iteration.
Azure IoT Device Simulation follows another approach and tries to cover more IoT functional features (and an important part of Azure IoT Hub SDK‘s device-side technical features; only a few of them have not been used ….. for now 🙂 ).
This solution main characteristics are:
Local (not a web solution), fully .NET Core based.
Lightweight tool (not a whole platform)
Easy integration with developer tools
Could be used for unit tests
Solution configurable in many aspects (certain parts of message contents need to be improved to avoid limitations)
Free (unless you decide to build a whole simulation platform with Kubernetes, etc)
The solution could even be deployed in a real IoT device as a binary application (.NET Core based) as well as a Docker container.
The simulation logic remains quite basic (simple random logic). However, the solution is extendable with custom logic implementations.
Message structures are configurable and rely on JSON templates. A strong link exists between simulation services and JSON templates. This should be reviewed in upcoming versions and reduce that level of coupling.
natively integrated into Visual Studio through the Azure workload and the Cloud explorer
Even though their philosophy is different from Azure IoT Device Simulator or Microsoft Azure Device Simulator’s, these tools add IoT capabilities directly into the IDE.
Iteration after iteration, they are getting richer and richer in terms of features.
As mentioned earlier, these extensions are:
They can be used for development or testing.
They do not allow:
simulating whole IoT device flows (not all the IoT flows are implemented. They are not built for that either.)
building platforms of devices.
building message advanced logic or templating.
industrializing the simulations.
Azure IoT Device Simulator is a complementary tool for IoT developers or testers. It can also be used for building whole IoT device simulation platforms. By default, it includes three types of messages (telemetry, error, commissioning). Message schema relies on JSON templates and, except a few dependencies with the implementation of the simulation service, the schema is totally customizable. The solution implements an important set of Azure IoT SDK capabilities covering a large field of IoT scenarios.
Azure IoT Device Simulator can be used as a standalone tool or as part of a global platform (Docker + Kubernetes or binaries + Apps).
Microsoft Device Simulation Accelerator is less technical, IDE-oriented (web) and very fast to deploy. In a few minutes, a whole IoT Device simulationplatform can be built. The types of messages and the metrics sent by devices can be customized totally (it seems that the current version does not allow customizing the simulation logic). The current version of the platform seems to be data generation-oriented. Costs also need to be taken into account; Microsoft Device Simulation Accelerator is a SaaS solution (web front).
Azure IoT Device Simulator was initially created as a developer tool for my personal IoT projects. Quite soon I felt the need of making it more reusable and generic.
Knowing that all IoT Developers are confronted with this same need, I thought it was maybe useful either build a monetizable solution (but with the required support, etc) or publish it as an opensource project. Great question because both alternatives were quite attractive to me.
In the end, I decided to publish the solution as an Open Source project and make it live through contributions. That will allow me to focus on other side projects and I am pretty sure I will have the chance to live new business adventures quite soon :).
IoT Hub exposes REST APIs and SDKs to interact with it.
The fact is that production projects sometimes (often) require implementing intermediate layers (logic, security or whatever) between IoT Hub used features and project’s accessible endpoints. This can be done with custom SDKs or in a more service oriented approach, with applicative services (lastly, usually REST oriented).
You will find here a Visual Studio 2017 extension that creates REST APIS (.NET Core 2.1.x) solutions exposing IoT Hub features. Indeed, the template creates a whole solution, ready to use and optimizes effort on creating business value.
Features included in the template are:
IoT Hub device management:
create and register a device (with default tags)
disable a device
enable a device
delete a device
get a given device properties
search devices according to given critera
Cloud to device communication:
call Direct Methods through REST API requests
update device twins (tags)
update device twin (desired properties)
create IoT Hub jobs (ex: device firmware update) and follow up status
get IoT Hub’s jobs details
All that ready to use.
You only need to set the right IoT Hub connection string (ideally, secured or stored in a KeyVault) in appsettings.json file.
In many of my last projects, I wanted to control latency levels among devices and IoT Hub. For many of them, I was just curious and for other, it was a real customer requirement.
How to do it?
What I ended up implementing for a very simple latency control relied on the items below:
new message type called “latency” and containing request timestamp
new IoT Hub endpoint (Event Hub type) to receive all the routed messages requesting latency control
new route based on “latency” message type and sending latency messages to the corresponding endpoint
new Azure Function connected to the Event Hub mentioned earlier. This function called an IoT Hub Direct Method. Its payload contained the original request timestamp. That way, the device could math the time spent for the round trip.
NOTE: in this case, latency measured device to cloud communication and its corresponding response. Single latency measure (merely device to cloud communication) could be enough in other cases.
If I get some free time in the upcoming days, I will try to package the solution and publish it (at least a kind of PoC).
Download the VSIX file, double-click on it and follow the instructions.
Through Visual Studio
Open Visual Studio 2019/2017.
Go to Tools -> Extensions & Updates.
Look for the Extension (for instance, by “.Net Core”).
Once found, click the Download button.
What does the project template do?
Once the template installed, when we go to File -> New Project, we should see the screen below:
Many inputs can be customized:
After clicking on “Ok”, a Visual Studio solution is created with the structure below:
It is what it is; I guess the proposed structure can be discussed, reviewed, completed, etc. I am open to discussions :). The purpose was to propose something usable, simple, fulfilling common REST API projects technical requirements (from the production point of view) and allowing to focus most of our effort on creating business value.
Feel free to change the content, adapt it to your requirements (you should ;)) or to provide feedback in order to evolve the template and share that capitalization.
In IoT projects it is quite typical that devices either are from different types or they send messages of different types. No matters the reason, IoT Hub ends up receiving different types of messages.
Before routing features existed, all the messages were treated through a single “pipeline” and eventual routing operations were coded “by hand” over that unique pipeline. Nowadays, things have changed and IoT Hub includes native routing features.
Let us see what it does and how it works.
Endpoints can be reached and defined from IoT Hub’s left-side menu (Messaging Section).
Endpoints management page allows to:
create custom endpoints
configure custom endpoints
delete custom endpoints
configure built-in endpoints
Default events endpoint
Cloud to device feedback endpoint
File upload notifications endpoint
NOTE: the number of custom EndPoints is limited (as of now, 10 per IoT Hub)
Creating a custom endpoint is pretty straightforward. It only requires:
an endpoint name
choosing its type
Service Bus Queue
Service Bus Topic
Azure Storage Container
Once endpoints are created, it is time create the routes. The process is pretty simple too:
It requires the settings below:
A route name
Data Source type:
Twin Change Events
Device Lifecycle Events
Endpoint (one of the previously created or a built-in endpoints)
Query string the routing is built over
Queries are written in a T-SQL-like language and based on:
message properties (kind of message metadata properties, settable by IoT SDK when building messages)
message content properties (usually, more related to the business core of the project)
Ex: status = 500 and $body.messageType = ‘error’
IoT Hub includes built-in routes that deserve a couple of words:
Default route, where devices’ messages go through by default
File upload, that can be used by devices to upload “big” messages (ex: any kind of media, collection of messages stored locally, etc).
Twin notifications, could be used by IoT Hub every time a twin is updated, in order to monitor or notify changes
Device lifecycle, used by IoT Hub to notify device lifecycle oriented messages (ex: device created, deleted, disabled, enabled, etc)
Things to keep in mind
If in your project, routing queries need to be based on messages’ content, keep in mind it must be “understandable”. Some device manufacturers or MCUs may have no choice and could send hexadecimal messages (or under any other custom serialization format).
Queries can be based on message properties too.
Routing feature is really useful (literally used in all real world projects I have been involved in since the feature was rolled out). It offers the possibility to build separate and customized treatment workflows, depending on message types and project requirements on them.