IFTS 14 2025 TS SEIC Protocolo de IoT

------------------------------------------------------

Aquí tienes un ordenamiento lógico, temático y comentado de los recursos que compartiste, clasificados según su relevancia para el armado de una estación meteorológica inteligente basada en ESP32, con subdivisiones claras por temas clave del proyecto.

🧠 1. Proyectos de referencia completos

Estos son ideales como base conceptual y técnica. Incluyen sensores, conexiones, programación y visualización.

🔹 The DIY Life - IoT Weather Station Using ESP32

🔧 Relevancia alta. Proyecto integral con sensores de temperatura, humedad, presión y lluvia. Usa ESP32 y MQTT. Tiene diseño de carcasa 3D e interfaz web.

Ideal como estructura base de todo el proyecto, incluye montaje, electrónica y software.

🔹 Instructables - DIY Weather Station With ESP32

🔧 Relevancia alta. Similar al anterior, incluye sensores comunes y uso de BME280. Enfocado a principiantes.

Útil para complementar la estación con sensores económicos y código Arduino claro.

🌬️ 2. Sensores y medición del viento

Aquí se agrupan los recursos para integrar anemómetro y veleta, claves para una estación más avanzada.

🔹 GitHub - Anemómetro IoT con MQTT y KNX

🔧 Relevancia alta. Incluye diseño funcional de anemómetro, código fuente y uso de MQTT.

Muy valioso para adaptar o integrar directamente en el sistema IoT.

🔹 Thingiverse - Wind Sensor V2.0 (Veleta y Anemómetro)

🧩 Relevancia alta. Modelo imprimible para sensores de viento.

Compatible con sensores de efecto Hall y ópticos. Fácil integración con ESP32.

🔹 Cults3D - Girouette capteur de vent

🧩 Relevancia media-alta. Modelo de veleta. Compatible con proyectos personalizados.

Puede adaptarse para usar con sensores Hall o interruptores magnéticos.

☀️ 3. Monitoreo solar y energía

Complemento útil si se desea hacer la estación autosuficiente con energía solar.

🔹 Instructables - DIY Solar PV Monitoring System V2.0

🔋 Relevancia media. Orientado al monitoreo de un sistema solar, pero incluye sensores de corriente, tensión, y visualización.

Útil si se alimenta la estación con paneles solares y se quiere monitorear su rendimiento.

🌡️ 4. Referencias de datos y validación

Para comparar o validar tus mediciones reales con datos públicos.

🔹 Weather Underground - Clima en Buenos Aires

📊 Relevancia media. Provee registros históricos diarios del clima en Argentina.

Ideal para comparar y validar datos de tu estación.

🧾 5. Documentación compartida

Puede contener materiales de clase, esquemas o planificación complementaria.

🔹 Google Docs - Documento compartido

📄 Relevancia pendiente de análisis. Se requiere revisar el contenido exacto del documento.

Puede contener material didáctico o técnico útil para planificar clases o informes del proyecto.

🧱 6. Diseños 3D complementarios

Modelos 3D diversos para imprimir componentes como cajas, soportes, carcasas.

🔸 Thingiverse - Sensor Station with Stand (Thing: 3398980)

📦 Relevancia media. Estación modular, adaptable para sensores múltiples.

🔸 Thingiverse - Anemómetro impreso (Thing: 1416009)

🌬️ Relevancia media. Anemómetro básico impreso. Alternativa simple al anterior.

🔸 Thingiverse - Modular Weather Station (Thing: 3546977)

🧩 Relevancia media. Estación modular compacta, buena base física.

🔸 Thingiverse - Weather Station + Electronics Box (Thing: 4216504)

🧰 Relevancia media. Diseño integral de caja para electrónica de estación meteorológica.

🔸 Thingiverse - Solar Weather Station Case (Thing: 4355150)

☀️ Relevancia media. Diseño orientado a uso solar. Buena ventilación y soporte para sensores.

🔸 Thingiverse - Weather Station Shield (Thing: 7020450)

⚙️ Relevancia baja-media. Carcasa para protección de sensores, adaptable.

🔸 TurboSquid - Weather Station Model 3D

💰 Relevancia baja. Modelo profesional 3D no imprimible, decorativo.

Solo útil para renders o presentaciones, no para construcción real.

🧭 Orden sugerido para desarrollo del proyecto

1. Definición de objetivos funcionales

   • Usar [The DIY Life] como base funcional.

   • Complementar con sensores de viento del GitHub y Thingiverse.

2. Diseño físico y mecánico

   • Seleccionar modelos de impresión 3D: carcasa + sensores de viento.

3. Código y conexión

   • Unificar códigos de ESP32 para lectura de sensores y envío por MQTT.

4. Monitoreo y validación

   • Validar datos con fuentes como Weather Underground.

5. Optimización y expansión

   • Incluir energía solar.

   • Monitor solar PV si se desea autonomía.

6. Documentación final

   • Usar el Google Docs o generar uno nuevo para armar el informe del proyecto.

