Qué es el Internet de las Cosas

01 · Punto de partida

Objetos que ahora hablan

Hasta hace pocos años, un termómetro marcaba una temperatura y alguien tenía que ir a mirarlo. Hoy el mismo termómetro, con un microcontrolador y una radio Wi-Fi, envía cada minuto su lectura a un servidor, y una aplicación avisa al dueño de una cámara frigorífica cuando la puerta quedó abierta, aunque esté a cien kilómetros. El termómetro no cambió de función: cambió de lugar en el mundo, porque ahora forma parte de una red.

En los cursos anteriores aprendiste a leer sensores, a mover actuadores, a comunicar dos dispositivos y a diseñar el firmware de un sistema embebido. Este curso suma lo que falta para que ese dispositivo salga de la mesa de trabajo y se vuelva parte de un sistema distribuido: conectividad, protocolos, servidores, datos, seguridad y mantenimiento a distancia.

Este primer tema arma el mapa general. Los siguientes recorren cada pieza: sensores, redes, HTTP, MQTT, almacenamiento, control remoto, seguridad y actualización a distancia.

02 · Definición

Definición de Internet de las Cosas

El Internet de las Cosas (IoT, por Internet of Things) es el conjunto de objetos físicos que incorporan sensores, capacidad de cómputo y conectividad para intercambiar datos con otros dispositivos y con servicios en la red. La «cosa» puede ser un sensor de pocos dólares, un electrodoméstico, una máquina industrial o un vehículo; lo que la hace parte del IoT es que su información viaja y que, muchas veces, también recibe instrucciones.

Un dispositivo IoT reúne cinco elementos:

• Sensores y actuadores. Son su contacto con el mundo físico: miden magnitudes y, si corresponde, accionan relés, motores o válvulas.
• Procesador con firmware. Un microcontrolador que lee, decide y organiza la comunicación; es el sistema embebido que ya conocés.
• Conectividad. Un enlace de red (Wi-Fi, Bluetooth, LoRa, celular) con el que sale de su entorno inmediato.
• Datos y servicios. Alguien recibe lo que el dispositivo mide, lo guarda, lo muestra o actúa en consecuencia.
• Identidad y seguridad. Cada dispositivo debe poder demostrar quién es y proteger lo que envía y lo que acepta.

Notá que la ecuación suma, no reemplaza. Todo lo que se aprendió sobre firmware, tiempo, memoria y consumo sigue valiendo; la conexión agrega posibilidades y también problemas nuevos, que ocupan casi todo este curso.

03 · Contraste

Qué lo distingue de lo que ya conocés

Como programador, el IoT te queda a mitad de camino entre dos mundos que conocés: el del firmware que corre solo en una placa y el de las aplicaciones web que hablan con servidores. Conviene ver en qué se parece y en qué difiere de cada uno.

La tabla muestra por qué el IoT es un oficio propio. Tiene las limitaciones de energía y memoria de un embebido y, a la vez, las exigencias de seguridad y disponibilidad de un sistema en red; y sus equipos están distribuidos, a veces en lugares a los que cuesta llegar.

04 · Estructura básica

Las cuatro capas de un sistema IoT

Casi todos los sistemas IoT, desde un sensor casero hasta una red industrial, se pueden describir con las mismas cuatro capas. Entender en cuál está cada problema ayuda a resolverlo y a decidir dónde conviene programar cada función.

Un ejemplo con un sensor de humedad de maceta. En la capa de dispositivo, un microcontrolador mide la humedad con un sensor capacitivo y duerme el resto del tiempo. En la red, usa Wi-Fi para publicar un mensaje con la lectura. En la plataforma, un servidor recibe el mensaje, lo guarda y compara con un umbral. En la aplicación, el dueño ve la gráfica en el celular y recibe una notificación: «la planta necesita agua». Si hay una electroválvula, el camino de vuelta le permite abrirla con un comando.

Dos reglas de diseño salen de este esquema. La primera: cada capa se puede reemplazar sin rehacer las otras si las interfaces están bien definidas (por ejemplo, cambiar Wi-Fi por LoRa sin tocar la aplicación). La segunda: una decisión se puede tomar en cualquier capa, y dónde conviene depende de la rapidez requerida y de cuánto se pueda transmitir; es el tema del bloque sobre procesamiento local.

