Animated navigation - turn off
Animated navigation - turn off

  • Clase 11 - 21/10/2025

    • Folder icon
      WireShark comunicaciones MQTT
    • Assignment icon
      Conclusiones analisis con WireShark
      Opened: Tuesday, 21 October 2025, 12:00 AM

    • Basándonos en tu script y tus requerimientos, necesitas hacer las siguientes modificaciones para usar QoS 2, no desconectarte inmediatamente y esperar la confirmación del broker de que el mensaje ha sido recibido por el suscriptor (que en el contexto de MQTT QoS 2 se traduce en la recepción del mensaje PUBCOMP por parte del broker).

      En QoS 2, el flujo de mensajes asegura que el mensaje se reciba exactamente una vez por el suscriptor. El publicador espera una secuencia de acuses de recibo del broker para considerarlo completado.

      Aquí está el script modificado:

      Python
      import paho.mqtt.client as mqtt
import time

# --- Configuración del Broker ---
BROKER_ADDRESS = "test.mosquitto.org"
BROKER_PORT = 1883  # Puerto estándar para MQTT sin cifrado (Non-TLS)
TOPIC = "/ProtcolosIoT/QoS2_Test" # Cambiado el tópico para ser más específico de la prueba
QOS = 2 # Calidad de Servicio (Quality of Service): ¡Cambiado a 2!

# --- Mensaje a Publicar ---
PAYLOAD = "Publicando mensaje de prueba con QoS 2 y esperando confirmación de entrega (PUBCOMP)."

# Bandera para saber si la publicación con QoS 2 ha sido completada (PUBCOMP recibido)
pub_complete = False 

def on_connect(client, userdata, flags, rc):
    """Función que se llama cuando el cliente se conecta al broker."""
    global pub_complete
    
    if rc == 0:
        print("Conexión exitosa al broker.")
        # La publicación se realiza una vez que la conexión es exitosa
        print(f"Intentando publicar: Tópico: {TOPIC}, QoS: {QOS}")
        
        # Publicar el mensaje
        # El resultado ahora incluye el mid (message ID) que es clave para QoS 1 y 2
        result, mid = client.publish(TOPIC, PAYLOAD, qos=QOS, retain=False)
        
        if result == mqtt.MQTT_ERR_SUCCESS:
            print(f"[PUBLICADO INICIADO] ID de Mensaje (mid): {mid}")
            # NO nos desconectamos aquí. Esperaremos 'on_publish'.
        else:
            print(f"Error al intentar publicar. Código: {result}")
            client.disconnect() # Desconectarse en caso de error inmediato
    else:
        print(f"Error de conexión. Código: {rc}")
        
# --- Nueva función para manejar la publicación ---
def on_publish(client, userdata, mid):
    """
    Función que se llama cuando la publicación es completada por el broker.
    
    En QoS 2, esta función se llama cuando el publicador recibe el
    mensaje 'PUBCOMP' del broker, indicando que el mensaje fue
    entregado *exactamente una vez* a los suscriptores.
    """
    global pub_complete
    print(f"\n--- Publicación QoS 2 Completada ---")
    print(f"Confirmación (PUBCOMP) recibida para ID de Mensaje: {mid}")
    print(f"[MENSAJE ENTREGADO]: {PAYLOAD}")
    print("El broker ha confirmado la entrega EXACTA a los suscriptores (QoS 2).")
    
    # Establecer la bandera para salir del bucle
    pub_complete = True
    
    # Se podría desconectar aquí si solo se quiere publicar una vez
    # client.disconnect() 


# Crear una instancia del cliente
client = mqtt.Client(client_id="PythonPublisherClient_QoS2")

# Asignar las funciones de conexión y publicación
client.on_connect = on_connect
client.on_publish = on_publish # ¡Función clave para la confirmación de entrega!

