Comandos de aplicación a dispositivo de IoT

Las aplicaciones usan dos mecanismos principales para enviar comandos a los dispositivos de IoT, mensajería de la nube al dispositivo y métodos directos.

• Las aplicaciones envían mensajes de la nube al dispositivo a colas de mensajes específicas del dispositivo en la plataforma de IoT para que los dispositivos puedan leerlos cuando están conectados. Los dispositivos deciden cuándo se deben leer los mensajes.

• Las aplicaciones invocan métodos directos directamente en los dispositivos conectados, mediante un patrón de solicitud-respuesta en puntos de conexión de dispositivos de IoT dedicados.

En este artículo se describen las características de la mensajería de la nube al dispositivo y los métodos directos. En el artículo también se describe cómo usar métodos directos con puertas de enlace de protocolo y dispositivos en espera conectados.

Mensajería de la nube a un dispositivo

Las aplicaciones envían mensajes de comandos de la nube al dispositivo para dispositivos específicos a IoT Hub, que almacena los mensajes en colas específicas del dispositivo. IoT Hub entrega los mensajes a las colas específicas del dispositivo, independientemente de si los dispositivos están conectados.

Las consideraciones siguientes se aplican cuando se usa la mensajería de la nube al dispositivo:

• Las colas de mensajes actúan de manera efectiva como buzones de los dispositivos, y estos se encargan de sondear sus colas de mensajes para buscar nuevos mensajes cuando están conectados.
• Los dispositivos reciben mensajes siguiendo el modo de primero en entrar, primero en salir; de este modo, la mensajería de la nube al dispositivo resulta ideal para leer y actuar secuencialmente sobre los mensajes.
• Como se puede configurar la caducidad de los mensajes, es posible quitar los mensajes no leídos de la cola de mensajes del dispositivo.
• En el caso de la comunicación con estado, las aplicaciones pueden usar un receptor de comentarios para supervisar la entrega y la confirmación de los mensajes. La aplicación puede usar un solo receptor de comentarios para supervisar todas las colas de mensajes de todos los dispositivos.

Métodos directos

Las aplicaciones invocan métodos directos directamente en los dispositivos de IoT conectados y esperan que los dispositivos ejecuten los métodos y los registren con IoT Hub. IoT Hub llama a los métodos directos en dispositivos conectados a través de canales directos, y los dispositivos son responsables de ejecutar funciones y devolver resultados inmediatos.

Las siguientes consideraciones se aplican al usar métodos directos:

• Los métodos directos generan un error si se interrumpe la conexión entre IoT Hub y el dispositivo antes de que se complete el método. Las aplicaciones pueden detectar y controlar los errores para volver a intentar ejecutar los comandos.
• Dado que no hay ninguna cola, las aplicaciones que deben secuenciar métodos directos necesitan administrar la secuenciación de llamadas a métodos, de modo que al completar el método anterior se llame al método siguiente.
• La invocación de métodos directos permite a una aplicación establecer dos tiempos de espera. Un tiempo de espera especifica cuánto tiempo debe esperar IoT Hub para que se conecte un dispositivo antes de dejarlo, y el otro tiempo de espera especifica cuánto tiempo debe esperar el autor de la llamada para que el método se complete y responda antes de dejarlo.

Métodos directos con puertas de enlace de protocolo

Las aplicaciones de IoT que usan puertas de enlace de protocolo pueden beneficiarse del cumplimiento de conectividad y del modelo de solicitud-respuesta de métodos directos. Las puertas de enlace de protocolo o de nube permiten conectar dispositivos ya existentes y otros dispositivos a IoT Hub actuando en nombre de los dispositivos para el agente de comunicaciones de protocolo personalizado. Igualmente, las puertas de enlace de protocolo pueden abstraer el modelo de métodos directos mediante la serialización de métodos en mensajes de protocolo compatibles con dispositivos.