A continuación, les dejo una lista de sensores comunes y accesibles para una estación meteorológica inteligente, ordenados de menor a mayor precio/calidad aproximada, agrupados por tipo de magnitud (temperatura, humedad, etc.), y con especificación del tipo de salida (analógica o digital, I2C, SPI, 1-Wire, etc.).

🌡️ Temperatura

💧 Humedad Relativa

🌬️ Presión Atmosférica

💨 Velocidad y Dirección del Viento

🌧️ Precipitación (Pluviómetro)

✅ Resumen y recomendaciones por calidad/precio

Perfecto, vamos a hacer una estimación realista del uso de pines GPIO del ESP32 al conectar los sensores típicos de una estación meteorológica inteligente educativa, y luego vemos cuántos GPIO sobran para otras tareas (actuadores, botones, relés, etc.).

🧠 Premisas del análisis

1. Microcontrolador: ESP32-WROOM-32 (38 pines, doble núcleo).

2. Sensores elegidos (por balance precio/calidad):

   • BME280 (temperatura, humedad, presión) → I2C

   • DS18B20 (temperatura extra opcional) → 1-Wire

   • Anemómetro y veleta → Entradas digitales (reed switch o encoder)

   • Pluviómetro tipping bucket → Entrada digital

   • Sensor de lluvia (FC-28) → Entrada digital/analógica

3. Bus compartido cuando sea posible: I2C puede compartir hasta varios sensores.

📌 Asignación estimada de pines

🧮 Total de GPIO utilizados

• Entradas/salidas dedicadas a sensores:
  2 (I2C) + 1 (1-Wire) + 1 (Anemómetro) + 1 (Veleta) + 1 (Pluviómetro) + 1 (Lluvia FC-28) = 7 GPIO

• Extras posibles para actuadores: Supongamos 2 GPIO para relés o LEDs → 2 GPIO (salidas)

⚙️ ¿Cuántos GPIO quedan libres en el ESP32?

• El ESP32 tiene 25 GPIO usables aprox. (depende del modelo y si se usan interfaces como UART, SPI, etc.)

• Si usamos 7 GPIO para sensores y 2 para salidas:

  • GPIO libres restantes ≈ 16

🟢 GPIO disponibles típicos en ESP32 (para uso general)

✅ Resumen final

Tu enfoque es excelente: plantear una red de estaciones meteorológicas inteligentes permite abordar no solo aspectos técnicos (hardware, sensores, redes), sino también criterios científicos y estadísticos, como densidad de sensores, interpolación de datos y análisis en una central. Vamos por partes:

📍 ¿Cuántas estaciones meteorológicas serían necesarias para la CABA?

📌 1. Superficie de CABA:

• Aprox. 203 km²

• Muy urbanizada, con microclimas (cerca del río, zonas verdes, áreas con mucho cemento, etc.)

📌 2. Densidad típica recomendada (referencias internacionales):

• Para estudios locales/urbanos, la OMM (Organización Meteorológica Mundial) recomienda entre 1 estación cada 1-5 km².

• Para estudios educativos o semiprofesionales, una red de 1 estación cada 4-6 km² puede ser suficiente.

📌 3. Cálculo estimado:

• Con 1 estación cada 5 km² → 203 / 5 = ~40 estaciones

• Con 1 estación cada 10 km² → ~20 estaciones (para un enfoque educativo / demostrativo)

📌 Recomendación práctica educativa:
Entre 10 y 20 estaciones distribuidas estratégicamente, priorizando:

• Costas y parques

• Zonas densamente urbanizadas

• Centros educativos o instituciones

• Puntos altos vs. bajos en la ciudad

🧠 ¿Qué puede hacer la estación central con los datos?

Una “central” o servidor que reciba los datos de la red puede:

🔹 1. Visualización y monitoreo (web o dashboard):

• Mapa con ubicaciones y datos en tiempo real / histórico

• Gráficos comparativos por zona, por variable

• Alertas automáticas (ej: lluvias intensas, ráfagas, calor extremo)

🔹 2. Análisis estadístico:

• Interpolación espacial (IDW, Kriging) para generar mapas térmicos

• Cálculo de promedios, mínimas y máximas por zona

• Detección de anomalías o valores atípicos

🔹 3. Predicción y modelado:

• Pronósticos simples (basado en presión/temperatura)

• Integración con datos satelitales (opcional)

• Aprendizaje automático (si lo trabajan en años avanzados)

🛠️ Propuesta educativa articulada

Podrías distribuir el trabajo así:

Perfecto. Plantear una red de estaciones meteorológicas para el Conurbano Bonaerense amplía mucho más el desafío, y también lo vuelve más interesante desde el punto de vista técnico, logístico y académico. Vamos paso a paso:

📍 ¿Qué es el Conurbano Bonaerense?

El Conurbano (AMBA sin CABA) comprende los municipios del Gran Buenos Aires alrededor de la Capital Federal. Según delimitación tradicional:

