Tema 16 · Bloque E · Sistemas informáticos. Programación

Tema 16. Internet de las cosas y redes de dispositivos

Cómo se conectan entre sí los objetos que fabricamos y qué protocolos hacen posible que se entiendan.

Este tema cierra el Bloque E y es el puente al Bloque F. El KR-1 ya sabe medir, decidir, actuar y recordar; lo que le falta es hablar. Y hablar, en un sistema técnico, no es enviar un mensaje bonito: es elegir una arquitectura, un protocolo y un formato de datos, y hacerlo teniendo en cuenta la seguridad, la privacidad y el consumo. Es, además, el contenido que el currículo enumera como «tecnologías emergentes».

Antes de empezar: ¿por qué una bombilla inteligente necesita internet para encenderse desde el sofá, si el móvil está a tres metros? La respuesta explica casi todo este tema: porque los dos hablan con un servidor intermedio, no entre sí. Y eso tiene ventajas —funciona también desde otra ciudad— e inconvenientes —si el servidor cierra, la bombilla se vuelve tonta—.
Al terminar serás capaz de…
  • explicar qué es el internet de las cosas y qué lo distingue de conectar un ordenador a la red;
  • describir las cuatro capas de una solución IoT y situar cada componente del KR-1;
  • explicar qué necesita una placa para ser un nodo de red: identificación, alimentación y conectividad;
  • conectar un ESP32 a una red Wi-Fi desde MicroPython y comprobar la conexión;
  • distinguir MQTT de HTTP y decidir cuál conviene en cada caso;
  • explicar el modelo de publicación y suscripción, y el papel de los temas;
  • publicar una lectura en formato JSON y suscribirse a un tema de órdenes;
  • situar Bluetooth, Zigbee y LoRa frente al Wi-Fi en alcance, consumo y velocidad;
  • valorar los riesgos de seguridad y privacidad de un dispositivo conectado y estimar su consumo.

1. Qué es el internet de las cosas

El internet de las cosas es la extensión de la red a objetos que no son ordenadores: sensores, electrodomésticos, vehículos, máquinas industriales, instalaciones. Lo que cambia no es la tecnología de red, que es la misma: lo que cambia son las restricciones.

Un ordenador y un nodo IoT en la misma red
AspectoOrdenadorNodo IoT
EnergíaEnchufado; el consumo casi no importa.Batería o panel: cada miliamperio cuenta.
Potencia de cálculoGigabytes de memoria.Cientos de kilobytes.
Datos que envíaMegabytes o gigabytes.Unas decenas de bytes cada varios minutos.
Quién lo manejaUna persona delante.Nadie: funciona solo durante meses.
Qué pasa si falla la redEl usuario lo ve y reacciona.Tiene que reaccionar el propio dispositivo.
MantenimientoActualizaciones frecuentes.Difícil o imposible: está en un tejado o enterrado.
La restricción que ordena todas las decisionesNadie va a estar delante. De ahí sale todo lo demás: el programa tiene que sobrevivir a un corte de red sin bloquearse, volver a conectarse solo, dejar el sistema en estado seguro si algo falla y consumir lo suficientemente poco como para durar el verano. Un programa de escritorio puede darse el lujo de esperar a que alguien pulse «reintentar»; un nodo IoT, no. Esta es la idea que el Bloque F desarrollará como diseño de un sistema automático.
La obsolescencia que llega por la red. Un objeto conectado depende de un servidor que alguien tiene que mantener. Cuando la empresa cierra el servicio, el objeto sigue perfectamente sano y deja de funcionar: es obsolescencia funcional del Tema 2, provocada no por una avería sino por una decisión ajena. Es una razón técnica de peso para que el KR-1 siga funcionando sin red —regando por su cuenta— y use internet solo para informar. Un sistema que no puede trabajar sin red es un sistema más frágil, no más moderno.

2. Arquitectura de una solución IoT