1. La aplicación invoca el método directo en nombre del dispositivo en la puerta de enlace de protocolo.
2. En la implementación del método, la puerta de enlace traduce el método a un protocolo específico del dispositivo y envía el mensaje al dispositivo. El dispositivo no es consciente de ningún cambio en la implementación en la nube.
3. Cuando el dispositivo completa el mensaje y responde, la puerta de enlace traduce el estado específico del dispositivo a la respuesta del método.
4. IoT Hub completa el método directo rellenando el resultado del método para el llamador.

El proyecto de código abierto Azure Protocol Gateway traduce métodos directos a mensajes de protocolo MQTT de forma nativa, es fácil de ampliar y demuestra este modelo de programación para otros adaptadores de protocolo.

Dispositivos en espera conectados

Los escenarios de comandos de IoT pueden implicar dispositivos en espera conectados que están en un estado de poca energía o un estado inactivo cuando no están activos. Algunos mecanismos, como SMS (servicio de mensajes de texto) en dispositivos móviles, pueden enviar señales de activación para que estos dispositivos pasen a un estado totalmente operativo.

1. La aplicación envía comandos a los dispositivos mediante la API de ServiceClient. Una instancia de ServiceClient puede enviar mensajes e invocar métodos para varios dispositivos.
2. La aplicación también envía llamadas de activación de SMS a los dispositivos en espera a través de la puerta de enlace de SMS del proveedor del dispositivo móvil.
3. En la activación, los dispositivos en espera usan la API de DeviceClient para conectarse a IoT Hub y recibir comandos. Una instancia de DeviceClient representa un único dispositivo conectado a IoT Hub.

Usar métodos directos para determinar el estado de conexión del dispositivo

El envío de mensajes de activación innecesarios a través de las puertas de enlace de SMS resulta costoso. Antes de enviar comandos reales a un dispositivo, use los tiempos de espera de conexión y métodos para determinar si el dispositivo está conectado y enviar una reactivación si es necesario.

    TimeSpan connTimeOut = FromSeconds(0); // Period to wait for device to connect.
    TimeSpan funcTimeOut = FromSeconds(30); // Period to wait for method to execute.

    while (true) {
        // Send the command via direct method. Initially use a timeout of zero
        // for the connection, which determines whether the device is connected to
        // IoT Hub or needs an SMS wakeup sent to it.

        var method = new CloudToDeviceMethod("RemoteCommand", funcTimeOut, connTimeOut);
        methodInvocation1.SetPayloadJson(CommandPayload);

        var response = await serviceClient.InvokeDeviceMethodAsync(deviceId, method);

        // [DeviceNotConnected] represents a return value from the CloudToDeviceMethod
        // method. That method is not implemented in this sample.
        if (response == [DeviceNotConnected] && connTimeOut == 0) {
            // The device is not currently connected and needs an SMS wakeup. This
            // device should wake up within a period of < 30 seconds. Send the wakeup
            // and retry the method request with a 30 second timeout on waiting for
            // the device to connect.

            connTimeOut = FromSeconds(30); // Set a 30 second connection timeout.
            SendAsyncSMSWakeUpToDevice(); // Send SMS wakeup through mobile gateway.
            continue; // Retry with new connection timeout.
        } else {
            // The method either succeeded or failed.
            ActOnMethodResult(var);
            break;
        }
    }

Para comprobar solamente la conectividad, use un método vacío con un tiempo de espera de conexión igual a cero para implementar un ping simple. Por ejemplo:

var method = new CloudToDeviceMethod("Ping", 0, 0);

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Jason Wadsworth | Ingeniero principal de software

Pasos siguientes

• En la Guía de comunicaciones de la nube al dispositivo se proporcionan instrucciones basadas en escenarios sobre cuándo usar mensajes de la nube al dispositivo o métodos directos.

Recursos relacionados

• Dispositivos, plataforma y aplicaciones IoT
• Escalado de soluciones de IoT con marcas de aplicación