Hardware components | ||||||
| × | 3 | ||||
| × | 1 | ||||
Software apps and online services | ||||||
| ||||||
| ||||||
 |
| |||||
 |
| |||||
Saludos Cordiales!
Somos Ariel Heredia y Keneth Juma estudiantes de sexto semestre la carrera de Ingeniería en Telecomunicaciones de la Universidad Técnica del Norte ubicada en la ciudad de Ibarra - Ecuador, el presente documento recopila la implementación de envío datos a la plataforma de Amazon Web Services IoT via MQTT-SN mediante el uso de los bancos de pruebas de hadware y software que posee FIT IoT-Lab, con la finalidad de representar los datos obtenidos de dos estaciones climáticas en una página web alojada en una instancia EC2 de AWS.
La recopilación de este proceso consiste a una de las prácticas realizadas en la materia de Internet de las Cosas tomando como referecia los archivos generados por Francesco Ottaviani estudiante de la Universidad de Roma con su trbajo RIOT-OS nodes sending data to AWS IoT via MQTT-SN - Hackster.io
IntroducciónEl presente documento recopila el proceso que permite evidencia envió de datos de estaciones climáticas alojadas en dos nodos openmote-b que necesitarán obtener direcciones IPv6 globales mediante el uso de un nodo openmote-b que cumple las funciones de router de borde, posteriormente para el envió de datos mediante MQTTSN es necesario la implementación de un broker en un nodo A8 para posteriormente realizar las conexiones necesarias con un puente que permita que los datos recopilados sean almacenados en una tabla pertenenciente a Dynamo DB, para finalmente dichos datos sean presentados mediante una página web alojada en un servidor web en una instancia del panel EC2 de Amazon Web Services.
Creación del experimento en FIT IoT-LabLa creación del experimento comienza con la asignación de un nombre y el tiempo de duración, en este caso el tiempo estimado para el desarrollo total de la práctica es de 6 horas.
Una vez que el tiempo de duración del experimento ha sido establecido, el siguiente proceso consiste en seleccionar el banco de pruebas localizado en Strasbourg y seleccionar los nodos que serán necesarios para el desarrollo de la práctica en base a la arquitectura IoT planteada brevemente con la finalidad de que sean reservados para el experimento creado, por ende, los nodos a seleccionar son:
- 1 Nodo A8
- 3 Nodos Openmote-b
Finalmente, el experimento es iniciado permitiendo al usuario acceder a las funciones que poseen cada uno de los nodos.
Se ingresa al front-endSSH de FIT IoT-LAB:
<user>@<local-machine>:~$ ssh <login>@strasbourg.iot-lab.infoA continuación, se ingresa al directorio de ejemplos de RIOT, luego al de gnrc_border_router.
$ cd iot-lab/parts/RIOT/examples/gnrc_border_routerSe procede a cargar la versión requerida de GNU ARM embedded toolchain en el entorno actual. Este paso se debe realizar cada vez que se vaya a construir un firmware RIOT en el frontend SSH de IoT-LAB, dado que este OS requiere una versión de arm gcc 7 o posterior.
$ source /opt/riot.sourceAhora es momento de ejecutar el comando make con las características adecuadas para el openmote-b, que en este caso son: canal 0 y velocidad de símbolo para comunicación serial de 115200 baudios:
$ make ETHOS_BAUDRATE=115200 DEFAULT_SUBGHZ_CHANNEL=0 BOARD=openmote-b clean allEn las siguientes imágenes se puede apreciar el proceso de compilación del firmware y su obtención en almacenamiento local:
En el dashboard de FIT IoT-LAB, se define el nodo que actuará como router de borde (en este caso el openmoteb-9) y se le flashea el firmware obtenido previamente.
Nota: No abrir la consola del router de borde desde el dashboard del testbed.
Con el firmware ya cargado en el dispositivo, es momento de dirigirse al front-endSSH y desde allí ejecutar el script ethos_uhcpd.py, al cual hay que especificar el nodo, la interfaz y el prefijo de red IPv6 que va a propagar el router de borde. Puede consultar el rango de prefijos disponibles para cada localidad en este enlace.
$ # syntax: sudo ethos_uhcpd.py <node-id> tap<id> <ipv6-prefix>
$ sudo ethos_uhcpd.py openmoteb-9 tap8 2a07:2e40:fffe:00f5::/64Luego de ejecutar el script, se tendrá una salida similar a la siguiente (se ha abierto ya la consola del openmote-9.strasbourg.iot-lab.info con el baudrate configurado anteriormente):
La compilación de de los clientes MQTT radica primeramente en descargar el repositorio de ejemplos creado por Francesco Ottaviani desde el banco de pruebas de Strambourg.
<user>@<local-machine>:~$ ssh <login>@strasbourg.iot-lab.info
<login>@strasbourg.iot-lab.info:~$ git clone https://github.com/Francesco31Ott/InternetOfThings19-20.gitEl siguiente proceso consta en copiar la carpeta emcute_MQTTSN a la carpeta de ejemplos de RIOT meidante los siguientes comandos.
<login>@strasbourg.iot-lab.info:~$ cd
<login>@strasbourg.iot-lab.info:~$ cd InternetOfThings19-20/SecondAssignment
<login>@strasbourg.iot-lab.info:~$ cp -r emcute_MQTTSN/ /senslab/users/<user>/iot-lab/parts/RIOT/examples/
<login>@strasbourg.iot-lab.info:~$ cd
<login>@strasbourg.iot-lab.info:~$ cd iot-lab/parts/RIOT/examples/parts/RIOT/examples/Una vez obtenida la carpeta que permite compilar los clientes MQTTSN que simulan la obtención de datos ambientales, el siguiente proceso consta en compilar las estaciones para obtener los archivos .elf que serán el firmware necesario para los dos nodos openmote-b restantes.
- Compilación de la estación 1 para el nodo openmote-b
<login>@strasbourg.iot-lab.info:~$ cd iot-lab/parts/RIOT/examples/parts/RIOT/examples/emcute_MQTTSN
<login>@strasbourg.iot-lab.info:~$ source /opt/riot.source
<login>@strasbourg.iot-lab.info:~$ make DEFAULT_SUBGHZ_CHANNEL=0 BOARD=openmote-b EMCUTE_ID=station1 clean allUna vez el proceso de compilación ha sido terminado, el siguiente proceso es obtener la ruta que se presenta al final de la compilación, la cual permitirá la descarga del firmware compilado desde el servidor de Strambourg.
De igual manera el proceso de descarga es necesario mediante una terminal Linux en donde se especifica el directorrio donde será almacenado con el nombre del archivo .elf
<user>@<local-machine>:~$ scp kjuma@strasbourg.iot-lab.info:/senslab/users/kjuma/iot-lab/parts/RIOT/examples/emcute_MQTTSN/bin/openmote-b/emcute_mqttsn.elf /home/keneth/Descargas/openmoteb-emcute_mqttsn1.elfUna vez el archivo ha sido descargado en el computador local, es necesario flashear el firmware al primer nodo openmote-b que cumplirán el rol de la primera estación climática.
Nota: Tener en cuenta el número del nodo en el cual se flashea el firmware de la primera estación, debido a que será un parámetro a tomar en cuenta posteriormente.
Posterior a seleccionar el nodo se debe cargar el firmware del cliente MQTTSN descargado del servidor.
Finalmente, cuando el proceso de flasheo del firmware ha sido completado aparece una ventana emergente que indica que el proceso ha sido exitoso.
- Compilación de la estación 2 para el nodo openmote-b
<login>@strasbourg.iot-lab.info:~$ cd iot-lab/parts/RIOT/examples/parts/RIOT/examples/emcute_MQTTSN
<login>@strasbourg.iot-lab.info:~$ source /opt/riot.source
<login>@strasbourg.iot-lab.info:~$ make DEFAULT_SUBGHZ_CHANNEL=0 BOARD=openmote-b EMCUTE_ID=station1 clean allUna vez el proceso de compilación ha sido terminado, el siguiente proceso es obtener la ruta que se presenta al final de la compilación, la cual permitirá la descarga del firmware compilado desde el servidor de Strambourg.
De igual manera el proceso de descarga es necesario mediante una terminal Linux en donde se especifica el directorrio donde será almacenado con el nombre del archivo .elf
<user>@<local-machine>:~$ scp kjuma@strasbourg.iot-lab.info:/senslab/users/kjuma/iot-lab/parts/RIOT/examples/emcute_MQTTSN/bin/openmote-b/emcute_mqttsn.elf /home/keneth/Descargas/openmoteb-emcute_mqttsn2.elfUna vez el archivo ha sido descargado en el computador local, es necesario flashear el firmware al segundo nodo openmote-b que cumplirán el rol de la segunda estación climática.
Nota: Tener en cuenta el número del nodo en el cual se flashea el firmware de la primera estación, debido a que será un parámetro a tomar en cuenta posteriormente.
Posterior a seleccionar el nodo se debe cargar el firmware del cliente MQTTSN descargado del servidor.
Finalmente, cuando el proceso de flasheo del firmware ha sido completado aparece una ventana emergente que indica que el proceso ha sido exitoso.
Para este caso, se va a utilizar el nodo A8 ya que es el tipo de nodo apto para correr Mosquitto RSMB dentro de los dispositivos que ofrece IoT-LAB, éste será el encargado de recibir las publicaciones de las estaciones y también de enviar esa información a los servicios de AWS. Para ello, primero se accede por SSH al nodo a8-3 (ya que no hay otra forma de hacerlo para acceder a la consola, dado que en el dashboard no está admitido) y se valida que tenga una dirección IPv6 global con el uso del comando ip -6 -o addr show eth0 (aunque también es posible usar ifconfig):
Con saber la IP global de este dispositivo no suficiente, se requiere también realizar pruebas de conectividad con el resto de los dispositivos de la topología, por lo que se hacen ping6 para validar convergencia en la red.
Una vez comprobada la conectividad, es momento de crear un archivo de configuración con el que se va a ejecutar Mosquitto, para eso, con el editor vim se crea el archivo config.conf (en el directorio home del usuario):
Dentro de éste, se coloca la información que se muestra en la siguiente imagen, donde constan los puertos de escucha MQTTN-SN UDP 1885 y MQTT TCP 1886, válidos para conexiones desde direcciones IPv6.
Se valida nuevamente la dirección IPv6 del nodo A8-3
Ya con el archivo editado, se procede a ejecutar el bróker con el comando broker_mqtts config.conf y se verifica que se esté escuchando en los puertos definidos.
El primer paso dado fue crear la cuenta en AWS de forma gratuita, que ofrece las condiciones suficientes para la implementación del sistema. Partiendo de la opción “Crear una cuenta gratuita”, se siguen los procesos normales de un registro en una plataforma, con la consideración de que AWS retiene un dólar por motivos de verificación de identidad; que luego es reembolsado.
La cuenta está lista para ser utilizada y para ello se debe iniciar sesión con las credenciales registradas como usuario raíz (pues aún no se crea algún usuario IAM). Después se puede verificar los detalles de la cuenta en nombreusaurio -> Mi cuenta.
Creación del usuario IAM
Con la finalidad de mejor control de acceso a los recursos de AWS, se estableció la creación de usuario IAM. Con el siguiente proceso: en el panel Mi cuenta, buscando la sección Acceso de los usuarios y los roles de IAM a la…, marcar la opción Activar el acceso de IAM y clic en Actualizar.
Lo siguiente es buscar el panel de IAM (Servicios->IAM), y hacer clic en Usuario para crear uno nuevo, los detalles de creación respecto a nombre de usuario, contraseña y políticas se muestran en las capturas siguientes.
Lo que resta por hacer es ir al apartado de Revisar y confirmar la creación del usuario. Se muestra un mensaje de creación correcta y se observa el usuario en el panel IAM.
Creación de objeto en IoT Core
El siguiente proceso fue la creación de un objeto IoT, con el que se debía hacer la interacción tanto de la parte de las estaciones meteorológicas como del cliente suscriptor. Se realizó la siguiente serie de pasos: Ir a Servicios→IoT Core→Administración→ Objetos→Crear objetos.
En la siguiente ventana seleccionar →Crear único objeto→ Siguiente, y luego definir los aspectos como nombre (weather-smartThing en este caso), sombra de dispositivo (Sin nombre). Es necesario también seleccionar la opción de generar certificado y dar clic en Siguiente. Allí mismo se deben descargar todos los certificados que aparezcan disponibles, pues son de importancia para los pasos posteriores. Las capturas son de ayuda complementaria a las instrucciones.
Finalmente se da clic en Crear un objeto, la política se crea en la siguiente parte.
Antes de terminar de crear el objeto se deben descargar todos los certificados y archivos de claves que aparecen en una ventana emergente, solo se lo puede hacer en ese momento.
Creación de política
Se creó una política con declaraciones generales para asociarla al certificado que se creó junto con el objeto. Para ello: Ir a IoT Core→ Seguridad →Políticas, y definir los parámetros correspondientes como se muestra en la imagen.
Además del nombre, se colocan las instrucciones de política, que consiste en permitir todo, para evitar inconvenientes con el uso del objeto creado previamente.
Luego clic en Crear y dirigirse a IoT Core→ Seguridad →Certificados, marcar todos los certificados que aparezcan y seleccionar Acciones →Asociar política, elegir la política creada previamente y aceptar.
Creación de tabla en DynamoDB
Continuando en la plataforma de AWS, se debe crear la tabla en donde se almacenarán los registros de cada una de las estaciones meteorológicas. Entonces es necesario dirigirse a Servicios→DynamoDBy luego dar clic en Crear Tabla.
Luego, se debe definir el nombre de la tabla (en este caso Ambiental), así como la clave de partición (id) y la de ordenación (datetime). Es importante tener en cuenta que estos 3 datos influyen de manera directa en el correcto funcionamiento de todo el sistema, por lo tanto, se debe hacer coincidir los nombres de las claves id y datetime con los códigos Python en las siguientes secciones.
Nota: Se recomienda poner los mismos nombres en las claves de partición y de ordenación, como se observa en la imagen, para evitar mayores modificaciones en los códigos.
Finalmente se hace clic en Crear para que establezca la tabla en el panel de DynamoDB.
Obtención de las credenciales de acceso
Esto resulta necesario para el proceso de conexión entre AWS y un terminal Linux, para ello se debe ir a NombreUsuario (Keneth Santiago Juma)→Mis credenciales de seguridad →Claves de acceso →Crear una clave de acceso y descargar el archivo .csv que se genera. Este archivo contiene el keyID y el Access keyID, necesarias para la preparación de la máquina virtual Linux.
Este proceso se lo va a realizar en el mismo nodo que el momento está ejecutando el bróker (a8-3), para lo cual se abre una nueva sesión SSH en aquel dispositivo:
<login>@strasbourg:~$ ssh root@node-a8-3A continuación, se clona el repositorio de Francesco Ottaviani en el dispositivo (este proyecto está basado en el siguiente trabajo realizado por estudiantes de la Sapienza Università di Roma)
Dentro del directorio SecondAssignment se crea un directorio para almacenar los certificados (certificado de AWS, archivos de clave pública y privada obtenidos luego de haber creado el objeto en AWS IoT-Core).
Se debe crear un repositorio en GitHub para guardar en él los certificados de AWS y luego clonar ese repositorio en el nodo a8-3.
Los archivos descargados deben ser copiados al directorio certs creado en el paso anterior.
A continuación, se desplaza hasta el directorio client_MQTTSN para localizar el archivo que, a través de código Python, va a hacer la conexión hacia AWS.
# vim MQTTNSNbridge.pyDentro del archivo se editan los parámetros con la información de la tabla de Dynamo DB y la región en la que está la cuenta de AWS configurada.
Además, se debe tener en cuenta el punto de enlace de AWS IoT-Core para colocarlo dentro del archivo. Este se encuentra en la parte de Configuración en el portal de Amazon Web Services.
Se hace entonces referencia a dicho punto de enlace, así como a los archivos de certificado y claves correspondiente.
Culminado el proceso anterior, dado que el script utiliza la librería de boto3, se debe instalar dicho componente para que el puente funcione adecuadamente. Es necesario asignar una ruta de instalación distinta a la que es por defecto, de lo contrario el dispositivo arrojará errores debido a la falta de espacio.
# TMPDIR=/ pip3 install --cache-dir=/ --build / boto3Es momento de instalar AWSIoTPythonSDK, que es un kit de desarrollo dedicado a conectar AWS IoT desde un dispositivo usando Python. Además, es necesario instalar la CLI de Amazon en un directorio dedicado (que también va a almacenar archivos de credenciales y configuración):
# pip3 install AWSIoTPythonSDK
# mkdir -p ~/.aws
# cd ~/.aws
# touch config credentials
# # ---------Instalación de AWS CLIv2---------
# curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
# unzip awscliv2.zip
# ./aws/installUna vez instalados los paquetes anteriores, se procede a editar los ficheros config y credentials con el editor vim.
# cd ~/.aws
# vim configSe agrega la información de la región y del formato de salida de los archivos hacia AWS:
Lo mismo se hace con el archivo que almacena las credenciales (se extraen del archivo rootkey.csv obtenido desde AWS):
# vim credentials
# # Inside the file:
[default]
aws_access_key_id=<your-access-key-id>
aws_secret_access_key=<your-aws-secret-access-key>Con esto ya se ha configurado el puente. En la sección Pruebasdefuncionamiento se dará inicio a todas las estaciones y se correrá este script.
Servidor webConfiguración de grupo de identidades en AWS Cognito
Este paso es esencial para empezar a adaptar el sitio web para que este interactúe con servicios de AWS como DynamoDB que es el que interesa en este caso. Para crear un grupo de identidades se debe dirigir a Servicios→Cognito, luego se selecciona Administrar grupos de identidades.
Se busca crear un nuevo grupo de identidades, se especifica el nombre del grupo (WheaterInfoAccess en este caso) y se marca la casilla Habilitar el acceso a identidades sin autenticar, esto para permitir el acceso a usuarios que no necesariamente estén registrados para poder acceder a la información de las estaciones meteorológicas desplegada en la web.
A continuación, Cognito solicita asociar el grupo de identidades a dos roles de IAM, uno para identidades autenticadas y otro para identidades sin autentificar. Los roles se crean en esa misma ventana y se puede dejar los nombres por defecto. Al final se da clic en Permitir
En la ventana siguiente se debe seleccionar la plataforma Javascript para obtener las credenciales y el código para colocar en scrip.js posteriormente.
Antes de configurar el sitio web, se debe hacer un paso adicional: Asociar al rol de identidades no autenticadas (en este caso Cognito_WheaterInfoAccessUnauth_Role) a la política AdministratorAccess, dado que los usuarios que van a visualizar no hacen ninguna autentificación. Esto se hace en la consola de IAM, en la parte de Roles, allí se selecciona el rol en cuestión y clic en Asociar políticas.
Después se selecciona la política indicada en el párrafo anterior y clic en Asociar la política.
Finalmente se ha aplicado la política, y se puede pasar al siguiente procedimiento que es la configuración de un servidor web local para poder visualizar la información almacenada en DynamoDB en un dashboard.
Configuración de Apache Web Server una instancia Ubuntu de AWS
Una vez que el proceso de Amazon Cognito ha sido completado el siguiente proceso consiste en implementar el dashboard de presentación de datos en una página web alojada en una instancia de AWS, este enlace indica el proceso de como obtener una instancia con un sistema operativo Ubuntu 18.04 enlace.
Posteriormente, es necesario iniciar sesión con las llave otorgada por Amazon en un software de conexión remota como Putty.
Una vez iniciada la sesión es necesario ingresar mediante las credecedenciales de la instancia, que en este caso es ubuntu.
Posteriormente, el primer proceso por realizar es la instalación de Apache2 en el servidor de Ubuntu.
ubuntu@<IP>:~$ sudo apt install apache2Después de la configuración del grupo de identidades en AWS Cognito, se realiza la configuración del sitio web que desplegará la información de la tabla de DynamoDB. Se copia entonces el contenido de la carpeta WebApp que está en el directorio InternetofThings19-20/FirstAssigment/ al directorio var/www/estaciones.com creado para este sitio.
ubuntu@<IP>:~$ git clone https://github.com/Francesco31Ott/InternetOfThings19-20.git
ubuntu@<IP>:~$ cd /var/www
ubuntu@<IP>:~$ sudo mkdir /var/www/estaciones.com
ubuntu@<IP>:~$ sudo chown -R $USER:$USER /var/www/estaciones.com
ubuntu@<IP>:~$ sudo chmod -R 755 /var/www/estaciones.com
ubuntu@<IP>:~$ cd /home/ubuntu/InternetOfThings19-20/FirstAssignment/WebApp
ubuntu@<IP>:~$ cp -r * /var/www/estaciones.com
ubuntu@<IP>:~$ cd /var/www/estaciones.com
ubuntu@<IP>:~$ cd web
ubuntu@<IP>:~$ cp * /var/www/estaciones.comConfiguración JavaScript
La siguiente configuración de la parte web, indica que se debe configurar el archivo script.js que se ubica en /var/www/esgtaciones.com/assets/js/script.js, donde se debe reemplazar la primera parte con el código obtenido en AWSCognito.
ubuntu@<IP>:~$ cd /var/www/estaciones.com
ubuntu@<IP>:~$ cd assets/js
ubuntu@<IP>:~$ nano script.jsEl resto del archivo solo se debe cambiar la referencia a la tabla EnvironmentalStation DB por el nombre de la tabla Ambiental (este caso).
Posteriormente se configura también el host virtual para el sitio.
ubuntu@<IP>:~$ sudo nano /etc/apache2/sites-available/estaciones.com.conf
--------------------------------------------------------------------------------------
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName estaciones.com
DocumentRoot /var/www/estaciones.com
DirectoryIndex dashboard.html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
--------------------------------------------------------------------------------------Finalmente, el último proceso consiste en habilitar el virtuahost y recargar el servicio para que la página pueda ser mostrada.
ubuntu@<IP>:~$ sudo a2ensite estaciones.com.conf
ubuntu@<IP>:~$ sudo a2dissite 000-default.conf
ubuntu@<IP>:~$ sudo apache2ctl configtest
sudo systemctl reload apache2Al momento, existe convergencia en la red y el nodo a8-3 está ejecutando el bróker RSMB. Entonces para probar el funcionamiento de todo este sistema se realiza lo siguiente:
- Dar inicio a las estaciones
En vez de abrir la consola de las estaciones cliente MQTT desde el panel web del testbed, se lo hace desde el front-endSSH a través del comando netcat. Las estaciones en este caso son el openmoteb-16 (estación 1) y el openmoteb-37 (estación 2)
# Usage: nc <node-id> <port>
<login>@strasbourg:~$ nc openmoteb-16 20000
> start <node-a8-3-global-ipv6> <port> <station-id>- Correr el script MQTTSNbridge.py
Se sigue el siguiente proceso (el usuario escribe los ID de las estaciones y escribe stop para empezar a recoger datos de las estaciones):
# cd InternetOfThings19-20/SecondAssignment/client_MQTTSN/
# python3 MQTTSNbridge.py
Enter the ID of the station, one by one, that you want to subscribe to.
Type 'stop' to interrupt the process.
1
2
stop- Verificar estado en la consola donde se ejecuta el puente
- Comprobar el envío de datos a Dynamo DB
- Visualizar datos en el dashboard alojado en el servidor web
Comments
Please log in or sign up to comment.