• Abarca 24 partidos

• Con una superficie aproximada de 3.600 km²

• Y una población de más de 10 millones de habitantes

🧮 ¿Cuántas estaciones meteorológicas serían necesarias?

📌 Densidades de referencia:

⚠️ Estas cantidades no son absolutas, sino que pueden adaptarse en función del terreno, la población o los objetivos pedagógicos. Lo ideal es una cobertura más densa en zonas urbanas y más espaciada en áreas rurales o verdes.

🧭 Estrategia de despliegue sugerida (proyecto educativo)

Dividí el territorio en “Zonas Clave” o polígonos geográficos por partido o subregión:

• Norte (Vicente López, San Isidro, San Fernando, Tigre)

• Oeste (Morón, Hurlingham, Ituzaingó, Merlo, Moreno, etc.)

• Sur (Lanús, Lomas de Zamora, Quilmes, Avellaneda, Almirante Brown, etc.)

• AMBA exterior (La Matanza, Florencio Varela, Esteban Echeverría, etc.)

Asigná a cada grupo de estudiantes el diseño, implementación o simulación de 1 a 3 estaciones según la zona que estudien.

🧠 ¿Qué puede hacer la central?

Lo mismo que con CABA, pero con más complejidad en escalabilidad y tratamiento de datos:

🔸 Infraestructura

• MQTT broker con gestión de múltiples tópicos por zona

• Servidor de base de datos optimizado (ej: PostgreSQL + TimescaleDB)

• Backend que agrupe los datos por zona / partido

🔸 Tratamiento avanzado

• Modelos de interpolación con mallas espaciales

• Gráficos de evolución temporal y mapas de calor

• Clasificación de zonas según microclimas

• Uso de mapas satelitales (por ejemplo, con Leaflet o OpenStreetMap)

🎓 Propuesta de articulación por materias (más ambiciosa)

📌 ¿Qué podés plantear como objetivo educativo?

Que los estudiantes comprendan cómo diseñar, desplegar y operar una red de sensores en un territorio extenso, considerando variables físicas, tecnológicas y sociales. Que puedan aplicar conocimientos interdisciplinarios para generar información útil y visualizar fenómenos del entorno con criterios científicos.

¡Excelente! Vamos a desarrollar dos componentes fundamentales para tu proyecto educativo de una red de estaciones meteorológicas en el Conurbano Bonaerense:

1. Mapa dividido en zonas con estimación de estaciones necesarias.

2. Esquema de arquitectura para soportar una red de más de 100 nodos.

🗺️ 1. Mapa dividido en zonas con estimación de estaciones necesarias

El Conurbano Bonaerense abarca aproximadamente 3.830 km² y está compuesto por 24 partidos. Para una cobertura efectiva, podemos dividirlo en zonas y estimar la cantidad de estaciones necesarias por zona, considerando una densidad de una estación cada 10 km² para un equilibrio entre precisión y recursos disponibles.

📊 Estimación por zonas:

Nota: Estas estimaciones son aproximadas y pueden ajustarse según las necesidades específicas del proyecto.

🧰 2. Esquema de arquitectura para una red de más de 100 nodos

Para manejar una red de más de 100 estaciones meteorológicas, es fundamental diseñar una arquitectura escalable y eficiente. A continuación, se presenta un esquema general:

🏗️ Componentes principales:

1. Estaciones Meteorológicas (Nodos):

   • Hardware: ESP32 con sensores (temperatura, humedad, presión, etc.).

   • Conectividad: Wi-Fi o LoRa, según la disponibilidad de infraestructura.

   • Funcionalidad: Recolección de datos y envío periódico al broker MQTT.

2. Broker MQTT:

   • Software: Mosquitto o EMQX.

   • Ubicación: Servidor centralizado o en la nube.

   • Funcionalidad: Recepción y distribución de mensajes de los nodos.

3. Base de Datos:

   • Tipo: Time-series (InfluxDB) o relacional (PostgreSQL).

   • Funcionalidad: Almacenamiento estructurado de los datos recibidos.

4. Servidor de Aplicaciones:

   • Software: Node-RED, Grafana, o desarrollo personalizado.

   • Funcionalidad: Procesamiento de datos, generación de alertas y visualización.

5. Dashboard Web:

   • Tecnologías: HTML, CSS, JavaScript, frameworks como React o Vue.js.

   • Funcionalidad: Visualización en tiempo real de los datos meteorológicos.

🔄 Flujo de datos:

1. Recolección: Las estaciones recopilan datos meteorológicos.

2. Transmisión: Los datos se envían al broker MQTT.

3. Procesamiento: El servidor de aplicaciones procesa y almacena los datos en la base de datos.

4. Visualización: Los usuarios acceden al dashboard web para consultar la información.

🔐 Consideraciones de seguridad:

• Autenticación: Implementar autenticación en el broker MQTT.

• Encriptación: Utilizar TLS/SSL para la transmisión de datos.

• Monitoreo: Establecer sistemas de monitoreo para detectar fallos o anomalías.