El nodo formado por el ESP32, la sonda y la electroválvula se conecta por Wi-Fi al punto de acceso del centro, que a través de internet alcanza un broker MQTT; del broker parten los datos al panel web y al móvil. El nodo publica en el tema kr1 barra humedad y se suscribe al tema kr1 barra orden, por el que le llegan las órdenes de vuelta.
Las cuatro capas del sistema. La clave está en el centro: el nodo y el panel no se conocen, solo conocen el nombre de los temas.
Las cuatro capas y el KR-1
CapaQué haceEn el KR-1
DispositivoMide, decide y actúa. Es el nodo.ESP32 con la sonda del Tema 11 y la electroválvula del Tema 8.
RedTransporta los mensajes.Wi-Fi del centro y, a partir de ahí, internet.
PlataformaRecibe, reparte y guarda los datos.Un broker MQTT y una base de datos sencilla.
AplicaciónPresenta la información y permite mandar órdenes.El panel web del Tema 18 y el móvil.
Y a veces hay una capa más: la pasarela. Cuando los nodos usan una tecnología que no llega a internet por sí sola —Zigbee, por ejemplo—, hace falta un dispositivo intermedio que traduzca: la pasarela. El KR-1 no la necesita porque el ESP32 lleva Wi-Fi integrado y habla directamente con el router. Esa es, precisamente, la razón por la que se eligió esta placa y no un micro:bit.

3. El ESP32 como nodo de red

Para que una placa sea un nodo de red necesita tres cosas, y conviene enumerarlas porque las tres dan problemas.

Identificación

Una dirección MAC única de fábrica, una dirección IP que le asigna la red y un nombre de cliente propio para el protocolo. Dos nodos con el mismo nombre se expulsan mutuamente.

Alimentación

El Wi-Fi es lo que más consume del nodo: de 28 mA en reposo pasa a unos 180 mA transmitiendo. Eso decide la batería y el panel del Tema 23.

Conectividad

Credenciales de la red, cobertura suficiente en el huerto y una política de qué hacer cuando la red no está.

Direcciones: MAC e IP no son lo mismoLa MAC es el número de serie del interfaz de red: viene de fábrica, no cambia y solo sirve dentro de la red local. La IP es la dirección en la red: la asigna el router, puede cambiar cada vez que el nodo se conecta y es la que se usa para encaminar los mensajes. Que la IP cambie es la razón por la que el panel no puede llamar al nodo por su dirección, y por tanto la razón por la que existe el modelo de publicación y suscripción de la sección 5.
Antes de contar con el Wi-Fi del centroUna red escolar suele tener restricciones que un nodo IoT no puede sortear: portal de autenticación con navegador, filtrado por MAC, puertos bloqueados o redes separadas para invitados. Conviene hablar con quien administra la red antes de diseñar, no después de montar. Y si el acceso no es posible, la alternativa razonable es un punto de acceso propio con un router sencillo, o el modo en que la propia placa crea su red para configuración local.

4. Conectar la placa al Wi-Fi

import network
import time

SSID = "IES_Huerto"
CLAVE = "..."                 # nunca se escribe en el código que se publica

def conectar_wifi(tiempo_max_s=20):
    """Conecta a la red Wi-Fi. Devuelve True si lo consigue."""
    wlan = network.WLAN(network.STA_IF)
    wlan.active(True)
    if wlan.isconnected():
        return True
    wlan.connect(SSID, CLAVE)
    inicio = time.time()
    while not wlan.isconnected():
        if time.time() - inicio > tiempo_max_s:
            print("Sin conexión tras", tiempo_max_s, "s")
            return False
        time.sleep(0.5)
    print("Conectado. IP:", wlan.ifconfig()[0])
    return True
Fíjate en el bucle de esperaEs el while con límite de seguridad del Tema 14, y aquí se entiende por qué era una regla y no un consejo. Sin el tiempo_max_s, un router apagado deja la placa esperando para siempre: no riega, no mide y no avisa. Con el límite, la función devuelve False y el programa principal puede decidir seguir funcionando sin red, que es exactamente lo que debe hacer un sistema de riego.
# El uso correcto: la red es opcional, el riego no
if conectar_wifi():
    publicar_estado()
else:
    print("Modo autónomo: se riega igual, se registra en el archivo local")
# ... y a continuación el bucle de control, que funciona en los dos casos
Las credenciales no van en el código que se publicaSi el proyecto se sube a un repositorio como el del Tema 4, la contraseña del Wi-Fi queda publicada para siempre —y borrarla después no sirve, porque el historial la conserva—. La práctica correcta es guardarla en un archivo aparte —por ejemplo secretos.py— que se importa y que se excluye del repositorio mediante .gitignore. Es exactamente la misma regla de privacidad del Tema 4, aplicada a un dato que no es personal pero sí sensible.