# Conectar al broker (esto es asíncrono)
try:
    print(f"Conectando a {BROKER_ADDRESS}:{BROKER_PORT}...")
    client.connect(BROKER_ADDRESS, BROKER_PORT, 60)
    
    # Iniciar el bucle de red en un hilo separado
    client.loop_start() 
    
    print("\nCliente en bucle. Esperando la confirmación de la entrega (PUBCOMP)...")
    
    # Bloqueamos el hilo principal hasta que se reciba el PUBCOMP
    timeout = 15 # Tiempo máximo de espera en segundos
    start_time = time.time()
    
    while not pub_complete and (time.time() - start_time < timeout):
        time.sleep(0.1) # Esperar un poco
        
    print("\n-------------------------------------")
    if pub_complete:
        print("¡Proceso de publicación QoS 2 completado con éxito!")
    else:
        print("¡Tiempo de espera agotado! No se recibió la confirmación completa (PUBCOMP).")

    # Detener el bucle de red y desconectar
    client.loop_stop()
    client.disconnect()
    print("Cliente desconectado.")

except Exception as e:
    print(f"No se pudo conectar al broker o hubo un error durante la ejecución: {e}")

      Resumen de Modificaciones Clave

      1. Cambio de QoS

      • Se modificó la variable QOS de 0 a 2:

        Python
        QOS = 2

      2. Eliminación de Desconexión Inmediata

      • Se eliminó la llamada a client.disconnect() dentro de la función on_connect, permitiendo que el cliente permanezca conectado.

      3. Implementación del Manejo de Publicación (on_publish)

      • Se definió la función on_publish(client, userdata, mid) y se asignó al cliente:

        Python
        client.on_publish = on_publish

        • En QoS 2, esta función se dispara solo después de que el publicador recibe el mensaje PUBCOMP del broker. PUBCOMP es la señal final que indica que el broker ha completado el protocolo de entrega QoS 2 y confirma que el suscriptor ha recibido el mensaje exactamente una vez.

      • Se utiliza una bandera global (pub_complete) dentro de on_publish para señalizar que la entrega se ha completado.

      4. Bucle de Espera (Sincronización)

      • Se reemplazó client.loop_forever() por client.loop_start() y un bucle de espera explícito:

        Python
        client.loop_start() 
# ...
while not pub_complete and (time.time() - start_time < timeout):
    time.sleep(0.1) 