🎓 Aplicación educativa

Este proyecto permite a los estudiantes:

• Integrar conocimientos de electrónica, programación, redes y análisis de datos.

• Desarrollar habilidades prácticas en el diseño y despliegue de sistemas IoT.

• Comprender la importancia de la recolección y análisis de datos ambientales.

¡Excelente planteo! Efectivamente, además de mapas de temperatura, humedad y presión, los datos de velocidad y dirección del viento permiten generar visualizaciones muy útiles e informativas. Aquí te detallo las principales formas de representar estos datos y cómo pueden integrarse a tu proyecto de red de estaciones meteorológicas:

✅ Formas de representar datos de viento:

1. 🌪️ Barbillas de viento (Wind barbs)

• Qué muestran: Dirección del viento (de dónde viene) y velocidad (mediante líneas o "barbas").

• Cómo se ven: Una flecha o línea apuntando en la dirección del viento con una serie de líneas pequeñas (barbas) indicando la velocidad.

• Usos educativos: Muy utilizados en meteorología profesional, ideales para aprender a interpretar datos como lo haría un observador climático.

2. 🧭 Roseta de vientos (Wind rose)

• Qué muestran: Frecuencia del viento proveniente de diferentes direcciones, agrupado por velocidad.

• Cómo se ve: Un gráfico circular tipo histograma en el que cada segmento representa una dirección (N, NE, E...), y su longitud/frecuencia la cantidad de veces que se registró viento de esa dirección.

• Ideal para: Estudiar patrones predominantes de viento en un lugar a lo largo del tiempo (por ejemplo, en un mes).

3. 📍 Vectores sobre mapa (Quiver plot)

• Qué muestran: Vectores dibujados sobre un mapa donde la dirección del vector indica la dirección del viento, y la longitud del vector su velocidad.

• Ideal para: Mostrar flujos de viento en mapas regionales, por ejemplo sobre CABA o el Conurbano.

4. 📈 Gráficos de líneas (serie temporal)

• Qué muestran: Evolución de la velocidad del viento a lo largo del tiempo.

• Complemento: Puede agregarse una segunda línea con la dirección del viento, codificada como ángulos (0° = Norte, 90° = Este...).

• Uso práctico: Permite estudiar ráfagas, comportamiento diario o estacional.

5. 🌀 Mapas animados de viento (streamlines)

• Qué muestran: Flujos animados sobre un mapa que simulan el comportamiento del viento en tiempo real.

• Requieren: Procesamiento más avanzado, pero se puede trabajar como desafío integrador usando librerías como Leaflet, Windy o D3.js.

• Valor educativo: Visualización intuitiva y atractiva, ideal para análisis climáticos avanzados.

📚 Aplicaciones educativas sugeridas:

• Comparar estaciones: Observar cómo difiere el comportamiento del viento en distintas zonas del conurbano.

• Análisis estacional: ¿Predomina el viento del este en invierno? ¿Cambia en verano?

• Modelos predictivos: Integrar viento + presión para crear modelos simples de pronóstico.

• Prevención: Evaluar cómo el viento podría impactar la propagación de contaminantes o incendios.

Excelente pregunta. Elegir la frecuencia de muestreo adecuada para cada sensor en una estación meteorológica es crucial para optimizar recursos (memoria, energía y red), sin perder precisión ni relevancia. A continuación te explico una frecuencia sugerida para cada variable, junto con justificación, recomendaciones para el buffer circular y uso de media móvil.

🕒 SUGERENCIAS DE FRECUENCIA DE MUESTREO POR VARIABLE

🌡️ Temperatura

• Frecuencia recomendada: cada 60 segundos (1 min).

• Justificación: Cambia lentamente. Muestrear más rápido no aporta valor significativo.

• Buffer circular: 60 muestras (una hora).

• Media móvil típica: 5-10 min (5-10 muestras).

💧 Humedad relativa

• Frecuencia recomendada: cada 60 segundos.

• Justificación: Comportamiento similar a la temperatura, con variaciones suaves.

• Buffer: 60 muestras.

• Media móvil: 5-10 muestras.

🌬️ Presión atmosférica

• Frecuencia recomendada: cada 5 minutos.

• Justificación: Cambia muy lentamente. Muestrear demasiado rápido no es útil.

• Buffer: 12 muestras (1 hora).

• Media móvil: 3-6 muestras.

🍃 Velocidad del viento

• Frecuencia recomendada: cada 5 segundos, con ventana de integración de 1 minuto.

• Justificación: Muy variable. Conviene muestrear rápido y calcular media, máximas y ráfagas por minuto.

• Buffer: 12 muestras/min → 720 para 1 hora.

• Media móvil: media y máxima cada 1 min (renovable).

🧭 Dirección del viento

• Frecuencia recomendada: cada 5 segundos (igual que la velocidad).

• Justificación: Puede cambiar rápidamente. Se calcula dirección media ponderada por velocidad.

• Buffer: igual al de velocidad.