5. MQTT y HTTP

Un protocolo es un conjunto de reglas acordadas para intercambiar mensajes. En el internet de las cosas conviven sobre todo dos, y sirven para cosas distintas.

HTTP · petición y respuesta

El cliente pregunta y el servidor responde. Es el protocolo de la Web. Simple, universal y con una limitación: el servidor no puede iniciar la conversación. Para saber si hay una orden nueva, el nodo tiene que preguntar cada cierto tiempo.

MQTT · publicación y suscripción

Los dispositivos se conectan a un broker y le entregan mensajes etiquetados con un tema. El broker los reparte a todos los suscritos a ese tema. La conexión queda abierta, de modo que una orden llega al instante sin preguntar.

Cuándo cada uno
CriterioMQTTHTTP
ModeloPublicación y suscripciónPetición y respuesta
Tamaño del mensajeCabecera de pocos bytesCabeceras de cientos de bytes
ConsumoBajo: conexión abierta y mensajes mínimosMayor: cada petición reabre y repite cabeceras
Órdenes hacia el dispositivoInmediatasSolo si el dispositivo pregunta
Varios receptoresNaturales: todos los suscritosHay que pedirlo uno a uno
FacilidadRequiere un brokerVale cualquier servidor web
Uso típicoTelemetría y control de dispositivosEnviar un dato a un servicio o consultar una página
Por qué el KR-1 usa MQTTPorque necesita las dos direcciones. Publicar la humedad podría hacerse con HTTP sin problema. Pero recibir la orden «no riegues, el depósito está vacío» exigiría que el nodo preguntara cada minuto —gastando energía y llegando tarde—, mientras con MQTT el mensaje llega en cuanto alguien lo publica. Y el desacoplamiento es la otra ventaja: el panel no necesita saber dónde está el nodo, lo que resuelve el problema de la IP cambiante de la sección 3.
Los temas se organizan como carpetas. Un tema MQTT es una cadena con niveles separados por barras: kr1/bancal2/humedad, kr1/bancal2/orden. Y quien se suscribe puede usar comodines: kr1/+/humedad recibe la humedad de todos los bancales, y kr1/# todo lo del proyecto. Diseñar bien el árbol de temas al principio es lo que permite añadir un segundo bancal después sin tocar el panel.

6. Publicar las lecturas

Los datos se envían como texto, y el formato convenido en el internet de las cosas es JSON: exactamente el diccionario del Tema 15, escrito como cadena.

import ujson
from umqtt.simple import MQTTClient

BROKER = "broker.ejemplo.org"
CLIENTE = "kr1-bancal2"          # único: dos iguales se expulsan
TEMA_DATOS = b"kr1/bancal2/humedad"

def publicar(cliente, humedad_pct, cuentas, rego):
    """Publica una lectura en formato JSON."""
    mensaje = {
        "humedad_pct": round(humedad_pct, 1),
        "cuentas": cuentas,
        "rego": rego,
    }
    cliente.publish(TEMA_DATOS, ujson.dumps(mensaje))

cliente = MQTTClient(CLIENTE, BROKER, keepalive=60)
cliente.connect()
publicar(cliente, 8.5, 2847, True)
# Se envía: {"humedad_pct": 8.5, "cuentas": 2847, "rego": true}
Por qué JSON y no «8.5»Enviar solo el número obliga a que quien lo reciba sepa de antemano qué significa, en qué unidad está y en qué orden vienen los campos. Con JSON, cada dato viaja con su nombre, y añadir la temperatura el mes que viene no rompe al panel que ya estaba funcionando. Es la misma razón por la que en el Tema 15 el histórico se guardaba como lista de diccionarios y no como lista de tuplas: los datos viajan con su nombre.
Qué publicar y cada cuánto. No se publica cada lectura: se publica lo que alguien va a mirar. El KR-1 publica cada quince minutos la humedad, y además un mensaje inmediato cuando ocurre algo —empieza a regar, termina, detecta un fallo—. Esa combinación de cadencia fija más eventos es el patrón habitual en telemetría, y reduce el consumo respecto a publicar continuamente. El Tema 18 lo formalizará como monitorización.