# ...
client.loop_stop()
client.disconnect()

        • client.loop_start() inicia el bucle de red en un hilo separado, lo que permite que el hilo principal se bloquee y espere a que la bandera pub_complete sea establecida a True por la función on_publish (que se ejecuta en el hilo de red).

        • Esto simula tu requerimiento de "esperar hasta que el broker le envíe el comando que indique que el suscriptor ya lo ha recibido" (el PUBCOMP).


    • Un 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í:

      Materia Entregable/Responsabilidad
      Protocolos de IoT Comunicaciones, MQTT, envío de datos
      Diseño de Sistemas Electrónicos Hardware robusto, PCBs para estaciones
      Programación o Bases de Datos Backend de recolección y almacenamiento (SQL)
      Diseño Web o Visualización Frontend, gráficos, dashboards
      Estadística / Matemática Tratamiento de datos, interpolación, gráficos
      Geografía o Ciencias Análisis de fenómenos locales, mapas de calor

      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:

      Objetivo Densidad sugerida Estaciones aprox.
      Alta resolución urbana 1 cada 5 km² ~720 estaciones
      Resolución media educativa 1 cada 10 km² ~360 estaciones
      Demostrativo / piloto 1 cada 25 km² ~144 estaciones

      ⚠️ 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)

      Materia Rol ampliado en el proyecto
      Protocolos de IoT Diseño de comunicación escalable, jerarquía entre nodos (clústeres)
      Diseño de Sistemas Electrónicos Robustez, tolerancia a fallos, alimentación solar
      Programación y Datos Backend para carga masiva, normalización, georreferenciación
      Geografía / Ciencias Ambientales Definición de zonas climáticas locales
      Matemática / IA Modelos de predicción meteorológica, clustering, interpolación
      Proyecto Final / Taller Integración completa del sistema con casos de uso reales

      📌 ¿Qué se puede 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.

      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:

      Zona Partidos incluidos Superficie aprox. (km²) Estaciones necesarias
      Norte Vicente López, San Isidro, San Fernando, Tigre 500 50
      Noroeste San Martín, Tres de Febrero, Hurlingham, Ituzaingó, Morón, Merlo, Moreno 800 80
      Oeste La Matanza, Marcos Paz, General Las Heras 900 90
      Suroeste Ezeiza, Esteban Echeverría, Presidente Perón, San Vicente, Cañuelas 700 70
      Sur Lomas de Zamora, Lanús, Avellaneda, Quilmes, Berazategui, Florencio Varela, Almirante Brown 930 93
      Total estimado 3.830 383

      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.

      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.

      Los datos de temperatura, humedad, presión y precipitaciones no solo se pueden visualizar, sino que también permiten interpretaciones útiles para actividades educativas, pronóstico simple, análisis ambiental, y más. A continuación te presento ideas organizadas por variable, con sugerencias de gráficos, interpretaciones posibles y propuestas de actividades.

      🌡️ TEMPERATURA

      ✅ Gráficos útiles:

      • Serie temporal: Temperatura vs. tiempo (línea o área).

      • Mapa de calor (Heatmap): Temperatura por zona (si hay varias estaciones).

      • Gráfico de mínimas y máximas diarias: Puede incluir bandas de temperatura confort.

      📊 Interpretación:

      • Identificación de patrones diarios (mínima a la madrugada, máxima a la siesta).

      • Comparación entre zonas urbanas y rurales (islas de calor).

      • Evaluación de ondas de calor/frío.

      📘 Actividad sugerida:

      • “Detectar la hora más fría y más cálida del día y estimar el ciclo térmico diario.”

      💧 HUMEDAD RELATIVA

      ✅ Gráficos útiles:

      • Serie temporal.

      • Gráfico combinado Temp vs. Humedad.

      • Gráfico de dispersión para ver correlación inversa (a mayor temperatura, menor humedad relativa).

      📊 Interpretación:

      • Detección de momentos de condensación posible (alto %HR, temperatura baja).

      • Análisis de confort térmico (índice de calor combinado).

      📘 Actividad sugerida:

      • “Analizar cuándo hay riesgo de rocío o condiciones para niebla.”

      🌬️ PRESIÓN ATMOSFÉRICA

      ✅ Gráficos útiles:

      • Serie temporal suave (curva continua).

      • Gráfico combinado presión + tiempo + eventos (como lluvias o cambios de viento).

      📊 Interpretación:

      • La presión baja y en descenso suele asociarse a mal tiempo o lluvias.

      • La presión alta y estable sugiere buen clima.

      📘 Actividad sugerida:

      • “Observar si el descenso de presión precede a eventos de lluvia o tormenta en tu zona.”

      ☔ PLUVIÓMETRO (PRECIPITACIONES)

      ✅ Gráficos útiles:

      • Histograma de precipitaciones diarias (barras).

      • Acumulado mensual o semanal.

      • Mapa de precipitaciones (si hay varias estaciones).

      📊 Interpretación:

      • Identificación de lluvias intensas, prolongadas o eventos extremos.

      • Comparación de zonas geográficas.

      • Cálculo de totales acumulados.

      📘 Actividad sugerida:

      • “Construir el gráfico de lluvias del mes y calcular la media semanal o detectar la lluvia más intensa.”

      🧠 Análisis integrador y actividades avanzadas

      🗺️ Mapa climático compuesto

      • Superponer variables (por ejemplo: temperatura + humedad + presión) para buscar patrones de clima regional.

      📈 Modelos simples de pronóstico

      • Usar una combinación de presión en descenso + humedad alta + temperatura estancada para predecir posibilidad de lluvia.

      📚 Propuesta educativa interdisciplinaria

      • Aplicar estadística para determinar:

        • Medias, máximos y mínimos.

        • Desvío estándar entre estaciones.

        • Detección de anomalías.

      • Relacionar con geografía y ciencia ambiental: impactos locales del cambio climático o urbanización.