• Media móvil: ponderada en 1-3 minutos.

☔ Pluviómetro (precipitaciones)

• Frecuencia recomendada: cada vez que ocurre un evento (tip-bucket o pulso), se cuenta.

• Justificación: Evento esporádico. Se registra el número de pulsos en intervalos de 1 min.

• Buffer: 60 muestras (última hora).

• Media móvil: acumulado en períodos deseados (ej. 10 min, 1 hora).

📦 ESTRUCTURA DE BUFFER CIRCULAR

Podés estructurar buffers circulares por variable, con tamaño definido por:

buffer_size = ventana_de_tiempo / frecuencia_de_muestreo

Ejemplo:

• Temperatura: 60 min / 1 min = 60 muestras.

• Viento: 60 min / 5 seg = 720 muestras.

🧠 MEDIA MÓVIL

• Simple: Promedio de últimas N muestras.

• Ponderada: Para dirección del viento (según velocidad).

• Exponencial: Si se desea priorizar valores más recientes.

💡 CONSEJO FINAL

En estaciones con ESP32, se puede:

• Usar Timer o Ticker para tareas periódicas.

• Guardar datos procesados (ej. promedio de viento por minuto) y evitar enviar todos los valores brutos.

• Usar técnicas de downsampling si se almacenan datos históricos.

Perfecto. A continuación te presento dos versiones de un esquema funcional para un ESP32 que muestrea sensores meteorológicos, guarda los datos en buffers circulares y calcula la media móvil. Podés elegir entre:

• ✅ Versión en C++ para Arduino (ESP32 con Arduino IDE)

• ✅ Versión en MicroPython (ESP32 con Thonny, uPyCraft, etc.)

🧠 ¿Qué incluye este esquema?

• Medición simulada de sensores: temperatura, humedad y velocidad del viento.

• Almacenamiento en buffers circulares.

• Cálculo de media móvil (promedio simple).

• Muestra cómo escalarlo a múltiples sensores.

🔧 OPCIÓN 1: C++ para Arduino (ESP32)

// Tamaño de cada buffer circular
const int BUFFER_SIZE = 60;  // por ejemplo: 60 muestras = 1 por minuto durante una hora

// Buffers para cada sensor
float tempBuffer[BUFFER_SIZE];
float humBuffer[BUFFER_SIZE];
float windSpeedBuffer[BUFFER_SIZE];

int bufferIndex = 0;  // índice común (circular)

// Simulación de lectura de sensores (reemplazar con funciones reales)
float leerTemperatura()   { return 20.0 + random(-100, 100) / 100.0; }
float leerHumedad()       { return 60.0 + random(-500, 500) / 100.0; }
float leerVelocidadViento(){ return 5.0 + random(0, 300) / 100.0; }

float calcularMedia(float buffer[], int tamaño) {
  float suma = 0;
  for (int i = 0; i < tamaño; i++) {
    suma += buffer[i];
  }
  return suma / tamaño;
}

void setup() {
  Serial.begin(115200);
}

void loop() {
  // Leer sensores y guardar en buffers
  tempBuffer[bufferIndex] = leerTemperatura();
  humBuffer[bufferIndex] = leerHumedad();
  windSpeedBuffer[bufferIndex] = leerVelocidadViento();

  // Calcular medias móviles (ej: última hora)
  float mediaTemp = calcularMedia(tempBuffer, BUFFER_SIZE);
  float mediaHum = calcularMedia(humBuffer, BUFFER_SIZE);
  float mediaViento = calcularMedia(windSpeedBuffer, BUFFER_SIZE);

  // Mostrar resultados
  Serial.print("Media Temp: "); Serial.print(mediaTemp); Serial.print(" °C\t");
  Serial.print("Media Hum: "); Serial.print(mediaHum); Serial.print(" %\t");
  Serial.print("Media Viento: "); Serial.print(mediaViento); Serial.println(" m/s");

  // Avanzar índice circular
  bufferIndex = (bufferIndex + 1) % BUFFER_SIZE;

  delay(60000);  // 1 muestra por minuto
}

🐍 OPCIÓN 2: MicroPython (ESP32)

import time
import random

BUFFER_SIZE = 60

# Buffers
temp_buffer = [0.0] * BUFFER_SIZE
hum_buffer = [0.0] * BUFFER_SIZE
wind_buffer = [0.0] * BUFFER_SIZE

index = 0

# Simular lectura de sensores
def leer_temperatura():
    return 20 + random.uniform(-1, 1)

def leer_humedad():
    return 60 + random.uniform(-5, 5)

def leer_velocidad_viento():
    return 5 + random.uniform(0, 3)

def media(buffer):
    return sum(buffer) / len(buffer)