7. Recibir órdenes

TEMA_ORDEN = b"kr1/bancal2/orden"
riego_bloqueado = False

def al_recibir(tema, mensaje):
    """Se ejecuta cada vez que llega un mensaje del broker."""
    global riego_bloqueado
    orden = ujson.loads(mensaje)
    if orden.get("bloquear") is True:
        riego_bloqueado = True
        print("Riego bloqueado por orden remota")
    elif orden.get("bloquear") is False:
        riego_bloqueado = False
        print("Riego desbloqueado")

cliente.set_callback(al_recibir)
cliente.subscribe(TEMA_ORDEN)

# En el bucle principal, comprobar si ha llegado algo
while True:
    cliente.check_msg()                 # no bloquea: mira y sigue
    humedad = leer_humedad()
    if humedad < UMBRAL and not riego_bloqueado:
        regar(30)
    publicar(cliente, humedad, 0, False)
    time.sleep(900)
Una función que se ejecuta cuando pasa algoal_recibir no la llama tu programa: la llama la biblioteca cuando llega un mensaje. Se le llama función de respuesta o callback, y es la primera vez en el curso que aparece código que no se ejecuta en el orden en que está escrito. Es también el motivo de la única variable global del bloque: la función tiene que comunicar al programa principal que el estado ha cambiado, y global es la forma sencilla de hacerlo. En el Tema 18 esto se resolverá mejor, con una máquina de estados.
Una orden remota no puede desactivar una protecciónEsta es una regla de diseño, no una recomendación. El bloqueo remoto puede impedir que se riegue, pero jamás debe poder forzar un riego indefinido ni anular el límite de tiempo del Tema 14. La razón es sencilla: un mensaje puede llegar corrupto, duplicado, retrasado o de alguien que no debería estar ahí. Las protecciones viven en el nodo y no se negocian por la red. El Tema 18 lo llamará enclavamiento.
Piensa: el nodo publica cada quince minutos. Si se queda sin red tres días, ¿cómo se enteraría alguien? Una posibilidad es que el panel vigile la ausencia de mensajes, en lugar de esperar un mensaje de error. MQTT incluso ofrece un mecanismo para ello, el mensaje de última voluntad, que el broker publica automáticamente si el nodo desaparece. ¿Qué te parece más fiable: que el sistema avise de que va mal, o que el vigilante note que ha dejado de hablar?

8. Otras tecnologías de enlace

El Wi-Fi no es la única forma de conectar un nodo, y conviene saber qué existe, aunque en este curso no las usemos. Se estudian a nivel de reconocimiento: para qué sirve cada una y por qué no es la elegida aquí.

Cuatro tecnologías de enlace comparadas
TecnologíaAlcanceVelocidadConsumoUso típico
Wi-FiDecenas de metrosAltaAltoNodos con alimentación disponible y acceso a un router. El KR-1.
Bluetooth de baja energíaUnos 10 mBajaMuy bajoPulseras, sensores que se leen con el móvil al pasar. No llega a internet solo.
ZigbeeDecenas de metros, en mallaBajaMuy bajoDomótica del Tema 23: muchos nodos que se reenvían entre sí. Necesita pasarela.
LoRaKilómetrosMuy bajaMuy bajoSensores agrícolas o urbanos aislados. Pocos bytes cada muchos minutos.
La regla que explica la tabla enteraAlcance, velocidad y consumo no se pueden tener los tres a la vez. Wi-Fi da velocidad y paga consumo; LoRa da alcance y paga velocidad; Bluetooth de baja energía ahorra consumo y paga alcance. Elegir tecnología de enlace es decidir cuál de los tres sacrificas, y la decisión la impone la aplicación: un huerto a veinte metros del edificio con panel solar admite Wi-Fi; el mismo sensor en un campo a cinco kilómetros, con una pila, exige LoRa.
Y dos ideas de red que conviene conocer. Una red en estrella —el Wi-Fi— tiene todos los nodos colgando de un punto central: si cae, cae todo. Una red en malla —Zigbee— permite que cada nodo reenvíe los mensajes de los demás, de modo que la red se reconfigura sola si uno falla y el alcance total crece con el número de nodos. Es la razón de que la domótica del Tema 23 use malla y no Wi-Fi para las decenas de sensores de una vivienda.

