Investigación y caracterización técnica de sensores
Antes de integrar múltiples sensores en un sistema centralizado de adquisición de datos, es necesario comprender el comportamiento individual de cada módulo.
En esta actividad, cada grupo trabajará con un único sensor del kit basado en Arduino Mega 2560.
El objetivo no es simplemente “hacerlo funcionar”, sino:
Comprender qué magnitud física mide.
Analizar cómo genera la señal.
Probar su funcionamiento real.
Documentar técnicamente su comportamiento.
Proponer su integración futura en RaspiAlarm.
Cada grupo deberá:
Conectar el sensor al Arduino.
Desarrollar un programa mínimo funcional.
Obtener lecturas reales.
Documentar todo el proceso en un README técnico.
Entregar código y pruebas.
El resultado final de esta fase será un catálogo técnico de sensores que servirá como base para la arquitectura global del sistema.
📘 3️⃣ LISTA DE SENSORES DEL KIT (Asignación por grupo)
Utilizando exclusivamente material típico de un kit compatible con Arduino Mega 2560.
Lista propuesta:
Grupo 1 – Sensor DHT11 (Temperatura y Humedad) Grupo 2 – HC-SR04 (Ultrasonidos) Grupo 3 – Sensor PIR (Movimiento) Grupo 4 – Sensor de llama Grupo 5 – Sensor de sonido (KY-038) Grupo 6 – Sensor LDR (Luz) Grupo 7 – Sensor de humedad del suelo Grupo 8 – Sensor de inclinación (Tilt Switch)
Cada grupo solo puede trabajar con su sensor asignado.
📘 4️⃣ Almacenamiento de datos
Arduino Mega 2560 envíe datos por USB y que Windows los guarde automáticamente en el PC.
Nada de herramientas raras. Solo:
Windows
IDE de Arduino
Cable USB
Python (para capturar y guardar datos)
Arquitectura mental:
Sensor → Arduino → USB (Serial) → PC → Archivo CSV
Eso es adquisición de datos básica. Ciencia aplicada.
PARTE 4 – Instalar librería para comunicación serie
Abrir:
Inicio → escribir “cmd” → Enter
Ejecutar:
pip install pyserial
Si aparece “Successfully installed”, está correcto.
PARTE 5 – Crear el programa que guarda datos
5.1 Crear archivo
En el escritorio:
Crear archivo llamado:
guardar_datos.py
Abrir con Bloc de notas y pegar:
import serial
import csv
from datetime import datetime
# CAMBIAR ESTE PUERTO POR EL CORRECTO
PUERTO = "COM3"
BAUDIOS = 9600
try:
ser = serial.Serial(PUERTO, BAUDIOS, timeout=1)
except:
print("No se puede abrir el puerto. Verifica el COM.")
exit()
archivo = open("datos_sensores.csv", mode="a", newline="")
writer = csv.writer(archivo, delimiter=";")
print("Capturando datos... Presiona Ctrl+C para detener.")
try:
while True:
linea = ser.readline().decode("utf-8").strip()
if linea:
timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
datos = linea.split(";")
fila = datos + [timestamp]
writer.writerow(fila)
archivo.flush()
print(fila)
except KeyboardInterrupt:
print("Finalizando captura...")
archivo.close()
ser.close()
En esta práctica vais a construir un pequeño sistema de adquisición de datos distribuido. En lugar de trabajar con un único sensor conectado a un solo dispositivo, vais a montar una arquitectura formada por varios Arduinos, cada uno con uno o varios sensores, y una Raspberry Pi que actuará como centro de recepción y almacenamiento.
El objetivo no es solo «leer sensores», sino comprender cómo se organiza un sistema real donde varios nodos capturan información y un equipo central la recibe, la procesa y la guarda para su análisis posterior.
Este tipo de arquitectura se parece mucho a sistemas reales de monitorización, automatización, IoT, domótica o control industrial.
2. Objetivos de la práctica
Al finalizar la práctica, debéis ser capaces de:
Conectar sensores a varios Arduinos.
Leer datos de sensores desde Arduino.
Enviar esos datos por comunicación serie a través de USB.
Conectar varios Arduinos a una Raspberry Pi.
Identificar los puertos serie de cada Arduino en Linux.
Crear en la Raspberry Pi un programa en Python que reciba datos desde varios Arduinos.
Guardar los datos recibidos en archivos CSV o JSON.
Documentar correctamente el montaje, el código y el funcionamiento del sistema.
3. Descripción general del sistema
La arquitectura general de la práctica será la siguiente:
18. Script Python de ejemplo para varios Arduinos y CSV
import serial
import threading
import csv
import os
from datetime import datetime
PUERTOS = [
"/dev/ttyACM0",
"/dev/ttyACM1",
"/dev/ttyACM2"
]
BAUDIOS = 9600
ARCHIVO_CSV = "datos_sensores.csv"
CAMPOS = ["timestamp", "arduino", "sensor", "valor"]
lock_csv = threading.Lock()
def parsear_linea(linea):
datos = {}
partes = linea.strip().split(";")
for parte in partes:
if "=" in parte:
clave, valor = parte.split("=", 1)
datos[clave.strip()] = valor.strip()
return datos
def inicializar_csv():
if not os.path.exists(ARCHIVO_CSV) or os.path.getsize(ARCHIVO_CSV) == 0:
with open(ARCHIVO_CSV, "w", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=CAMPOS)
writer.writeheader()
def guardar_csv(registro):
with lock_csv:
with open(ARCHIVO_CSV, "a", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=CAMPOS)
writer.writerow(registro)
def escuchar_puerto(puerto):
try:
ser = serial.Serial(puerto, BAUDIOS, timeout=1)
print(f"Escuchando {puerto}")
while True:
linea = ser.readline().decode("utf-8", errors="ignore").strip()
if linea:
print(f"{puerto} -> {linea}")
datos = parsear_linea(linea)
if "arduino" in datos and "sensor" in datos and "valor" in datos:
registro = {
"timestamp": datetime.now().strftime("%Y-%m-%d %H:%M:%S"),
"arduino": datos["arduino"],
"sensor": datos["sensor"],
"valor": datos["valor"]
}
guardar_csv(registro)
except Exception as e:
print(f"Error en {puerto}: {e}")
def main():
inicializar_csv()
hilos = []
for puerto in PUERTOS:
hilo = threading.Thread(target=escuchar_puerto, args=(puerto,), daemon=True)
hilo.start()
hilos.append(hilo)
for hilo in hilos:
hilo.join()
if __name__ == "__main__":
main()
19. Script Python de ejemplo para guardar en JSON
import serial
import threading
import json
from datetime import datetime
PUERTOS = [
"/dev/ttyACM0",
"/dev/ttyACM1"
]
BAUDIOS = 9600
ARCHIVO_JSON = "datos_sensores.jsonl"
lock_json = threading.Lock()
def parsear_linea(linea):
datos = {}
partes = linea.strip().split(";")
for parte in partes:
if "=" in parte:
clave, valor = parte.split("=", 1)
datos[clave.strip()] = valor.strip()
return datos
def guardar_json(registro):
with lock_json:
with open(ARCHIVO_JSON, "a", encoding="utf-8") as f:
f.write(json.dumps(registro, ensure_ascii=False) + "\n")
def escuchar_puerto(puerto):
try:
ser = serial.Serial(puerto, BAUDIOS, timeout=1)
print(f"Escuchando {puerto}")
while True:
linea = ser.readline().decode("utf-8", errors="ignore").strip()
if linea:
print(f"{puerto} -> {linea}")
datos = parsear_linea(linea)
if "arduino" in datos and "sensor" in datos and "valor" in datos:
registro = {
"timestamp": datetime.now().strftime("%Y-%m-%d %H:%M:%S"),
"arduino": datos["arduino"],
"sensor": datos["sensor"],
"valor": datos["valor"]
}
guardar_json(registro)
except Exception as e:
print(f"Error en {puerto}: {e}")
def main():
hilos = []
for puerto in PUERTOS:
hilo = threading.Thread(target=escuchar_puerto, args=(puerto,), daemon=True)
hilo.start()
hilos.append(hilo)
for hilo in hilos:
hilo.join()
if __name__ == "__main__":
main()
FASE 7. Ejecución del programa
20. Guardar y ejecutar el script
Guardad el script con un nombre como:
nano receptor_sensores.py
Pegad el código, guardadlo y ejecutadlo:
python3 receptor_sensores.py
Si todo funciona, deberíais ver en pantalla líneas como estas:
Esta práctica os permitirá trabajar con una arquitectura completa de adquisición de datos usando varios microcontroladores y un sistema Linux central.
No se trata solo de conectar cables y leer números, sino de entender cómo diseñar un sistema modular, organizado y ampliable. Ese enfoque es mucho más valioso que hacer una sola lectura aislada en un monitor serie.
Cuando el sistema funcione, habréis construido una pequeña red de sensores con almacenamiento centralizado, algo muy cercano a muchos proyectos reales de automatización, IoT y monitorización.
En esta práctica vas a convertir tu Raspberry Pi en un pequeño nodo autónomo de captura de datos dentro del proyecto RaspyAlarma.
Tu Raspberry deberá ser capaz de:
leer los datos de un sensor con Python,
guardar esas lecturas en una base de datos MariaDB,
ejecutar ese proceso automáticamente cada cierto tiempo mediante cron,
y dejar preparada la información para una futura sincronización con un servidor central.
Todos los alumnos deberán usar la misma estructura de base de datos, ya que más adelante será necesario unificar los datos de todos los sensores y de todas las Raspberry del proyecto.
Objetivo general
El objetivo de esta práctica es crear un sistema automático en el que una Raspberry:
lea un sensor,
almacene la lectura en una base de datos local,
identifique de qué Raspberry procede el dato,
indique si la lectura representa o no una situación de alerta,
y marque si ese dato ya fue enviado o no al servidor central.
Estructura obligatoria de la base de datos
Todos los alumnos deberán usar una base de datos llamada exactamente:
raspialarm
Y una tabla llamada exactamente:
lecturas_sensores
Estructura obligatoria de la tabla
La tabla deberá contener estos campos:
id
raspberry_id
nombresensor
lectura1
lectura2
lectura3
fecha_hora
alumnoEncargado
descripcionSensor
estado_alerta
enviado_central
Significado de los campos
raspberry_id
Este campo servirá para identificar qué Raspberry ha generado la lectura.
Ejemplos válidos:
RPI01
RPI_AULA_01
RPI_PASILLO
RPI_HABITACION_3
Este identificador debe ser fijo para cada Raspberry y no debe cambiar entre ejecuciones.
estado_alerta
Este campo servirá para indicar el estado de la lectura.
Valores recomendados:
normal
aviso
critico
No todos los sensores tendrán alertas complejas al principio, pero el campo debe existir ya desde esta fase.
Ejemplo:
una lectura dentro de lo normal → normal
una lectura elevada pero no crítica → aviso
una lectura peligrosa o fuera de umbral → critico
enviado_central
Este campo servirá para saber si esa lectura ya ha sido enviada al servidor central del proyecto.
Valores recomendados:
0 → todavía no se ha enviado
1 → ya se ha enviado
En esta práctica, normalmente todos los registros nuevos se guardarán inicialmente con valor 0.
Parte 1. Crear la base de datos
Paso 1. Comprobar que MariaDB está activa
Abre una terminal y ejecuta:
sudo systemctl status mariadb
Si no estuviera arrancada:
sudo systemctl start mariadb
Y para dejarla activada al iniciar el sistema:
sudo systemctl enable mariadb
Paso 2. Entrar en MariaDB
sudo mariadb
Paso 3. Crear la base de datos
Dentro de MariaDB:
CREATE DATABASE raspialarm; SHOW DATABASES; USE raspialarm;
Parte 2. Crear la tabla común del proyecto
Ejecuta esta instrucción SQL exactamente como aparece:
CREATE TABLE lecturas_sensores ( id INT AUTO_INCREMENT PRIMARY KEY, raspberry_id VARCHAR(50) NOT NULL, nombresensor VARCHAR(100) NOT NULL, lectura1 DECIMAL(10,2), lectura2 DECIMAL(10,2), lectura3 DECIMAL(10,2), fecha_hora DATETIME NOT NULL, alumnoEncargado VARCHAR(100) NOT NULL, descripcionSensor VARCHAR(255), estado_alerta VARCHAR(20) NOT NULL DEFAULT 'normal', enviado_central TINYINT(1) NOT NULL DEFAULT 0 );
Paso 4. Comprobar la estructura de la tabla
DESCRIBE lecturas_sensores;
También puedes verla completa con:
SHOW CREATE TABLE lecturas_sensores;
Parte 3. Crear un usuario específico para la aplicación
No debes usar root dentro del script Python.
Ejecuta:
CREATE USER 'raspiuser'@'localhost' IDENTIFIED BY 'raspi1234'; GRANT ALL PRIVILEGES ON raspialarm.* TO 'raspiuser'@'localhost'; FLUSH PRIVILEGES; EXIT;
En la práctica anterior has preparado tu Raspberry Pi para que lea datos de un sensor con Python y los almacene automáticamente en una base de datos MariaDB llamada raspialarm.
Ahora toca construir la siguiente pieza del sistema: un visualizador web en PHP que permita consultar las lecturas almacenadas.
El objetivo es que tu Raspberry no solo capture y guarde información, sino que además pueda mostrarla en una página web accesible desde el navegador.
Este visualizador será la base para futuros paneles más avanzados del proyecto RaspyAlarma, donde más adelante podrás añadir filtros, alertas visuales, gráficas y conexión con un servidor central.
Objetivo de la práctica
En esta práctica vas a crear un pequeño panel web en PHP que:
se conecte a la base de datos raspialarm,
lea los registros de la tabla lecturas_sensores,
muestre los datos en una tabla HTML,
permita visualizar las lecturas más recientes,
muestre información útil como el estado de alerta y si el dato fue enviado al servidor central.
Qué vas a construir
Al finalizar la práctica tendrás:
una carpeta web del proyecto,
un archivo de conexión a MariaDB,
una página PHP que recupere datos de la tabla,
una tabla HTML con todas las lecturas,
una versión mejorada con formato visual,
y un pequeño panel base para seguir ampliando en el futuro.
Requisitos previos
Antes de empezar debes tener ya preparado lo siguiente:
una Raspberry Pi funcionando,
Apache y PHP instalados,
MariaDB instalada y operativa,
la base de datos raspialarm creada,
la tabla lecturas_sensores creada,
y varios registros insertados desde el script Python.
Si todavía no tienes registros en la base de datos, primero debes completar la práctica anterior.
Estructura esperada de la base de datos
La práctica parte de esta tabla:
id
raspberry_id
nombresensor
lectura1
lectura2
lectura3
fecha_hora
alumnoEncargado
descripcionSensor
estado_alerta
enviado_central
Qué debe hacer el visualizador
El visualizador deberá mostrar como mínimo:
el identificador del registro,
el identificador de la Raspberry,
el nombre del sensor,
las tres lecturas,
la fecha y hora,
el alumno encargado,
la descripción del sensor,
el estado de alerta,
y el estado de envío al servidor central.
Parte 1. Comprobar que Apache, PHP y MariaDB están funcionando
Paso 1. Comprobar Apache
Abre una terminal y ejecuta:
sudo systemctl status apache2
Si no estuviera arrancado:
sudo systemctl start apache2
Y para dejarlo activado al inicio:
sudo systemctl enable apache2
Paso 2. Comprobar MariaDB
sudo systemctl status mariadb
Si no estuviera arrancada:
sudo systemctl start mariadb
Paso 3. Comprobar PHP
Ejecuta:
php -v
Esto debe mostrarte la versión de PHP instalada.
Parte 2. Preparar la carpeta del proyecto web
Tu visualizador web se guardará dentro del directorio servido por Apache.
🎧 Resumen en audio del tema Escucha este breve audio para repasar las ideas principales de la tarea antes de continuar o al finalizar la lectura.
Introducción
Hasta este momento, varias Raspberry Pi del proyecto RaspyAlarma ya son capaces de leer información de sensores y almacenarla en una base de datos local. Ese primer paso permite que cada nodo funcione de manera autónoma y conserve sus propias lecturas.
Ahora vamos a dar el siguiente salto: construir un servidor central que reciba los datos generados por todas las Raspberry y los almacene en una base de datos general. A partir de esa información centralizada, desarrollaremos también una interfaz web que permita consultar el estado de todos los sensores, visualizar gráficas, detectar alertas y disponer de un histórico común.
Aunque en un sistema real normalmente existiría un único servidor central, en esta práctica se permitirá que el alumnado trabaje de forma flexible: pueden hacerlo individualmente o en grupos, e incluso pueden desplegar más de un servidor central para repartir tareas y favorecer la participación.
Reto del proyecto
Debéis construir el servidor central del sistema RaspyAlarma. Este servidor se ejecutará en una máquina virtual Ubuntu alojada en Proxmox y será el encargado de recibir, almacenar y mostrar las lecturas de sensores enviadas por distintas Raspberry Pi.
Cada Raspberry seguirá guardando sus datos en local, pero además tendrá que sincronizar los registros pendientes con la base de datos central. A partir de esta información, deberéis desarrollar una interfaz web que permita visualizar el estado de todos los sensores, consultar históricos y representar gráficas.
El objetivo no es solo almacenar datos, sino crear una arquitectura distribuida funcional, organizada y ampliable, similar a la que podría utilizarse en un entorno profesional real.
Objetivos del proyecto
Al finalizar esta práctica, el alumnado deberá ser capaz de:
Desplegar una máquina virtual Ubuntu en Proxmox que actuará como servidor central.
Instalar y configurar en ella los servicios necesarios.
Diseñar una base de datos central para almacenar las lecturas de todas las Raspberry.
Implementar un mecanismo para recibir datos desde los nodos remotos.
Guardar las lecturas recibidas en una base de datos general.
Crear una interfaz web para visualizar la información agregada.
Mostrar listados, filtros, estados de alerta y gráficas.
Comprender la diferencia entre almacenamiento local en nodos y centralización de información.
Simular una arquitectura real de monitorización distribuida.
Escenario de trabajo
Imaginad que habéis diseñado un sistema de asistencia y monitorización distribuido. Cada Raspberry Pi recoge lecturas de sensores instalados en distintos puntos y almacena esos datos localmente. Sin embargo, eso no es suficiente para gestionar el sistema completo.
Necesitamos un centro de control, una máquina central capaz de:
Recibir información desde todas las Raspberry.
Unificar los datos en una sola base de datos.
Mostrar el estado general del sistema.
Generar paneles visuales con tablas y gráficas.
Identificar situaciones de alerta.
Servir como base para futuras ampliaciones, como envío de correos, paneles de incidencias o integración con otros sistemas.
Arquitectura propuesta
La arquitectura recomendada para esta práctica será la siguiente:
Nodo Raspberry Pi
Cada Raspberry:
Lee sensores localmente.
Guarda sus lecturas en su propia base de datos.
Identifica qué registros todavía no han sido enviados al servidor central.
Envía únicamente esos registros pendientes.
Marca los registros como enviados cuando el servidor central los confirma.
Servidor central Ubuntu
La máquina virtual Ubuntu:
Ejecuta Apache o Nginx.
Ejecuta PHP para la parte web y la recepción de datos.
Ejecuta MariaDB o MySQL para almacenar todas las lecturas.
Expone una ruta o endpoint para recibir los datos enviados por las Raspberry.
Ofrece un panel web para visualizar y analizar la información.
Idea importante de diseño
Aunque técnicamente se podría hacer que el servidor central se conecte a las bases de datos de las Raspberry y “tire” de los datos, no es la opción recomendada para esta práctica.
La mejor solución didáctica y técnica es esta:
La Raspberry guarda sus lecturas en local.
La Raspberry envía periódicamente los registros pendientes al servidor central.
El servidor central responde confirmando la recepción.
La Raspberry marca esos registros como enviados.
Este enfoque tiene varias ventajas:
Es más realista.
Es más seguro.
Evita abrir las bases de datos de las Raspberry al exterior.
Reduce problemas de conectividad.
Permite trabajar con sincronización parcial y tolerancia a fallos.
Requisitos de la práctica
El sistema deberá cumplir, como mínimo, con los siguientes requisitos.
En el servidor central
Máquina virtual Ubuntu funcionando en Proxmox.
IP fija o localizable dentro de la red.
Apache + PHP + MariaDB instalados.
Base de datos central creada.
Endpoint de recepción de datos funcionando.
Interfaz web operativa.
En las Raspberry
Base de datos local con lecturas ya almacenadas.
Script de sincronización hacia el servidor central.
Uso de un identificador único de Raspberry.
Campo que indique si el registro ya fue enviado.
Capacidad para reenviar registros pendientes si hubo error.
Tecnologías recomendadas
Para esta práctica se recomienda utilizar:
Proxmox para alojar la máquina virtual.
Ubuntu Server como sistema operativo del servidor central.
Apache como servidor web.
PHP para el desarrollo del endpoint y del panel web.
MariaDB/MySQL como sistema gestor de base de datos.
Python en las Raspberry para el envío de datos.
Cron para automatizar los envíos periódicos.
Chart.js para representar gráficas en la interfaz web.
Parte 1 – Creación del servidor central
Paso 1. Crear la máquina virtual en Proxmox
Cada grupo o alumno deberá crear una máquina virtual Ubuntu en Proxmox que actuará como servidor central.
Características recomendadas
2 vCPU
2 GB o 4 GB de RAM
20 GB de disco
Ubuntu Server
Adaptador de red en la misma red que las Raspberry
Tareas
Crear la VM.
Instalar Ubuntu Server.
Configurar nombre del equipo.
Configurar acceso por usuario y contraseña.
Anotar la IP asignada.
Recomendación
Es buena idea asignar una IP fija o una reserva DHCP, para que las Raspberry sepan siempre a qué dirección enviar los datos.
Cread la base de datos general del proyecto. Por ejemplo:
CREATE DATABASE raspialarma_central;
Después, cread un usuario específico para la aplicación:
CREATE USER 'raspyadmin'@'localhost' IDENTIFIED BY 'TuPasswordSegura'; GRANT ALL PRIVILEGES ON raspialarma_central.* TO 'raspyadmin'@'localhost'; FLUSH PRIVILEGES; EXIT;
Parte 2 – Diseño de la base de datos central
Paso 5. Crear la tabla principal de lecturas
La tabla central debe recoger información común de todas las Raspberry y de todos los sensores.
Estructura recomendada
USE raspialarma_central;CREATE TABLE lecturas_centrales ( id INT AUTO_INCREMENT PRIMARY KEY, id_raspberry VARCHAR(100) NOT NULL, nombresensor VARCHAR(100) NOT NULL, lectura1 VARCHAR(100), lectura2 VARCHAR(100), lectura3 VARCHAR(100), fecha_hora DATETIME NOT NULL, alumnoEncargado VARCHAR(100), descripcionSensor TEXT, estado_alerta VARCHAR(50) DEFAULT 'normal', fecha_recepcion TIMESTAMP DEFAULT CURRENT_TIMESTAMP, origen_ip VARCHAR(100), hash_registro VARCHAR(255), UNIQUE KEY unique_registro (id_raspberry, nombresensor, fecha_hora, hash_registro) );
Explicación de algunos campos importantes
id_raspberry
Identifica de forma única de qué Raspberry procede el dato.
estado_alerta
Permite saber si la lectura está en estado normal, aviso o alerta.
fecha_recepcion
Indica cuándo llegó el registro al servidor central.
origen_ip
Puede almacenar la IP desde la que se envió el dato.
hash_registro
Sirve para evitar duplicados si una Raspberry vuelve a mandar el mismo dato.
Mejora interesante
También podéis crear una tabla de nodos Raspberry:
CREATE TABLE raspberries (
id INT AUTO_INCREMENT PRIMARY KEY,
id_raspberry VARCHAR(100) UNIQUE NOT NULL,
nombre VARCHAR(100),
ubicacion VARCHAR(100),
descripcion TEXT,
ultima_conexion DATETIME,
estado VARCHAR(50) DEFAULT 'activo'
);
Esto os permitirá saber qué nodos existen, cuál fue su última conexión y tener una visión más ordenada del sistema.
Parte 3 – Recepción de datos en el servidor central
Paso 6. Crear el endpoint de recepción
En el servidor Ubuntu, cread una carpeta para vuestra aplicación:
Para que no cualquier equipo mande datos falsos, podéis añadir una clave compartida o token simple.
Por ejemplo, que cada Raspberry envíe también:
api_key
o una cabecera personalizada
Y el servidor compruebe que coincide con la esperada.
No hace falta complicarlo demasiado: para una práctica educativa, una clave sencilla ya es suficiente para introducir el concepto de autenticación entre máquinas.
Parte 4 – Sincronización desde las Raspberry
Paso 7. Adaptar el script Python de cada Raspberry
Cada Raspberry ya guarda datos en local. Ahora deberá además:
Consultar en su base de datos local los registros no enviados.
Preparar un JSON con esos registros.
Enviarlo al servidor central.
Si el servidor responde correctamente, marcar esos registros como enviados.
Lógica del proceso
El flujo correcto debería ser este:
La Raspberry lee el sensor.
Inserta la lectura en su base local.
Cada cierto tiempo, otro script consulta los registros con enviado_central = 0.
Los envía al servidor central.
Si el servidor responde correctamente, esos registros pasan a enviado_central = 1.
Campo obligatorio en la base local
Recordad que la tabla local de cada Raspberry debe incluir algo como:
id_raspberry
estado_alerta
enviado_central
Esto permitirá gestionar la sincronización correctamente.
Frecuencia de envío
Podéis programar el script para que se ejecute con cron cada:
1 minuto
5 minutos
o el intervalo que considere el grupo
Eso dependerá del ritmo de captura de datos.
Parte 5 – Interfaz web del servidor central
Paso 8. Crear el panel web principal
Una vez que el servidor central ya recibe datos, habrá que crear una web que muestre toda la información agregada.
La interfaz deberá desarrollarse en PHP y deberá leer los datos desde la base de datos central.
Contenido mínimo del panel
El panel debería mostrar, como mínimo:
Vista general
Número total de lecturas recibidas.
Número de Raspberry activas.
Número de sensores registrados.
Número de alertas.
Tabla de lecturas
ID
Raspberry origen
Nombre del sensor
Lecturas
Fecha y hora
Estado de alerta
Filtros
Filtrar por Raspberry
Filtrar por sensor
Filtrar por fecha
Filtrar por estado de alerta
Gráficas
Evolución temporal de un sensor
Número de alertas por nodo
Distribución de lecturas por tipo de sensor
Paso 9. Crear una portada tipo dashboard
Una buena práctica es construir una página principal con tarjetas o bloques visuales.
Ejemplo de bloques
Total de nodos conectados
Última lectura recibida
Sensores en alerta
Total de registros
Esto hace que el proyecto parezca mucho más profesional y permite al alumnado trabajar el diseño de interfaces orientadas a monitorización.
Paso 10. Crear gráficas con Chart.js
Para representar datos de forma visual, se recomienda utilizar Chart.js.
Ejemplos de gráficas que podéis pedir:
Temperatura a lo largo del tiempo
Número de lecturas por Raspberry
Estados de alerta por tipo de sensor
Comparativa entre varios nodos
Paso 11. Crear una página de detalle por Raspberry
Además del panel general, es muy interesante que exista una vista individual para cada Raspberry.
Esa página podría mostrar:
Identificador del nodo
Ubicación
Última conexión
Sensores asociados
Histórico de lecturas
Alertas detectadas
Esto da una estructura mucho más completa al proyecto.
Parte 6 – Funcionalidades extra recomendadas
Aquí es donde puedes enriquecer muchísimo el proyecto.
1. Sistema de alertas visuales
Si una lectura supera un umbral, mostrarla en rojo o destacarla visualmente.
Ejemplos:
Temperatura demasiado alta
Humedad anómala
Falta de actualización de un nodo
2. Detección de Raspberry inactivas
Si una Raspberry no envía datos en un tiempo determinado, el panel puede marcarla como:
Activa
Inactiva
Desconectada
Esto es muy útil en un sistema distribuido real.
3. Registro de logs
Crear una tabla o archivo de log donde quede constancia de:
Envíos recibidos
Fallos de sincronización
Intentos inválidos
Errores de base de datos
Así introducís el concepto de auditoría del sistema.
4. Histórico de incidencias
Podéis añadir una tabla para guardar incidencias detectadas:
Fecha
Raspberry
Tipo de problema
Descripción
Estado de resolución
5. Exportación de datos
Añadir una opción para exportar lecturas en CSV.
Esto da mucho valor al proyecto porque permite luego tratar la información en Excel, LibreOffice Calc o herramientas de análisis.
6. Panel responsive
Hacer que la web se vea razonablemente bien en móvil, tablet y PC.
7. Inicio de sesión
Como ampliación, podéis pedir una pequeña autenticación en PHP para que el panel central no sea público.
8. Mapa o distribución física
Si queréis darle más fuerza visual, podéis representar cada Raspberry por ubicación o sala.
Entregables
Entregable 1 – Infraestructura
Documento con:
Nombre del servidor
IP
Capturas de la VM
Servicios instalados
Entregable 2 – Base de datos
Script SQL de creación
Explicación de tablas
Justificación del diseño
Entregable 3 – Recepción de datos
Código del endpoint
Ejemplo de JSON recibido
Capturas de pruebas correctas
Entregable 4 – Sincronización
Script Python de envío
Consulta de pendientes
Marcado de enviados
Entregable 5 – Panel web
Capturas del dashboard
Tablas
Filtros
Gráficas
Entregable 6 – Mejoras
Seguridad
Logs
Alertas
Exportación
Detección de nodos inactivos
Criterios de evaluación orientativos
Puedes evaluarlo así:
Diseño de arquitectura
Claridad del planteamiento
Separación entre nodo y central
Coherencia técnica
Base de datos
Estructura correcta
Uso de claves
Evitar duplicados
Campos útiles
Comunicación entre sistemas
Envío correcto de datos
Gestión de errores
Registros marcados como enviados
Interfaz web
Funcionalidad
Claridad visual
Utilidad de filtros
Gráficas correctas
Mejoras
Seguridad
Alertas
Logs
Exportación
Control de nodos
Documentación
Orden
Explicaciones
Capturas
Comprensión real del sistema
Resultado final esperado
Al terminar la práctica, el alumnado habrá construido un sistema completo con esta lógica:
Varias Raspberry recogen datos.
Cada una los almacena localmente.
Cada una sincroniza con el servidor central.
El servidor central unifica la información.
Un panel web muestra todo el sistema de manera visual y organizada.
En otras palabras, no habrán hecho solo una página PHP, sino una infraestructura distribuida de monitorización, que ya se parece bastante a una solución profesional real.
Ampliaciones que puedes realizar
Esto te puede venir bien para futuras fases del proyecto:
Envío de correos de alerta
Cuando un sensor entre en estado crítico, enviar correo automático.
API REST real
En lugar de un PHP simple, crear una pequeña API con rutas más organizadas.
Panel de administración
Permitir alta de nodos, edición de sensores y gestión de incidencias.
Copias de seguridad
Programar backups automáticos de la base de datos central.
