The holy grail of IoT Edge compute is zero-touch configuration and monitoring.
If we look at the life cycle of an edge device, these are the phases where the device is rolled out to production:
The only time when we want to have a person near that edge device is during the initial deployment (Plan, Register), during decommission (Retire) and during physical changes or while repairing the device.
To make zero-touch possible we first need to have a secure cloud connection that supports both sending telemetry to the cloud and retrieving commands from the cloud. And that is supported by Azure IoT Edge by default.
But still, we also need a second communication channel to log-in remotely in a secure way. This is typically done by hand to look at local settings, to check logging, to check connections, or to make repairs to eg. the operating system or the Azure IoT Edge runtime. This could be done using SSH and/or a Remore Desktop connection (RDP). Because this is typically an outbound connection, this is usually provided using a ‘jump box’ or a VPN connection so the connection is set up in a more secure way.
As said, this is done by hand… so far for zero-touch.
Now, if we look at what tasks are performed on the IoT Edge device using an SSH connection:
Checking the log of running modules
Restarting modules if their performance is not thusted or to force picking up settings
Checking the cloud connectivity
What if exactly these three tasks could be performed from the cloud? What if these task could automated?
Azure IoT supports cloud-to-device messaging with Direct Methods. This is an important tool when you want to control your devices real-time or if you want to execute logic on the device real-time.
In the past I have written about Direct Methods a couple of times. like this blog. I then wrote about IoT Edge supporting Direct Methods too. To be more specific, Modules in an IoT Edge support Direct Methods.
But my colleague Heindirk pointed me at a little gem unknown to me.
The same logic used to communicate from Azure cloud to a module can also be used to communicate from one module to another module without IoT Edge routes!
This update had some visual updates and now supports a Singleton pattern for the Device client too.
But it also included support for both Device twins and Direct Methods. The latter feature looks a lot like the Commands method but there are some fundamental changes.
Yes, both solutions (Command and Direct Method) can execute code on a remote IoT Hub client. But the remote method just passes a message to the client. The Direct method can pass a message in a certain context. It calls a specific method (a client can have multiple methods registered) and passes the JSON parameter.
If you execute a Command, it feels like fire-and-forget. There is no descriptive response. But the caller of a Direct Method can wait until a response is accepted and a JSON value is returned.