9. Seguridad, privacidad y consumo

Seguridad

Riesgos y medidas mínimas
RiesgoQué podría pasar en el KR-1Medida mínima
Mensajes sin cifrarCualquiera en la red ve las lecturas y las órdenes.Usar MQTT sobre TLS cuando el broker lo admita.
Broker abiertoCualquiera publica en tu tema y ordena regar.Usuario y contraseña en el broker; temas con permisos.
Credenciales en el códigoLa clave del Wi-Fi publicada en el repositorio.Archivo aparte excluido del control de versiones.
Contraseñas por omisiónUn dispositivo con la clave de fábrica es de acceso público.Cambiarlas todas antes de conectar nada.
Órdenes maliciosasAlguien vacía el depósito regando sin parar.Protecciones en el nodo, no en la red: límite de tiempo y de riegos diarios.
Sin actualizacionesUna vulnerabilidad conocida sigue abierta años.Prever cómo se actualizará el nodo antes de instalarlo.
Un objeto conectado es un objeto atacableConectar algo a la red le añade una función y también una superficie de ataque. Y en el internet de las cosas el problema es peor que en un ordenador por dos motivos: los dispositivos son muchos, y nadie los actualiza. Ha habido ataques masivos construidos con cámaras y grabadoras domésticas que conservaban su contraseña de fábrica. La pregunta de diseño no es «¿quién iba a querer atacar mi riego?», sino «¿qué puede hacer alguien con mi dispositivo si lo controla?».

Privacidad

Los datos de un sensor pueden ser datos personalesLa humedad de un bancal, no. Pero un sensor de presencia, un consumo eléctrico detallado o una cámara del centro sí revelan información sobre personas, y entran de lleno en la normativa de protección de datos del Tema 4.[5] Tres reglas para un proyecto escolar: medir solo lo necesario, no publicar datos que identifiquen a nadie y preguntar antes de instalar un sensor donde haya personas. Y dejarlo escrito en la memoria, porque es una decisión de diseño como cualquier otra.

Consumo del nodo

Tres estrategias de conexión y su consumo diario
EstrategiaWi-FiConsumo medioEnergía diaria
Siempre conectadoActivo las 24 h≈ 120 mA≈ 9,5 Wh
Conectar solo para publicar30 s cada 15 min≈ 31 mA≈ 2,5 Wh
Sueño profundo entre medidas30 s cada 15 min, resto dormido≈ 4 mA≈ 0,3 Wh
El sueño profundo cambia el orden de magnitudEl ESP32 puede apagar casi todo y despertar por temporizador consumiendo microamperios. Pasar de «siempre conectado» a «dormir entre medidas» divide el consumo por más de treinta, y eso decide si el panel solar del Tema 23 necesita ser de 10 W o de 1 W. El precio es que el nodo no recibe órdenes mientras duerme: hay que elegir entre control inmediato y autonomía. Para el KR-1, que revisa cada quince minutos, la espera es aceptable; para un sistema de seguridad, no lo sería.

Comprueba lo que has aprendido

Este tema se demuestra con un nodo que publica de verdad, obedece una orden y sigue funcionando cuando se le quita la red.

Qué debería mostrar tu trabajo
AspectoQué debes demostrarEvidencias posibles
ArquitecturaQue sitúas cada componente en su capa y justificas el protocolo elegido.Diagrama de las cuatro capas de tu sistema y una comparación razonada entre MQTT y HTTP.
ConexiónQue el nodo se conecta, informa de su IP y no se bloquea si no hay red.Función de conexión con tiempo máximo y prueba con el router apagado: el sistema sigue regando.
PublicaciónQue envías datos con nombre, en JSON, con una cadencia razonada.Mensajes recibidos en el broker, árbol de temas diseñado y política de cadencia más eventos.
SuscripciónQue una orden remota cambia el comportamiento sin poder anular una protección.Bloqueo remoto funcionando y comprobación de que el límite de tiempo de riego sigue actuando.
Seguridad y privacidadQue has identificado los riesgos y aplicado las medidas mínimas.Credenciales fuera del repositorio, broker con usuario y contraseña, y un apartado de privacidad en la memoria.
ConsumoQue estimas el consumo del nodo y eliges una estrategia de conexión.Tabla de consumo de las tres estrategias con la energía diaria y la elección justificada.