while True:
    temp_buffer[index] = leer_temperatura()
    hum_buffer[index] = leer_humedad()
    wind_buffer[index] = leer_velocidad_viento()

    media_temp = media(temp_buffer)
    media_hum = media(hum_buffer)
    media_viento = media(wind_buffer)

    print("Media Temp:", round(media_temp, 2), "°C",
          "Media Hum:", round(media_hum, 2), "%",
          "Media Viento:", round(media_viento, 2), "m/s")

    index = (index + 1) % BUFFER_SIZE

    time.sleep(60)  # 1 muestra por minuto

Perfecto, estás describiendo una arquitectura IoT robusta y escalable, ideal para una red de estaciones meteorológicas. A continuación te detallo un esquema claro de cómo llevar adelante esto y qué herramientas podés utilizar.

🧭 Arquitectura propuesta: Red de estaciones meteorológicas inteligentes

🔧 Componentes principales:

🟦 Nodos remotos (Estaciones)

• Microcontrolador: ESP32

• Sensores: temperatura, humedad, presión, viento, lluvia, etc.

• Comunicación: WiFi (o LoRa en zonas rurales)

• Software:

  • Lectura periódica de sensores

  • Cálculo de media móvil

  • Publicación MQTT cada X minutos

Tópicos MQTT (por estación)
  /estaciones/ID123/temperatura
  /estaciones/ID123/humedad
  /estaciones/ID123/presion
  /estaciones/ID123/viento/velocidad
  /estaciones/ID123/viento/direccion
  /estaciones/ID123/lluvia

🟨 Broker MQTT (Mosquitto o EMQX)

• Recibe datos desde todos los nodos

• Internamente no almacena los datos, solo los enruta

• Puede estar en una Raspberry Pi, PC servidor local, o en la nube (ej: AWS EC2, VPS)

🟩 API Backend (middleware)

• Lenguaje: Python (FastAPI), Node.js, Django, etc.

• Función:

  • Suscribirse a los tópicos MQTT

  • Decodificar el payload JSON

  • Insertar los datos en una base de datos

  • Servir endpoints RESTful o WebSocket

🟥 Base de datos

• Opciones:

  • InfluxDB (ideal para series temporales)

  • PostgreSQL + TimescaleDB

  • MongoDB (si necesitas más flexibilidad)

• Contendrá todos los datos históricos

🟦 Dashboard Web (Frontend)

• Opciones:

  • Grafana (con InfluxDB/PostgreSQL)

  • ReactJS o VueJS + Leaflet (para mapas interactivos)

  • ThingsBoard (todo en uno, open source)

• Visualizaciones:

  • Gráficos de línea, barras, circulares

  • Mapas de calor (Leaflet, Mapbox, etc.)

  • Estado en tiempo real y promedios históricos

🌐 Esquema gráfico de la arquitectura

+-------------+       +-------------+       +------------+       +-------------+       +---------------+
|  Estaciones | ----> |   Broker    | --->  |    API     | --->  |   Base de   | <---  |  Dashboard    |
|  ESP32+sens | MQTT  |   Mosquitto | MQTT  |  backend    |       |   Datos     |       |  Web/RealTime  |
+-------------+       +-------------+       +------------+       +-------------+       +---------------+
                           ^                                                     
                           |                                            
                     MQTT Explorer (debug, monitoreo)                    

🧠 Ideas para dashboards

• Temperatura y humedad: mapas de calor por zona.

• Presión atmosférica: gráficas de tendencia para predicción de clima.

• Viento: vectores animados en mapas (dirección + velocidad).

• Lluvia: mapa de acumulación o intensidad.

• Estado de red: estaciones activas, sin conexión, calidad de señal, etc.

🚀 Bonus: tecnologías recomendadas

¡Excelente! Vamos a trabajar en el diseño de la estructura de tópicos MQTT y a estimar el ancho de banda necesario para una red de estaciones meteorológicas inteligentes.

🧱 1. Estructura de Tópicos MQTT

Una buena práctica es usar una jerarquía de tópicos clara y escalable. Supongamos una red con varias estaciones, cada una con un ID o nombre único. Un ejemplo de jerarquía podría ser:

meteo/{estacion_id}/{variable}

Donde:

• meteo: tópico raíz del sistema

• {estacion_id}: identificador único de cada estación (ej: estacion001, caba_norte)

• {variable}: puede ser temperatura, humedad, presion, viento/velocidad, viento/direccion, lluvia

Ejemplos de tópicos:

meteo/caba_norte/temperatura
meteo/caba_norte/humedad
meteo/caba_norte/presion
meteo/caba_norte/viento/velocidad
meteo/caba_norte/viento/direccion
meteo/caba_norte/lluvia

📡 2. Formato del mensaje

Los mensajes pueden ser simples o complejos:

• Simple (solo valor):

"24.5"

• Con timestamp (más útil):

{
  "valor": 24.5,
  "ts": "2025-05-19T10:03:00Z"
}

• Extendido (con calidad, unidad, etc.):

{
  "valor": 24.5,
  "unidad": "°C",
  "ts": "2025-05-19T10:03:00Z",
  "q": 1
}

Usar JSON implica más bytes por mensaje, pero aporta mucha trazabilidad.

