Dispositivos conectados y casos de uso

01 · Punto de partida

Un chip, muchos mundos

Imaginá tres dispositivos construidos con la misma placa ESP32. El primero es un termostato en la pared de una casa: tiene energía de la red eléctrica, un Wi-Fi que ya existe y un usuario que quiere configurarlo desde el celular en cinco minutos. El segundo vigila la vibración de un motor en una planta: debe funcionar años sin parar, soportar ruido eléctrico, calor y polvo, y entregar datos que un sistema de mantenimiento usará para decidir. El tercero mide la humedad de un campo a dos kilómetros de la casa más cercana, sin enchufe ni Wi-Fi, y debe vivir años con una batería.

El código para leer el sensor y enviar un valor es casi el mismo en los tres. Todo lo demás es distinto: la alimentación, la red, la caja, la seguridad, el costo, la forma de instalar y de actualizar. Un buen diseñador de IoT no empieza por el microcontrolador sino por el caso de uso, porque es el caso el que dicta cómo debe ser el dispositivo.

Este tema no enseña tecnologías sino a leer problemas. En los siguientes bloques, cada tecnología se evalúa contra la ficha que armes acá.

02 · Papeles

Qué papel cumple cada dispositivo

Antes de mirar sectores conviene clasificar a los dispositivos por la función que cumplen, porque cada papel impone un diseño diferente.

Un mismo equipo puede cumplir varios papeles. El termostato es sensor (temperatura), controlador (decide) y actuador (maneja la caldera). Lo importante es que cuanto más actúa un dispositivo sobre el mundo físico, más importa que sea seguro por sí mismo, y cuanto más depende de una batería, más importa cada mensaje que envía.

03 · Panorama

Los sectores y sus perfiles

Cinco sectores concentran buena parte de los proyectos. Para cada uno, la tabla resume qué se mide o controla, qué red se usa con más frecuencia, de dónde viene la energía y cuál es la exigencia que manda en el diseño.

El gráfico muestra algo que se confirma en el laboratorio: los equipos de batería mandan pocos datos pequeños, y los de red eléctrica pueden enviar mucho más. Un parche de salud es un caso aparte: manda tanto como un termostato, pero con una batería minúscula, por eso se recarga cada pocos días.

04 · Casos

Cada caso por dentro

Hogar

El usuario no es técnico: quiere desembalar el producto, conectarlo y que funcione. Pesan el aprovisionamiento (cómo se le da la clave del Wi-Fi sin pantalla ni teclado), la privacidad (una cámara o un micrófono manejan datos íntimos) y la compatibilidad con otros productos. El costo por unidad es muy ajustado y el producto debe seguir andando aunque el fabricante cierre su servicio, algo que se olvida con frecuencia.

Industria

El IoT industrial (IIoT) agrega sensores a máquinas que ya existen para vigilar su estado y predecir fallas. Importan la robustez (temperatura, polvo, vibración, ruido eléctrico), la disponibilidad continua, la integración con protocolos industriales (Modbus, OPC UA) y la separación entre la red de planta y la de oficinas por razones de seguridad. Los equipos se compran para durar décadas, y el ciclo de decisión es largo.

Agro

Los sensores están lejos de todo: sin red eléctrica, sin Wi-Fi y a veces sin cobertura celular. Lo que manda es el alcance (LoRa llega a kilómetros) y la autonomía: batería, a menudo con un panel solar pequeño. Se mide poco y lento (la humedad del suelo cambia en horas) y, a cambio, el equipo tiene que soportar sol, lluvia, polvo y animales.

Ciudad

La palabra clave es escala: miles de contenedores, plazas de estacionamiento o luminarias. Cada dispositivo se instala una vez y se visita lo menos posible, de modo que importan la batería de años, la comunicación económica (LoRa, NB-IoT) y la gestión masiva: dar de alta, vigilar y actualizar a distancia. También cuenta la resistencia al vandalismo y a la intemperie.

Salud

Los datos son sensibles y los errores tienen consecuencias. Pesan la privacidad y la normativa (los dispositivos médicos están regulados), la precisión de la medición y la confiabilidad: no es lo mismo perder el dato de un contador de pasos que el de una alarma cardíaca. Los equipos son pequeños y portátiles, con baterías chicas que se recargan seguido.

05 · Crecimiento

Del prototipo a la flota

Un prototipo con un dispositivo funciona casi siempre. Lo que cambia al pasar a cientos o miles de unidades no es la lógica del firmware sino todo lo que lo rodea:

Un cambio pequeño por equipo se vuelve grande en la flota. Un dispositivo que sube 100 KB más al día cuesta nada; diez mil dispositivos suben 1 GB más por día. Un reinicio ocasional por falla de red que nadie nota en uno, en diez mil equipos ocurre varias veces por hora. En la escala, lo raro se vuelve cotidiano.

