Tarea 3

Universidad de Chile Facultad de Ciencias Físicas y Matemáticas Departamento de Ciencias de la computacion CC5326 – Diseño de Internet de las Cosas

Profesor: Luciano Radrigan F. Auxiliar: Alberto Abarzua P.

Objetivos a cumplir: #

• Integrar las funcionalidades de las tareas 1 y 2: WiFi y BLE. Esto significa que un ESP32 debe ser capaz de funcionar en ambos modos, con todas las funcionalidades de ambas tareas.

• El modo de funcionamiento del ESP32 debe ser controlado por el estado de la base de datos (como fue mencionado en las tareas anteriores). Esto será crucial para esta tarea.

• Los cambios en la base de datos deberán ser reflejados en el ESP32 y en el funcionamiento del sistema.

• La base de datos debe ser accedida desde Python únicamente (no se permitirá modificarla directamente usando adminer o pgadmin).

• Deben crear una API HTTP que permita (se dará una plantilla utilizando FastAPI):

  • Acceder a la configuración actual
  • Modificar la configuración actual
  • Acceder a los datos generados por las ESP32

• Una interfaz web la cual permita (se dará una plantilla usando React):

  • Visualizar los datos generados por las ESP32: Para esto, deben generar gráficos que se actualicen en tiempo real; no se permitirá mostrar datos en una tabla.
  • Modificar la configuración actual

Funcionamiento #

Todo debe funcionar según la configuración de la base de datos. Tendremos los 2 medios de comunicación:

BLE: #

• Protocolos de datos: 0, 1, 2 y 3
• Transport Layer:
  • BLE Continuo: Se envían los datos de forma continua, sin pausas.
  • BLE Discontinuo: Entre cada envio de datos existe un perido de duracion discontious_time (configurable en la base de datos) donde la ESP32 debe entrar en modo deep sleep.

WiFi: #

• Protocolos de datos: 0, 1, 2, 3, 4
• Transport Layer:
  • TCP: Se envían los datos a través de TCP, entre cada envio de datos existe un perido de duracion discontious_time (configurable en la base de datos) donde la ESP32 debe entrar en modo deep sleep.
  • UDP: Se envían los datos a través de UDP.

Se solicita que según los cambios en la base de datos, puedan cambiar tanto el medio de comunicación (BLE o WiFi) como el protocolo de datos y el transport layer.

Por simplicidad, se tendrá un estado de inicio (llamaremos estado a la configuración de medio, protocolo y transport layer); se debe iniciar el funcionamiento usando BLE Continuo y el protocolo 0. Luego, se podrá cambiar el estado a través de la API HTTP.

Luego, se debe poder cambiar desde cualquier estado a cualquier otro estado, por ejemplo:

• BLE Continuo y protocolo 0 a BLE Discontinuo y protocolo 1
• BLE Continuo y protocolo 0 a TCP y protocolo 4
• TCP y protocolo 4 a UDP y protocolo 3
• etc …

Flujo General #

1. Se inicia el sistema con BLE Continuo y protocolo 0, y se realiza una conexión entre el ESP32 y la Raspberry Pi. Se envían los datos según el protocolo 0.

2. En la interfaz web, se pueden ver los datos adquiridos por el ESP32 y se puede cambiar el estado de la base de datos a TCP y protocolo 4. (Esto realiza una llamada a la API HTTP, la cual interactúa con la base de datos).

3. En el siguiente intercambio de datos entre el ESP32 y la Raspberry Pi, su código en Python detecta el cambio en la base de datos y envía la configuración actualizada a la ESP32.

4. El ESP32 recibe la configuración actualizada y cambia su medio de comunicación a TCP y su protocolo de datos a 4. Luego, envía los datos según el protocolo 4.

5. Se ven realizados los cambios en la interfaz web y se vuelve al paso 2 para realizar otro cambio.

Aquí es importante notar que el ESP no puede trabajar con WiFi y BLE al mismo tiempo, por lo que se debe cerrar la conexión BLE para poder trabajar con WiFi y viceversa. Para esto, les puede ser útil simplemente reiniciar el ESP32 cuando se cambie el estado de la base de datos e inicializarla con el nuevo estado. Con esto surge un nuevo problema: ¿dónde queda la información de qué protocolo usar después de reiniciar el ESP32?

Para esto les será útil el uso de la memoria no volátil (en el apunte se explica cómo utilizarla). De esta forma, cuando al ESP32 le llegue una configuración nueva, la guardará en la memoria no volátil y, cuando se reinicie el ESP32, esta leerá la configuración guardada en la memoria no volátil y se inicializará con esta.

Encabezados de los paquetes #

Cada paquete deberá contar con su propio encabezado, que incluirá la siguiente información. Este será común para todos los protocolos de envío:

Protocolos de envío #

Los protocolos de envío determinan la forma y el contenido que deben seguir los paquetes enviados por los ESP32. Estos paquetes se enviarán a través de TCP o UDP, dependiendo de la configuración asignada a la ESP32, la cual se encuentra en la base de datos.