05 · Comportamiento

El ciclo medir, enviar, recibir y actuar

En un sistema embebido aislado, el lazo era sentir, decidir y actuar. En IoT el lazo se prolonga por la red: el dispositivo mide, envía lo medido, recibe información u órdenes y actúa. Una parte de la decisión puede quedar en el dispositivo y otra pasar al servidor.

1. Medir. Leer el sensor, convertir la señal a un valor con unidad y ponerle una marca de tiempo.
2. Enviar. Dar formato a la lectura (por ejemplo, JSON) y transmitirla; ésta es la telemetría.
3. Recibir. Aceptar configuraciones o comandos del servidor, y confirmar que se recibieron.
4. Actuar. Ejecutar la orden sobre el actuador y devolver el estado resultante.
5. Dormir. Si el equipo funciona con batería, apagar lo que no se usa hasta el próximo ciclo.

Un mensaje de telemetría es simple, pero conviene que traiga siempre el mismo conjunto de datos:

{
  "dispositivo": "camara-07",
  "momento": "2026-11-07T14:32:00Z",
  "temperatura_c": 4.3,
  "puerta_abierta": false,
  "bateria_pct": 87
}

Cuatro cosas hacen útil a un mensaje así: el identificador dice quién lo envía, el momento permite ordenar los datos aunque lleguen tarde, cada valor lleva su unidad en el nombre, y el estado del propio dispositivo (batería) permite vigilarlo. Vamos a ver este tipo de estructura en el tema 12 y en los dedicados a HTTP, JSON y MQTT.

06 · Dificultades

Lo difícil del IoT

Conectar un dispositivo a Internet es fácil: cualquier placa con Wi-Fi lo logra en minutos. Lo difícil es que siga funcionando bien, de forma segura y a bajo costo, con miles de unidades durante años. Cinco desafíos aparecen en casi todos los proyectos:

• Energía. Transmitir es de lo que más gasta un dispositivo. Una radio activa puede consumir cientos de veces más que el procesador dormido, por lo que enviar menos y dormir más define la autonomía.
• Conexión poco confiable. Las redes se caen, la señal varía y los servidores se reinician. El firmware debe reintentar con criterio, guardar datos mientras no hay red y reconectarse solo.
• Escala. Pasar de uno a mil dispositivos obliga a pensar en identidad, alta de equipos, monitoreo y costo de los datos transmitidos. Lo que se hace a mano con uno es inviable con mil.
• Seguridad. Un dispositivo conectado es una puerta a la red. Claves por defecto, comunicación sin cifrar y firmware sin actualizar son las causas más comunes de incidentes.
• Mantenimiento. Corregir un error en campo exige poder actualizar el firmware a distancia, de forma segura y sin dejar equipos inutilizados.

Cada desafío tiene su bloque en este curso. Por ahora basta con quedarse con una idea: en IoT no se diseña un dispositivo, se diseña un servicio del que el dispositivo es una parte, con un ciclo de vida que dura mucho más que la demostración inicial.

07 · Analogía con programación

Simular un sensor conectado en Python

Para sentir el compromiso de diseño no hace falta hardware: alcanza con simular. El programa modela un sensor de una cámara frigorífica durante un día. La temperatura oscila alrededor de 4 °C y, a las 13:20, alguien deja la puerta abierta durante 80 minutos, de modo que sube por encima de los 8 °C del umbral de alarma. El dispositivo mide cada periodo minutos y decide cuándo transmitir: siempre (periodico) o solo si el valor cambió al menos 0,5 °C o pasó una hora sin enviar nada (cambio). Para cada configuración calcula los mensajes enviados, la energía consumida, la demora en avisar la alarma y la autonomía de una batería de 2000 mAh.

import math

ALARMA = 8.0           # °C: por encima de este valor hay que avisar
BATERIA_MAH = 2000     # capacidad de la batería
SUENO_MAH_DIA = 0.24   # 0,01 mA durmiendo las 24 horas
MUESTRA_MAH = 0.0005   # costo de leer el sensor una vez
COSTO_MSG = {"wifi": 0.02, "lora": 0.002, "celular": 0.08}   # mAh por mensaje enviado