06 · Método

La ficha de un caso de uso

Antes de elegir hardware, completá esta ficha. Sirve para ordenar las ideas y para discutir con quien contrata el proyecto:

1. Qué se mide o controla y con qué precisión.
2. Con qué frecuencia cambia la variable y cada cuánto hay que informar.
3. Cuántos dispositivos habrá al inicio y dentro de tres años.
4. Dónde se instalan: interior, exterior, cerca o lejos de una red, accesibles o no.
5. De dónde sale la energía y cuánto debe durar sin intervención.
6. Qué plazo tiene cada reacción y qué ocurre si se pierde.
7. Qué datos son sensibles y quién puede verlos o controlar el equipo.
8. Cómo se instala, se actualiza y se repara y quién lo hace.

Las respuestas arman un perfil como el de la tabla del apartado 3 y descartan opciones: con batería de años y kilómetros de distancia, el Wi-Fi queda fuera; con una cerradura, la telemetría pasa a segundo plano frente a la seguridad. La ficha convierte el «quiero conectar esto» en requisitos verificables.

07 · Analogía con programación

Calcular el perfil de un caso en Python

Cada sector se puede describir con unos pocos números: cuántos mensajes por día envía un equipo, cuántos bytes pesa cada uno, cuánta energía cuesta enviarlo, qué batería tiene y cuántos días como mínimo debe durar. Con ellos, el programa calcula para una flota entera los mensajes por día, los gigabytes por mes y la autonomía, y emite un veredicto: viable, batería insuficiente o volumen alto (más de 100 GB por mes). El parámetro multiplicador permite enviar más o menos seguido que lo habitual.

SUENO_MAH_DIA = 0.24   # 0,01 mA durmiendo las 24 horas
MUESTRA_MAH = 0.0005   # costo de una lectura
LIMITE_GB_MES = 100    # a partir de aquí el volumen de datos pesa en el costo

# caso: (mensajes por día, bytes por mensaje, mAh por mensaje, batería en mAh o None, autonomía mínima en días)
CASOS = {
    "hogar":     (288, 150, 0.02, None, 0),       # termostato o enchufe: Wi-Fi, red eléctrica
    "industria": (1440, 400, 0.02, None, 0),      # vibración de un motor: cada minuto
    "agro":      (48, 60, 0.002, 2000, 1095),     # humedad de suelo: LoRa, 3 años como mínimo
    "ciudad":    (24, 40, 0.08, 2000, 730),       # nivel de un contenedor: celular, 2 años
    "salud":     (1440, 30, 0.002, 200, 7),       # parche con Bluetooth LE: una semana
}


def perfil(caso, flota, multiplicador=1.0):
    msgs, bytes_msg, mah_msg, bateria, minimo = CASOS[caso]
    msgs = msgs * multiplicador
    por_dia = msgs * flota
    gb_mes = por_dia * bytes_msg * 30 / 1e9
    dias = None
    if bateria is not None:
        mah = SUENO_MAH_DIA + msgs * (MUESTRA_MAH + mah_msg)
        dias = bateria / mah
    if dias is not None and dias < minimo:
        veredicto = "batería insuficiente"
    elif gb_mes > LIMITE_GB_MES:
        veredicto = "volumen alto"
    else:
        veredicto = "viable"
    return por_dia, gb_mes, dias, veredicto


print("caso       flota   mensajes/día   GB/mes   batería       resultado")
for caso in CASOS:
    por_dia, gb, dias, veredicto = perfil(caso, 1000)
    bat = "red eléctrica" if dias is None else f"{dias:,.0f} días"
    print(f"{caso:<10} {1000:>5} {por_dia:>13,.0f} {gb:>8.2f}   {bat:<13} {veredicto}")

print()
for caso, flota, mult in [("agro", 1000, 4), ("ciudad", 1000, 4), ("industria", 10000, 1)]:
    por_dia, gb, dias, veredicto = perfil(caso, flota, mult)
    bat = "red eléctrica" if dias is None else f"{dias:,.0f} días"
    print(f"{caso}, flota {flota}, envío x{mult}: {por_dia:,.0f} mensajes/día, {gb:.1f} GB/mes, {bat} -> {veredicto}")

Resultado con los valores iniciales, para 1000 equipos: hogar, 288.000 mensajes por día y 1,30 GB por mes; industria, 1.440.000 mensajes y 17,28 GB; agro, 48.000 mensajes, 0,09 GB y 5556 días de batería; ciudad, 24.000 mensajes, 0,03 GB y 921 días; salud, 1.440.000 mensajes, 1,30 GB y 52 días. Todos resultan viables. Si el agro envía cuatro veces más seguido, la autonomía baja a 2778 días y sigue siendo suficiente. El contenedor de la ciudad, con el mismo cambio, cae a 251 días y queda por debajo de los 730 exigidos: «batería insuficiente». Y la industria con 10.000 equipos suma 14,4 millones de mensajes por día y 172,8 GB por mes: «volumen alto». (La salida de Python usa la coma como separador de miles y el punto como decimal.)