Prueba definitiva del bloque: desconecta el router. El KR-1 debe seguir midiendo, seguir riegando cuando toque, seguir registrando en su archivo local y volver a publicar solo cuando la red regrese. Si se queda colgado, todavía no es un sistema de control.

Glosario del tema

Broker
Servidor intermediario que recibe los mensajes publicados y los reparte a los suscritos a cada tema.
Cliente
Dispositivo o programa que se conecta a un broker o a un servidor; su nombre debe ser único.
Dirección IP
Dirección que identifica un dispositivo en una red; la asigna el router y puede cambiar.
Dirección MAC
Identificador único de fábrica del interfaz de red de un dispositivo.
Función de respuesta
Función que no llama el programa principal, sino la biblioteca cuando ocurre un suceso.
HTTP
Protocolo de petición y respuesta propio de la Web; el servidor no puede iniciar la conversación.
Internet de las cosas
Extensión de la red a objetos que no son ordenadores, con fuertes restricciones de energía, cálculo y mantenimiento.
JSON
Formato de texto para intercambiar datos con pares de clave y valor; equivalente a un diccionario.
LoRa
Tecnología de enlace de muy largo alcance, baja velocidad y bajo consumo.
Malla
Topología en la que los nodos reenvían los mensajes de los demás, de modo que la red se reconfigura sola.
MQTT
Protocolo ligero de publicación y suscripción, pensado para dispositivos con pocos recursos.
Nodo
Dispositivo que mide, decide y actúa dentro de una solución IoT.
Pasarela
Dispositivo que traduce entre una tecnología de enlace local e internet.
Protocolo
Conjunto de reglas acordadas para intercambiar mensajes.
Publicación y suscripción
Modelo en el que quien envía y quien recibe no se conocen: solo comparten el nombre de un tema.
Sueño profundo
Modo de muy bajo consumo en el que la placa apaga casi todo y despierta por temporizador.
Tema
Etiqueta jerárquica con la que se clasifica un mensaje MQTT.
Zigbee
Tecnología de enlace de bajo consumo y topología en malla, habitual en domótica.

Resumen esencial

  1. Lo que distingue un nodo IoT de un ordenador no es la tecnología de red: son las restricciones de energía, cálculo, datos y mantenimiento.
  2. La restricción que ordena todas las decisiones es que nadie va a estar delante: el nodo debe reconectarse solo y quedar en estado seguro si falla.
  3. Un sistema que no puede trabajar sin red es más frágil, no más moderno: el KR-1 riega sin internet y usa la red solo para informar.
  4. Una solución IoT tiene cuatro capas: dispositivo, red, plataforma y aplicación; y a veces una pasarela entre las dos primeras.
  5. La MAC viene de fábrica y no cambia; la IP la asigna el router y puede cambiar, y por eso el panel no puede llamar al nodo por su dirección.
  6. Todo bucle de conexión lleva tiempo máximo: sin él, un router apagado deja la placa esperando para siempre.
  7. Las credenciales van en un archivo aparte excluido del repositorio, porque el historial conserva lo que se publica una vez.
  8. HTTP es petición y respuesta; MQTT es publicación y suscripción, con mensajes mínimos y órdenes inmediatas.
  9. En MQTT el nodo y el panel no se conocen: solo comparten el nombre de un tema, organizado por niveles como carpetas.
  10. Los datos viajan en JSON, con cada campo con su nombre, de modo que añadir una medida no rompe lo que ya funcionaba.
  11. Se publica con una cadencia fija y además ante cada suceso relevante; no cada lectura.
  12. Una orden remota puede impedir una acción pero nunca desactivar una protección: las protecciones viven en el nodo.
  13. Alcance, velocidad y consumo no se pueden tener a la vez: Wi-Fi, Bluetooth de baja energía, Zigbee y LoRa sacrifican uno cada uno.
  14. Un objeto conectado es un objeto atacable, y la pregunta de diseño es qué puede hacer alguien si lo controla.
  15. Un sensor puede generar datos personales; se mide solo lo necesario y se pregunta antes de instalarlo donde haya personas.
  16. El sueño profundo divide el consumo por más de treinta, a cambio de no recibir órdenes mientras duerme.

Fuentes y recursos fiables