📶 3. Análisis del Ancho de Banda

Supongamos:

• Cada estación mide 6 variables

• Frecuencia de muestreo: 1 muestra por minuto por variable

• Cada mensaje MQTT (con encabezado y JSON incluido) pesa ~150 bytes

• 100 estaciones

Cálculo:

Mensajes por minuto = 100 estaciones × 6 variables = 600 msg/min
Bytes por minuto = 600 msg × 150 bytes = 90,000 bytes/min ≈ 88 KB/min

Ancho de banda promedio:

90,000 bytes/min ÷ 60 = 1,500 bytes/seg ≈ 12 kbps

🔍 Resultado: La red completa (100 estaciones) consumiría ~12 kilobits por segundo en promedio.

Si se transmitiera cada 10 segundos en lugar de cada 60, se multiplicaría ×6 = ~72 kbps

🧭 4. Posible estructura para suscripción en el backend

En el backend, se pueden usar wildcards para suscribirse a todos o parte de los tópicos:

• meteo/+/temperatura → todas las temperaturas de todas las estaciones

• meteo/caba_norte/# → todos los datos de una estación

• meteo/# → todos los datos del sistema

✅ Recomendaciones

• Mantener los tópicos cortos pero descriptivos

• Usar JSON si se quiere registrar timestamps, unidades, etc.

• Considerar compresión o binarios solo si se escala a miles de estaciones

• El backend puede usar librerías como paho-mqtt, mosquitto_sub, o brokers intermedios (ej. EMQX, HiveMQ) con reglas para reescritura o almacenamiento.

Perfecto. A continuación, te presento dos partes:

1. 📊 Tabla estimativa de ancho de banda según cantidad de estaciones y frecuencia de muestreo.

2. 🔧 Ejemplo de código (C++ para Arduino/ESP32) que publica valores en MQTT con la estructura sugerida.

📊 1. Tabla de Análisis de Ancho de Banda MQTT

Supuestos:

• Cada estación mide 6 variables: temperatura, humedad, presion, viento/velocidad, viento/direccion, lluvia.

• Cada mensaje pesa ~150 bytes (incluyendo encabezado y JSON).

• Solo transmisión unidireccional (estación → broker).

💡 Nota: En redes grandes o en entornos de baja conectividad, se puede transmitir datos comprimidos, usar Protobuf, o reducir frecuencia.

🔧 2. Código para ESP32 (C++ con Arduino)

Este ejemplo:

• Se conecta por WiFi

• Usa la librería PubSubClient

• Publica cada minuto en formato JSON

• Simula valores de sensores

#include <WiFi.h>
#include <PubSubClient.h>

// WiFi
const char* ssid = "TU_SSID";
const char* password = "TU_PASSWORD";

// MQTT
const char* mqtt_server = "192.168.0.100";
const int mqtt_port = 1883;
const char* station_id = "caba_norte";

WiFiClient espClient;
PubSubClient client(espClient);

unsigned long lastMsg = 0;
const long interval = 60000; // 60 segundos

void setup_wifi() {
  delay(10);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) delay(500);
}

void reconnect() {
  while (!client.connected()) {
    if (client.connect("ESP32Client")) break;
    delay(1000);
  }
}

void publishData(const char* variable, float value, const char* unit) {
  char topic[64];
  snprintf(topic, sizeof(topic), "meteo/%s/%s", station_id, variable);

  char payload[128];
  snprintf(payload, sizeof(payload),
    "{\"valor\":%.2f,\"unidad\":\"%s\",\"ts\":\"%lu\"}",
    value, unit, millis() // en producción, usar RTC
  );

  client.publish(topic, payload);
}

void setup() {
  Serial.begin(115200);
  setup_wifi();
  client.setServer(mqtt_server, mqtt_port);
}

void loop() {
  if (!client.connected()) reconnect();
  client.loop();

  unsigned long now = millis();
  if (now - lastMsg > interval) {
    lastMsg = now;

    publishData("temperatura", 23.5 + random(-10, 10) / 10.0, "C");
    publishData("humedad", 55 + random(-5, 5), "%");
    publishData("presion", 1013 + random(-3, 3), "hPa");
    publishData("viento/velocidad", random(0, 40), "km/h");
    publishData("viento/direccion", random(0, 360), "grados");
    publishData("lluvia", random(0, 10), "mm");
  }
}

✅ ¿Qué podés hacer con este código?

• Sustituir los random() por lecturas reales: DHT22, BMP280, anemómetro, etc.

• Agregar timestamp UTC con un RTC o usando NTP.

• Extender el payload con quality, sensor_id, battery_level, etc.

• Usar TLS si es necesario para seguridad del MQTT.

🌐 ThingsBoard

¿Qué es?

ThingsBoard es una plataforma IoT de código abierto (también disponible como servicio en la nube) que permite:

• Recibir datos de dispositivos IoT mediante protocolos como MQTT, HTTP o CoAP.

• Visualizar datos en dashboards interactivos.

