LuisLlamas Logo
digital-twins-nanoframework

Device Twin de Azure IoT Hub con nanoFramework

  • 3 min
  • Iniciación

Un gemelo digital es una representación en la nube del estado de un dispositivo físico.

En Azure IoT Hub, ese gemelo se llama Device Twin. Nos permite tener propiedades reportadas por el dispositivo, propiedades deseadas desde la nube y métodos directos para pedirle acciones concretas.

No es solo enviar datos cada cierto tiempo. Es convertir el dispositivo en algo que la nube puede consultar, configurar y gobernar de forma ordenada.

Aquí hablamos de Device Twin de IoT Hub. Azure Digital Twins es otro servicio más amplio para modelar edificios, fábricas o sistemas completos. Están relacionados por la idea, pero no son exactamente lo mismo.

Propiedades reportadas y deseadas

Un Device Twin tiene dos grupos de propiedades importantes:

  • Reported properties: Las escribe el dispositivo. Por ejemplo, firmware, batería, IP, temperatura actual o modo activo.
  • Desired properties: Las escribe la nube. Por ejemplo, umbral de alarma, frecuencia de muestreo o si debe activar un modo de ahorro.

La idea es sencilla: el dispositivo dice “así estoy”, y la nube dice “así quiero que te configures”.

Leer el twin desde nanoFramework

La clase DeviceClient permite obtener el twin actual con GetTwin. A partir de ahí podemos revisar sus propiedades deseadas y aplicar configuración.

using System.Diagnostics;
using System.Threading;
using nanoFramework.Azure.Devices.Client;
using nanoFramework.Azure.Devices.Shared;

DeviceClient client = new DeviceClient(
    "mi-hub.azure-devices.net",
    "esp32-salon",
    "CLAVE_DEL_DISPOSITIVO");

if (client.Open())
{
    Twin twin = client.GetTwin(new CancellationTokenSource(10000).Token);

    if (twin?.Properties?.Desired != null &&
        twin.Properties.Desired.Contains("samplePeriodSeconds"))
    {
        int samplePeriod = (int)twin.Properties.Desired["samplePeriodSeconds"];
        Debug.WriteLine($"Nuevo periodo de muestreo: {samplePeriod}s");
    }
}
Copied!

Con esto la nube puede cambiar la configuración sin reflashear el ESP32, algo especialmente útil en dispositivos desplegados de forma remota.

Reportar estado del dispositivo

También podemos enviar propiedades reportadas con UpdateReportedProperties. Esto no es telemetría rápida, sino estado relativamente estable.

using nanoFramework.Azure.Devices.Shared;

TwinCollection reported = new TwinCollection();

reported.Add("firmware", "1.0.3");
reported.Add("wifiRssi", -62);
reported.Add("samplePeriodSeconds", 30);
reported.Add("status", "running");

bool ok = client.UpdateReportedProperties(
    reported,
    new CancellationTokenSource(10000).Token);
Copied!

Al verlo desde Azure IoT Hub, tendremos una ficha del dispositivo con su estado. Muy cómodo para paneles de administración, soporte técnico o despliegues con muchos nodos.

Usa propiedades reportadas para cosas que cambian poco. Para lecturas constantes de sensores, sigue usando telemetría normal con SendMessage.

Métodos directos

Los métodos directos sirven para pedir al dispositivo que haga algo ahora. Por ejemplo:

  • Reiniciarse.
  • Cambiar temporalmente de modo.
  • Encender un relé.
  • Forzar una lectura de sensores.
  • Activar una rutina de calibración.

En nanoFramework registramos una función con AddMethodCallback.

using System.Diagnostics;
using nanoFramework.Azure.Devices.Client;

client.AddMethodCallback(OnDirectMethod);

private static string OnDirectMethod(int requestId, string payload)
{
    Debug.WriteLine($"Método recibido. RequestId: {requestId}");
    Debug.WriteLine($"Payload: {payload}");

    // Aquí ejecutaríamos la acción real.
    // Por ejemplo, cambiar un modo, encender un GPIO o reiniciar.

    return "{ \"result\": \"ok\" }";
}
Copied!

El método devuelve un JSON con la respuesta. No lo conviertas en una operación eterna: un método directo debería ser rápido y predecible.

No uses métodos directos para procesos largos que puedan bloquear el dispositivo. Para eso es mejor recibir el comando, guardar una tarea pendiente y responder rápido.

Un patrón práctico

Una estructura bastante limpia para un dispositivo real sería:

  1. Al arrancar, conectar Wi-Fi y abrir DeviceClient.
  2. Leer el Twin para cargar configuración deseada.
  3. Reportar versión de firmware, IP, RSSI y estado inicial.
  4. Enviar telemetría periódica con SendMessage.
  5. Escuchar métodos directos para acciones puntuales.
  6. Reportar cambios importantes de estado.

Con este patrón, el dispositivo deja de ser una caja negra. La nube sabe qué versión tiene, cómo está configurado y si responde a comandos.

Los gemelos digitales convierten un proyecto IoT en algo mucho más gestionable. Ya no solo mandamos temperatura cada 30 segundos. Ahora podemos configurar el dispositivo desde la nube, saber en qué estado está y pedirle acciones concretas.

En esta página