def temperatura(minuto):
    t = 4 + 0.5 * math.sin(2 * math.pi * minuto / 720)    # ciclo normal de la cámara
    if 800 <= minuto < 840:
        t += (minuto - 800) * 0.2                         # alguien deja la puerta abierta
    elif 840 <= minuto < 880:
        t += (880 - minuto) * 0.2                         # y la cierra
    return t


def simular(periodo, modo, medio):
    ultimo, ultimo_min = None, -9999
    mensajes = muestras = 0
    aviso = None
    for m in range(0, 1440, periodo):
        t = temperatura(m)                                # medir
        muestras += 1
        if modo == "periodico":                           # decidir si vale la pena enviar
            enviar = True
        else:
            enviar = ultimo is None or abs(t - ultimo) >= 0.5 or m - ultimo_min >= 60
        if enviar:                                        # enviar
            mensajes += 1
            ultimo, ultimo_min = t, m
            if t > ALARMA and aviso is None:
                aviso = m
    inicio = next(m for m in range(1440) if temperatura(m) > ALARMA)
    mah = SUENO_MAH_DIA + muestras * MUESTRA_MAH + mensajes * COSTO_MSG[medio]
    demora = "no avisó" if aviso is None else f"{aviso - inicio} min"
    return mensajes, mah, demora, BATERIA_MAH / mah / 365


print("modo       período  medio    mensajes/día  mAh/día  aviso     batería")
for modo, periodo, medio in [("periodico", 1, "wifi"), ("periodico", 15, "wifi"),
                             ("periodico", 60, "wifi"), ("cambio", 1, "wifi"),
                             ("cambio", 5, "lora"), ("periodico", 1, "celular")]:
    n, mah, demora, anios = simular(periodo, modo, medio)
    print(f"{modo:<10} {periodo:>4} min  {medio:<8} {n:>8}  {mah:>10.2f}  {demora:>8}  {anios:>5.1f} años")

Resultado con los valores iniciales: enviar cada minuto por Wi-Fi son 1440 mensajes por día, 29,76 mAh diarios y el aviso es inmediato, pero la batería dura apenas unos 67 días (0,2 años). Con el celular, el mismo ritmo consume 116,16 mAh por día y la batería se agota en unos 17 días. Enviar cada 15 minutos baja el gasto a 2,21 mAh por día (2,5 años) y el aviso llega 6 minutos después de pasar el umbral. Cada hora, en cambio, son 7,5 años de batería pero el aviso tarda 21 minutos. El modo cambio a 1 minuto envía solo 49 mensajes, avisa a los 2 minutos y rinde 2,8 años. Con LoRa y revisión cada 5 minutos, 39 mensajes y 11,9 años.

El código muestra la tensión central de este curso: medir seguido es barato; transmitir es caro. La mejor solución no es enviar siempre ni enviar rara vez, sino medir seguido y enviar solo lo que importa. Esa decisión local, tomada en el propio dispositivo, es una de las ideas más rentables de todo el IoT.

08 · Exploración interactiva

Un sensor de cámara frigorífica, de extremo a extremo

Este laboratorio ejecuta el mismo modelo del código anterior y dibuja la temperatura de la cámara durante un día. Elegí el medio de red, la estrategia de envío y cada cuántos minutos mide el sensor. Los puntos blancos son los mensajes que realmente se enviaron; la línea punteada naranja es el umbral de alarma. Los consumos son valores didácticos de orden de magnitud, no mediciones de un modelo concreto.

Recorrido guiado

