En el segundo capítulo de esta serie dedicada a la implementación de una solución tecnológica que aúna dispositivos de Internet de las Cosas y la nube, exploramos el Hub de servicios dedicados a IoT en Amazon Web Services, en sintonía con un dispositivo inteligente compuesto por un microcontrolador ESP32 como es M5Stack Fire Kit.
Planteado un supuesto de aplicabilidad posible, el registro en directo de asistentes a un evento multitudinario, esta labor requirió de tareas técnicas como hitos reales de proyecto. ¿A destacar? Alta del dispositivo, generación de certificados X.509 para identificación y acceso remoto bidireccional local/Cloud, puesta a punto del entorno de desarrollo, implementación y flasheo de lógica de negocio y mecanismos de publicación y suscripción de mensajería en topics MQTT.
Este procedimiento secuencial de acciones pudiera repetirse tantas veces como puntos de interacción inteligente (“things”) se requirieran en correspondencia con el dimensionamiento final de la infraestructura (véase número de accesos al recinto, volumen de inscritos al evento, personal contratado para la organización del mismo). ¿Y ahora qué?
Llegados aquí, es turno de incorporar a nuestra propuesta el enorme potencial de recursos de computación distribuida y analítica, almacenamiento, bases de datos y recursos dedicados para Internet de las cosas que ofrece AWS. Esto permitirá vitaminar el proyecto con ciertos automatismos, en forma de reglas de negocio para la persistencia de información emitida y la toma de decisiones en tiempo de celebración de evento, que es cuando verdaderamente se requieren.
4. AWS SAR: Reglas y funciones Serverless para completar la operabilidad en la solución IoT Cloud
Recuperando el diagrama global de infraestructura IoT Cloud presentado en la primer parte de nuestro tutorial, vamos a establecer el flujo básico de publicación/suscripción entre AWS IoT y AWS Lambda. Con ello llevaremos a cabo la implementación de un Backend Serverless que permita enviar y recibir mensajes en el flujo de topics bajo protocolo MQTT, posibilitando una funcionalidad completa de doble sentido:
- Al emitir un mensaje desde M5Stack Fire como dispositivo emisor y originario del flujo de interacción, una regla de AWS IoT reenviará su contenido hacia una función Lambda (“TopicSubscriber“) encargada de registrar su contenido en una tabla del servicio autogestionado de bases de datos NoSQL DynamoDB.
- Al emitir una petición de servicio con un mensaje determinado desde un endpoint REST POST habilitado en el servicio API Gateway, dicho recurso invocará a una función Lambda (“TopicPublisher“) que reenviará el contenido hacia el topic al que está suscrito M5Stack Fire.
De cara a simplificar la realización de este apartado, recurriremos al despliegue de una aplicación reutilizable ya existente y de dominio público disponible en Serverless Application Repository (AWS SAR). Utilizando la plantilla de definición de recursos necesarios AWS Serverless Application Model (SAM), dicha aplicación despliega los siguientes servicio de manera automática sobre nuestra cuenta de AWS:
- Las dos funciones Lambda de suscripción (“TopicSubscriber“) y publicación (“TopicPublisher“) anteriormente descritas.
- Una tabla en DynamoDB en la que registrar los mensajes emitidos por M5Stack Fire.
- Una regla AWS IoT que invoca a la función Lambda de suscripción con el contenido del mensaje enviado al topic m5stack/pub.
- Endpoint de APIGateway con recurso de invocación a la función Lambda de publicación de mensajería hacia el dispositivo local.
Incorporar a nuestra propuesta el enorme potencial de recursos que ofrece AWS permitirá vitaminar el proyecto con ciertos automatismos, en forma de reglas de negocio para la persistencia de información emitida y la toma de decisiones en tiempo de celebración de evento, que es cuando verdaderamente se requieren.
El procedimiento a seguir para dicha integración es el siguiente:
- Autenticarnos desde la consola de administración web en la cuenta de AWS sobre la que realizamos los primeros pasos de nuestro tutorial, situándonos en la misma región en la que dimos de alta el thing.
- En otra pestaña del navegador, hacer clic en el siguiente enlace web, el cual nos redirigirá a la aplicación Serverless reutilizable lambda-iot-rule, alojada en el repositorio AWS SAR; posteriormente, seleccionar la opción “Deploy“:
- En la configuración de la aplicación, habrá que introducir los valores de los topics de publicación y suscripción incluidos en la configuración de política asociada a nuestro dispositivo IoT (véase en caso de duda la sección de “1. AWS IoT Device Management: things y buenas prácticas” del anterior post); preservando el nombre de aplicación por defecto, introduciremos la cadena “m5stack/sub” en el campo del topic de publicación al que M5Stack se suscribe para la recepción de mensajes, y “m5stack/pub” en el campo del topic de suscripción como canal por el que el dispositivo pueda comportarse como emisor de mensajes. Importante en última instancia habilitar la casilla de consentimiento de creación de roles personalizados requeridos de permisos de interacción entre servicios en IAM:
- En un corto plazo de tiempo se procede al aprovisionamiento de todos los servicios de AWS necesarios antes descritos, definidos en la plantilla de Serverless Application Model (SAM); finalmente, podrá verificarse la creación de la aplicación Serverless, incluyendo hasta 11 recursos distintos, aparte del endpoint o punto de enlace a API Gateway (:
De modo opcional, podemos revisar que se han creado debidamente cada uno de los recursos mencionados, validando así que nuestra aplicación Serverless se encuentra plenamente operativa. Por otra parte, dicha validación se realizará con el ánimo de conocer más en profundidad el detalle de configuración de las instancias de servicios involucrados, la programación embebida en el tratamiento de eventos, y en la parametrización de identificadores necesarios para vincular unos recursos con otros. Para ello, y desde la consola de administración de AWS:
- Accedemos al servicio AWS Lambda y seleccionamos en la barra lateral la opción “Functions“, mostrándosenos en el panel central de la vista las dos creadas tras el despliegue de la aplicación SAR:
La función de subscripción al topic atiende a la gestión de eventos, preparando un nuevo “item” a insertar en DynamoDB como consecuencia de una invocación a la función con el contenido del mensaje incluido en el parámetro “event“. Destacar también la referencia al identificador con el nombre de la tabla sobre la que persistir dicha información. Se trata de un valor generado dinámicamente en tiempo de despliegue (al igual que el resto de identificadores de los recursos disponibles) a través del uso de variables de entorno:
Realizando el mismo ejercicio con el segundo recurso funcional, para la publicación de mensajes al topic al que está subscrito M5Stack se requiere de la gestión del mensaje emitido desde el endpoint habilitado en API Gateway. La función Serverless es invocada por este punto de enlace, el cual publica en el topic cuyo valor se concretiza nuevamente dinámicamente:
- Accedemos ahora al servicio DynamoDB, y seleccionamos en la barra lateral la opción “Tables“, figurando en el panel central una (de momento vacía) que lleva por nombre el mismo que el indicado en el paso de parámetros de la función Lambda de subscripción (figura 6):
- Queremos comprobar seguidamente si, en caso de emitirse un mensaje desde M5Stack al topic de publicación (“m5stack/pub“), se ha registrado alguna regla de actuación que invoque a la función Lambda de inserción del contenido en DynamoDB. Nos dirigimos al servicio IoT Core, hacemos clic en la opción “Act” y “Rules” sobre el menú lateral, y entramos al detalle del único registro listado. Debe de figurar activada la regla, la condición de consulta del disparador orientada al topic de publicación en cuestión, y la acción programada de invocación hacia la función Lambda correspondiente (“TopicSubscriber“):
- Únicamente nos queda dirigirnos a nuestra aplicación Lambda (en AWS Lambda”, seleccionando la función de nombre serverlessrepo-lambda-iot-rule), y sobre la pestaña “Overview“, guardarnos a buen recaudo el endpoint o punto de enlace de API Gateway. Haremos uso de él en nuestra gran demostración final:
Con esto daríamos por concluida la implementación de los componentes necesarios para contar con un flujo de trabajo básico en la comunicación entre un dispositivo inteligente local y servicios remotos Cloud.
Inclusión de nueva regla AWS IoT adicional según tipo de asistente registrado
Con el objetivo de mostrar la versatilidad de acciones que pueden adherirse a nuestro proyecto IoT Cloud, amoldable a las necesidades reales que pudieran requerirse en cualquier contexto y/o sector profesional, vamos a incorporar una funcionalidad nueva. Con ella, y retornando a nuestro ejemplo de aplicabilidad posible, en el supuesto del acceso al evento multitudinario de personas que acudan al mismo en calidad de ponente (“Speaker”), dicho registro de información, aparte de persistir en DynamoDB como soporte de almacenamiento de todos los asistentes, provocará:
- Almacenar el mensaje en un bucket de Amazon Simple Storage Service (S3) al que tendrá acceso únicamente el área de Marketing de la empresa organizadora del espacio, facilitando así la entrega de distinto material de merchandising como agradecimiento por la colaboración realizada.
- El envío de un mensaje personalizado gracias al servicio de notificaciones push Simple Notification Service (SNS), avisando al Chief Operations Officer (COO) de la llegada de cada conferenciante.
Nos dirigiremos nuevamente por tanto al servicio AWS IoT en la consola de administración, seleccionando “Act” y “Rules” nuevamente del panel lateral, y haciendo clic en el otro extremo de la pantalla sobre botón “Create“. Ya allí se sugiere el uso de valores para los siguientes parámetros:
- Name:
speaker_detector- Rule query statement:
SELECT * AS speaker_details
FROM 'm5stack/pub'
WHERE type_attender = "Speaker"- Add action: añadiremos dos acciones:
1) “Store a message in an Amazon S3 bucket”, creando bucket de nombre “speaker-data” sobre el que depositar los mensajes con el detalle de los asistentes ponentes (más información aquí).
2) “Send a message as an SNS push notification“, creando una subscripción de tipo email con la dirección de correo electrónico de la persona supervisora del control y gestión de los colaboradores (más información aquí).
Tras crear la regla personalizada, la configuración debería de mostrarse similar a la que figura en la siguiente captura de pantalla:
5. Validación final sin ‘efecto demo’
Llegó el gran día. Un evento sin precedentes. Nos encontramos ante la inauguración del encuentro tecnológico más esperado del año por todos: una nueva edición de IoT&Big Data Tech Event 2021. Inscripciones agotadas. Los mejores referentes mundiales charlando sin tapujos acerca de experiencias reales de proyectos reales haciendo uso de tecnologías asentadas y otras tantas disruptivas y en proceso de maduración. Comienzan los registros en puerta de asistentes regulares, sponsors y ponentes para la entrada al recinto. Para ello, se ha contado con una solución IoT Cloud desarrollada ad hoc para la presente edición, la cual parte de unos dispositivos inteligentes que van validando a cada paso la información del usuario (hora de acceso, tipología). Con una finalidad de control organizativo, de gestión del aforo y de apoyo a los colaboradores, dicha información se va registrando al momento, permitiendo llevar a cabo la toma de decisiones in-time (como la de restringir el acceso por superar el aforo establecido, por ejemplo).
9:00 horas: se abren las puertas, acudiendo paradójicamente (cuestiones del azar) únicamente personas en calidad de asistentes regulares y sponsors. 5 minutos después, se decide revisar uno de estos dispositivos IoT (el único a esas horas operativo), utilizado por un operario de la organización, así como el estado de la infraestructura aprovisionada en la nube de AWS para conocer si está funcionando correctamente la operabilidad . Revisando el thing en cuestión, se observa que se han producido hasta ahora 7 registros (3 de ellos con type_attender “Sponsor” – botón frontal izquierdo – y los otros 4 como “Regular attender” – botón frontal central -):
Al acceder a la cuenta organizativa de AWS sobre la que se llevó a cabo la labor de implementación de nuestra solución IoT Cloud de servicios dedicados a la gestión de accesos al evento, encontramos que exactamente se habían registrado el mismo número de personas, y en el mismo orden temporal dentro del intervalo de los 5 minutos de registro:
Poniendo el foco en el cuerpo principal de cada registro (campo “payload“), observamos la información que a modo ilustrativo se emite desde el dispositivo origen, coincidente con la que se mostraba por la pantalla del dispositivo local:
Justo a lo lejos, y obligado a madrugar por formar parte de la validación de esta nueva solución tecnológica, acude el primero de los ponentes al lugar de acreditación, registrándose debidamente al mismo. Acto seguido, se vuelve a requisar el dispositivo local para comprobar por pantalla si se ha emitido algún mensaje que corrobore dicha alta, indicando a todas luces que así fue:
De manera análoga, validamos que se ha incluido un nuevo registro respecto a la anterior vez en el servicio autogestionado de bases de datos no relacionales DynamoDB, esta vez con el primer speaker dado de alta:
Al tratarse de un colaborador, revisamos que el área de marketing disponga ya de la información relevante de su presencia para proveerle de un kit de bienvenida como gesto de gratitud por estar presente en estas jornadas:
Y no menos importante, preguntamos al director de operaciones si ha recibido algún aviso relevante, y nos reenvía esta captura de pantalla de su dispositivo móvil:
13:00 horas: el aforo empieza a completarse. Éxito en la primera jornada, es probable que durante el día se tenga que impedir el paso a más visitantes para respetar las medidas de seguridad sanitaria en el recinto.
13:26 horas: tras contabilizar el número de personas dadas de alta, e identificar que ha llegado al máximo permitido, se emite una petición de servicio a todos los dispositivos inteligentes para dar por finalizada su labor de registro de nuevos usuarios:
curl -d '{"STAFF":"AFORO COMPLETADO! IMPOSIBILIDAD DE NUEVAS ALTAS."}' -H "Content-Type: application/json" -X POST "https://xj91kamgla.execute-api.eu-west-1.amazonaws.com/Prod/publish"
¡Sed más previsores en la jornada de mañana, que lo mismo volvéis a quedaros a las puertas de la cita obligada para todo “techie”!
Aquí finaliza nuestro tutorial de diseño e implementación de una solución tecnológica que aúna la interconexión de componentes locales de sensorización y actuación local en combinación con capacidades Cloud. Espero con ello haber afianzado los conocimientos abordados a lo largo de esta serie de 3 publicaciones. Si has llegado hasta aquí, solo me queda felicitarte por tu esfuerzo. ¡Un nuevo mundo de posibilidades te espera!
Todos los post de esta serie:
Tu primer proyecto IoT Cloud (I): Tutorial para solución E2E con ESP32 y AWS IoT
Tu primer proyecto IoT Cloud (II): Registro en AWS IoT y puesta a punto de M5Stack
Tu primer proyecto IoT Cloud (III y fin): Procesamiento en streaming y validación final
Para mantenerte al día con el área de Internet of Things de Telefónica visita nuestra página web o síguenos en Twitter, LinkedIn y YouTube.
The post Tu primer proyecto IoT Cloud (III y fin): Procesamiento en streaming y validación final appeared first on Think Big.