En resumen, cada protocolo de envío tiene la estructura Headers + Body. El “Body” contiene los datos que se enviarán, los cuales están especificados en las tablas anteriores. Este “Body” depende del protocolo de envío que se haya configurado en la base de datos.

Generacion de datos #

Acceloremeter_kpi: Representa un sensor de vibraciones que mide en los tres ejes y calcula su promedio mediante la fórmula de la raíz cuadrada de la media (RMS). Los valores son float y se generan con las siguientes fórmulas:

• Ampx: Valores aleatorios entre 0.0059 y 0.12
• Freqx: Valores aleatorios entre 29.0 y 31.0
• Ampy: Valores aleatorios entre 0.0041 y 0.11
• Freqy: Valores aleatorios entre 59.0 y 61.0
• Ampz: Valores aleatorios entre 0.008 y 0.15
• Freqz: Valores aleatorios entre 89.0 y 91.0
• RMS: sqrt{(Ampx^2 + Ampy^2 + Ampz^2)}

Acceloremeter_Sensor: Un medidor de aceleración que genera un vector de 2000 datos por eje (X,Y,Z) para sus dos parámetros: aceleración y velocidad angular. Los datos son float y se generan con las siguientes fórmulas:

• Acc_X: Valores aleatorios entre -16.0 y 16.0
• Acc_Y: Valores aleatorios entre -16.0 y 16.0
• Acc_Z: Valores aleatorios entre -16.0 y 16.0
• Rgyr_X: Valores aleatorios entre -1000 y 1000
• Rgyr_Y: Valores aleatorios entre -1000 y 1000
• Rgyr_Z: Valores aleatorios entre -1000 y 1000

THPC_Sensor (Temperatura-Humedad-Presión-CO): Representa un sensor de cada uno de estos aspectos. Los valores son enteros, excepto para CO que es float.

• Temp: Valor aleatorio entre 5 y 30
• Hum: Valor aleatorio entre 30 y 80
• Pres: Valor aleatorio entre 1000 y 1200
• CO: Valor aleatorio entre 30 y 200

Batt_Sensor: Representa el nivel de batería del aparato. El valor es un u_int8 aleatorio entre 1 y 100.

Base de Datos #

La base de datos debe contener las siguientes tablas (las mismas que en la tarea anterior a excepción de la tabla Configuración)):

• Datos: Esta tabla almacenará todos los datos recibidos, incluyendo un sello de tiempo (timestamp) y el identificador del dispositivo (Id_device y MAC).

• Logs: Esta tabla registrará la información de cada conexión recibida por el servidor, incluyendo el ID_device, el tipo de capa de transporte (Transport_Layer), el protocolo utilizado y su timestamp.

• Configuración:: Esta tabla almacenará la configuración actual de la ESP32, es decir el estado del sistema (medio de comunicación, protocolo de envío y capa de transporte) y configuraciones para su funcionamiento. Esta tabla debe ser modificada por la API HTTP.

  • ID_protocol: Protocolo de envío
  • Transport_Layer: BLE Continuo, BLE Discontinuo, TCP o UDP
  • TCP_PORT: Puerto del servidor TCP
  • UDP_PORT: Puerto del servidor UDP
  • Gyro_sensibility: Sensibilidad del giroscopio
  • Acc_sensibility: Sensibilidad del acelerómetro
  • Acc_sampling_rate: Frecuencia de muestreo del acelerómetro
  • Gyro_sampling_rate: Frecuencia de muestreo del giroscopio
  • Discontinous_time: Tiempo de espera entre paquetes en modo BLE discontinuo y TCP
  • Host_ip_address: Dirección IP de la Raspberry Pi
  • Wifi_ssid: Nombre de la red WiFi
  • Wifi_password: Contraseña de la red WiFi

• Loss: Esta tabla almacenará el tiempo de demora en la comunicación (tiempo desde el momento de envío hasta el momento de escritura en la base de datos, calculado usando la diferencia entre esos timestamps) y la cantidad de pérdida de paquetes (packet loss) en bytes para cada comunicación que haya ocurrido.

Entrega #

1. Una demostración en vivo del funcionamiento del sistema el [dia por definir].

2. En el readme de su repositorio de Git, agregar una descripción de la tarea, los integrantes del grupo y una explicación de lo realizado.

3. Subir el código a U-cursos (Plazo en U-cursos). Si es posible, incluya un enlace a un repositorio de Git donde se trabajó en la tarea.

Recomendaciones #

• Es importante que separen la logica en 3 componentes, de esta forma podran trabajar de forma mas ordenada y eficiente, de tal forma que la base de datos siempre sea la fuente de verdad y los otros componentes solo se encarguen de leerla y modificarla.

  • La base de datos
  • La Interfaz Web y la API HTTP
  • Su servidor/cliente en python con la ESP32

• El uso de la memoria no volatil es fundamental para poder guardar la configuracion de la ESP32 y que esta se mantenga luego de un reinicio.

• Cualquier duda que tengan, no duden en preguntar al cuerpo docente.

Plantilla #

Dentro del README.md (Leanlo!) de la plantilla se encuentra la informacion necesaria para poder utilizarla.

• Plantilla de la tarea