El modelo ilustra dos cuellos de botella distintos: en los equipos con batería manda el consumo por mensaje; en las flotas grandes con red eléctrica manda el volumen de datos. Resolver uno no resuelve el otro, y por eso hay que conocer el caso antes de optimizar.

08 · Exploración interactiva

Cinco sectores, una flota

Este laboratorio ejecuta el mismo modelo del código anterior. Elegí un sector, el tamaño de la flota y qué tan seguido se envía respecto de lo habitual. Las barras comparan, en escala logarítmica, los mensajes diarios totales de los cinco sectores con la misma flota; el elegido va resaltado. Los consumos y tamaños son valores didácticos de orden de magnitud.

Recorrido guiado

1. Con los valores iniciales (agro, 1000 equipos, frecuencia habitual), calculá. Son 48.000 mensajes por día, 5556 días de batería sobre un mínimo de 1095 y un volumen insignificante: viable.
2. Pasá a 4 veces más seguido. La autonomía baja a 2778 días, que sigue alcanzando. En el agro hay margen para medir más.
3. Elegí Ciudad con frecuencia habitual: 921 días, por encima de los 730 exigidos. Ahora ponelo 4 veces más seguido: baja a 251 días y el resultado es «Batería insuficiente». La radio celular cuesta mucho por mensaje.
4. Elegí Industria con 1000 equipos: 1,44 millones de mensajes por día y 17,3 GB al mes, viable. Subí la flota a 10.000: 172,8 GB al mes y «Volumen alto». No hay batería que cuidar; el problema es el servidor.
5. En Industria con 10.000 equipos, probá 4 veces menos seguido: 43,2 GB al mes y vuelve a ser viable. Reducir el envío resuelve un problema de volumen igual que uno de energía.
6. Elegí Salud: 1.440.000 mensajes por día con 1000 equipos, igual que la industria, pero con 52 días de autonomía en una batería de 200 mAh; por encima de los 7 días exigidos. El mismo número de mensajes, perfil de exigencia totalmente distinto.

09 · Comprensión

Confusiones frecuentes

10 · Práctica guiada

Predecí antes de comprobar

1. Emparejar caso y exigencia

Asociá cada caso con su exigencia dominante: (1) una flota de 8000 luminarias urbanas; (2) un oxímetro de pulsera; (3) un sensor de nivel en un pozo rural; (4) un enchufe inteligente de venta masiva. Exigencias: (a) autonomía de años y alcance de kilómetros; (b) facilidad de instalación y costo mínimo; (c) gestión masiva y mantenimiento mínimo; (d) privacidad y confiabilidad de datos personales.

2. Volumen del hogar

Un termostato envía 288 mensajes de 150 bytes por día. ¿Cuántos datos genera una flota de 2000 equipos en un mes de 30 días?

3. Batería del campo

Un sensor agrícola envía 48 mensajes por día y gasta 0,0025 mAh por cada envío con su lectura, más 0,24 mAh diarios durmiendo. ¿Cuánto dura una batería de 2000 mAh? ¿Y si pasa a enviar cada 5 minutos?

4. El contenedor que se queda sin batería

Un sensor de contenedor envía 24 mensajes al día por celular y dura 921 días. Se decide pasar a 96 mensajes al día para detectar antes el llenado. ¿Cuánto durará y qué alternativa hay?

5. Salud: un tipo de exigencia diferente

Un parche envía 1440 mensajes por día y su batería de 200 mAh dura 52 días. ¿Es un problema? ¿Y si el requisito fuera de 90 días?

6. Escala industrial

Una planta pasa de 1000 a 10.000 sensores de vibración (1440 mensajes de 400 bytes por día cada uno). ¿Cuántos GB por mes? ¿Qué se puede hacer para reducirlo?

11 · Síntesis

Ideas para recordar

¿Listo para el tema 4?

Antes de avanzar, elegí un producto IoT que conozcas y completá su ficha: qué mide, cada cuánto, cuántas unidades, dónde, con qué energía, con qué plazo, qué datos son sensibles y cómo se actualiza. Después, ubicalo en uno de los cinco sectores y explicá qué exigencia domina su diseño.

En el próximo tema estudiamos los microcontroladores con conectividad: ESP32, ESP8266, RP2040 W y nRF, cómo comparar sus radios, su memoria y su consumo, y cómo elegir la plataforma que mejor responde a la ficha de tu caso.