• Configurar reglas, alertas y procesamiento de datos.

• Gestionar dispositivos de forma centralizada.

¿Para qué lo podrías usar?

• Para monitorear temperatura, humedad, presión, etc., desde sensores conectados a ESP32 o notebooks Python.

• Para armar dashboards personalizados (gráficas, medidores, etc.).

• Para practicar protocolos de comunicación y analizar redes IoT.

• Para crear alertas del tipo: “Si la temperatura > 30°C, encender una alarma” (lógica de reglas).

• Para mostrar a tus alumnos cómo se hace la integración real entre hardware y servicios en la nube.

🌐 TheThings.io

¿Qué es?

Es una plataforma comercial de IoT en la nube, pensada para empresas que desarrollan productos conectados. Tiene funciones similares a ThingsBoard, pero:

• Es más orientada a productos comerciales.

• Ofrece una interfaz sencilla para dispositivos y visualización.

• Permite conectar por MQTT, HTTPS, CoAP.

¿Para qué lo podrías usar?

• Para mostrar alternativas comerciales a ThingsBoard.

• Para integrar tus ESP32 o simulaciones Python sin necesidad de desplegar servidores propios.

• Para enseñar conceptos como API REST, seguridad, integración con apps móviles, etc.

🔐 Tiene un modelo gratuito limitado (registro requerido).

🌐 ThingSpeak

¿Qué es?

ThingSpeak es una plataforma gratuita para la comunidad, mantenida por MathWorks (creadores de MATLAB), pensada para el uso académico, hobby y prototipado.

¿Qué permite?

• Recibir datos mediante HTTP GET/POST.

• Visualizar datos en gráficas automáticamente.

• Analizar datos usando MATLAB (opcional).

• Crear alertas básicas con IFTTT u otros servicios.

¿Para qué lo podrías usar?

• Para proyectos sencillos o introductorios en clase.

• Para que tus alumnos envíen datos de sensores sin complicarse con MQTT o certificados.

• Para analizar datos históricos fácilmente.

• Para conectar con otras plataformas como Google Sheets, Telegram, etc., mediante Webhooks.

🔍 Comparación rápida

Broker: mqtt.thingsboard.cloud
Puerto: 1883 (sin TLS), 8883 (con TLS)
Username: Tu ACCESS TOKEN

Broker: mqtt.thethings.io
Puerto: 1883
Username: Tu device token

🛠️ Paso a paso: Cómo crear dashboards con widgets en ThingsBoard Cloud

✅ 1. Registrarse y acceder

• Ir a: https://thingsboard.cloud

• Crear una cuenta gratuita o iniciar sesión.

✅ 2. Agregar un dispositivo

1. En el menú izquierdo, ir a Devices.

2. Clic en el botón "+" y seleccionar Add new device.

3. Ponerle un nombre (ej. ESP32 Sensor Node).

4. Guardar.

5. Ir a la pestaña "Credentials" para copiar el Access Token, lo necesitarás para el ESP32 o cliente MQTT.

✅ 3. Publicar datos desde un dispositivo

• Usar el ESP32 o script en Python para enviar datos al broker MQTT:

  mqtt.thingsboard.cloud
  puerto: 1883
  usuario: ACCESS TOKEN
  topic: v1/devices/me/telemetry
  mensaje JSON: {"temperature": 22.5, "humidity": 60}
  

✅ 4. Crear un dashboard

1. En el menú izquierdo, ir a Dashboards.

2. Clic en el botón "+" → Create new dashboard.

3. Darle un nombre (ej. Monitor Ambiental).

4. Clic en el lápiz (✏️) para editarlo.

✅ 5. Agregar un widget

1. Dentro del editor de dashboard, clic en "+" (Add new widget).

2. Aparecerá la "Widget Library":

   • Elegí una categoría, por ejemplo: Charts → Timeseries line chart, o Digital gauges, Cards, etc.

3. Seleccioná el widget que querés usar → clic en "Add to dashboard".

✅ 6. Vincular el widget a un dispositivo

1. Al insertar el widget, se abrirá el diálogo de configuración.

2. En Entity Alias, clic en "+":

   • Elegí un nombre para el alias (ej. Sensor ESP32)

   • Tipo: Single entity

   • Tipo de entidad: Device

   • Seleccionar el dispositivo creado anteriormente.

3. Luego, en el widget, seleccioná los datos a visualizar:

   • Key: temperature, humidity, etc.

✅ 7. Ajustes opcionales

• Personalizar:

  • Colores de fondo, escalas del eje, nombre del widget, alertas visuales, etc.

• Agregar varios widgets para distintas variables (temperatura, humedad, presión).

✅ 8. Guardar y visualizar

• Clic en Save (ícono de disquete arriba a la derecha).

• Tu dashboard ya está listo y se actualizará automáticamente cuando lleguen nuevos datos.

• Crear alertas visuales o notificaciones.

• Compartir dashboards públicamente o por usuario.

• Combinar múltiples sensores en un mismo dashboard.