1. Con los valores iniciales, simulá. Son 96 mensajes por día, 2,21 mAh, 2,5 años de autonomía y un aviso 6 minutos después de pasar el umbral. Es un equilibrio razonable.
2. Poné 1 minuto con «Enviar cada medición». El aviso es inmediato, pero son 1440 mensajes, unos 5 MB al mes por sensor y la batería dura unos 67 días. Multiplicá por mil sensores.
3. Pasá a 60 minutos. La batería rinde 7,5 años, pero la alerta llega 21 minutos después de pasar el umbral: para una cámara con mercadería puede ser tarde.
4. Volvé a 1 minuto y elegí «Enviar solo si cambia 0,5 °C». Los mensajes bajan a 49, el aviso llega en 2 minutos y la autonomía sube a 2,8 años: se mide igual de seguido, pero se transmite solo lo importante.
5. Elegí celular con envío en cada medición cada minuto: la batería dura unos 17 días. Cambiá a «solo si cambia» y vas a ver cuánto cuesta cada transmisión.
6. Elegí LoRa, «solo si cambia» y 5 minutos: 39 mensajes, 11,9 años y un aviso en 1 minuto. Es la mejor combinación del modelo, aunque en la práctica LoRa limita el tamaño y la frecuencia de los mensajes y exige estar dentro del alcance de una antena.

09 · Método de trabajo

Cómo analizar un dispositivo IoT

Frente a un producto IoT, propio o ajeno, recorré estas preguntas en orden antes de escribir código:

1. ¿Qué magnitud física mide o controla? Qué sensores y actuadores tiene, y con qué precisión y rapidez.
2. ¿Para qué se necesita ese dato? Quién lo usa y qué decisión permite. Si nadie decide nada con él, quizá no hace falta enviarlo.
3. ¿Con qué frecuencia cambia lo que mide? Eso fija cada cuánto medir y cada cuánto enviar.
4. ¿Cuánta demora admite el aviso? Segundos, minutos u horas: define la estrategia de envío.
5. ¿De dónde saca energía? Red eléctrica, batería o energía solar, y cuánto debe durar.
6. ¿Por qué red se conecta? Alcance, velocidad, costo y qué pasa cuando no hay cobertura.
7. ¿Cómo se protege? Identidad, cifrado y qué sucede si alguien accede al equipo.
8. ¿Cómo se actualiza y se vigila? Cómo llega un arreglo a mil equipos y cómo se sabe si alguno dejó de responder.

Las respuestas se condicionan entre sí: más frecuencia gasta más energía, más energía exige batería más grande, más batería sube el costo. En el tema 6 convertimos estas preguntas en requisitos medibles.

10 · Comprensión

Confusiones frecuentes

11 · Práctica guiada

Predecí antes de comprobar

1. ¿Es o no es IoT?

Decidí cuáles de estos dispositivos forman parte del IoT y justificá: (a) una lavadora sin conexión; (b) un sensor de humedad que publica lecturas por Wi-Fi; (c) una cerradura que se abre desde una aplicación; (d) un termómetro de mercurio; (e) un medidor de energía que informa a la empresa eléctrica.

2. Ubicar en capas

En un sistema de riego automático, indicá en qué capa (dispositivo, red, plataforma o aplicación) está cada elemento: (a) el sensor de humedad del suelo; (b) el broker que recibe los mensajes; (c) una notificación en el celular; (d) el módulo Wi-Fi; (e) la base de datos con el historial.

3. Cuántos datos

Un sensor envía un mensaje de 120 bytes cada 10 minutos. ¿Cuántos mensajes y cuántos bytes produce en un mes de 30 días? ¿Y una flota de 2000 sensores?

4. Autonomía

Un sensor consume 2,21 mAh por día. ¿Cuánto dura una batería de 2000 mAh? ¿Y si se reduce el consumo diario a la mitad?

5. Elegir la estrategia

Un sensor de nivel de un tanque de agua cambia muy lentamente (unos centímetros por día), pero debe avisar enseguida si el nivel cae por debajo de un mínimo. ¿Cómo conviene medir y enviar?

6. Qué pasa sin red

Un sensor envía cada 15 minutos y pierde la conexión durante 2 horas. ¿Cuántos mensajes se perderían si no guarda nada? ¿Cómo evitarlo?

12 · Síntesis

Ideas para recordar

¿Listo para el tema 2?

Antes de avanzar, definí «dispositivo IoT» con tus palabras, dibujá de memoria las cuatro capas con un ejemplo de tu casa y explicá por qué medir seguido y enviar poco puede ser mejor que enviar todo. Si podés justificar las tres respuestas, tenés la base del curso.

En el próximo tema estudiamos la arquitectura de un sistema IoT con más detalle: qué hace cada capa, cómo viaja un dato desde el sensor hasta el panel y dónde conviene tomar cada decisión.