Actuadores y salidas remotas

01 · Punto de partida

De mirar a actuar

Un sistema IoT cierra el ciclo cuando, además de medir, puede cambiar algo en el mundo: encender el riego cuando el suelo está seco, abrir una cerradura, apagar un equipo que se sobrecalienta. Con esa capacidad llegan dos problemas nuevos. El primero es eléctrico: un pin de microcontrolador entrega unos pocos miliamperes, y una bomba, una electroválvula o una lámpara necesitan cientos de veces más. El segundo es lógico: un comando que viaja por una red que pierde, duplica y retrasa mensajes puede ejecutarse mal, tarde, dos veces o nunca.

Los dos se resuelven con ideas concretas: circuitos de potencia que aíslen y protejan al microcontrolador, y una disciplina de diseño en la que el dispositivo se protege a sí mismo, sin depender de que la nube haga todo bien.

02 · Catálogo

Los actuadores más usados

Una distinción que importa para el diseño: algunas salidas son de estado (la luz queda encendida hasta nueva orden) y otras de acción (abrir una puerta, dar una dosis). Las de acción tienen efectos que no se pueden deshacer enviando la orden contraria, y requieren más cuidado.

03 · Electrónica de potencia

Cómo manejar una carga desde un pin

Un pin de un microcontrolador está pensado para señales, no para potencia. Entrega una corriente máxima del orden de 10 a 40 mA según el modelo, y la suma de todos los pines también tiene un tope. Una bobina de relé de 70 mA o un motor de 500 mA no pueden conectarse directamente: el pin se sobrecalentaría o se destruiría.

La solución es una etapa intermedia que amplifica la corriente: un transistor o un MOSFET que el pin controla y que maneja la carga con una fuente aparte.

Cuatro detalles de ese circuito concentran la mayoría de los errores:

• La resistencia de base (Rb). Limita la corriente que el pin da al transistor. Para conmutar a fondo se necesita una corriente de base mayor que la de colector dividida por la ganancia mínima del transistor, con un margen (de tres a cinco veces). Con una bobina de 70 mA y una ganancia mínima de 100, la base necesita al menos 0,7 mA; con margen de cinco, 3,5 mA, lo que con 3,3 V del pin y 0,7 V de la unión da una resistencia de unos 740 Ω (se elige 680 Ω).
• El diodo de rueda libre. Una bobina (relé, electroválvula, motor) se opone a que su corriente cambie: al cortar el transistor genera un pico de tensión de decenas de voltios que lo destruye. Un diodo en paralelo con la bobina, con el cátodo hacia el positivo, da un camino a esa corriente y absorbe el pico. Sin él, el circuito puede funcionar semanas y fallar de golpe.
• La masa común. El transistor, la fuente de la bobina y el microcontrolador comparten la referencia de 0 V. Sin ella el transistor no recibe la señal.
• Fuente separada y desacoplo. Las cargas inductivas generan ruido y bajan la tensión al arrancar. Conviene alimentarlas con una fuente adecuada y poner un condensador cerca; de lo contrario el microcontrolador se reinicia cada vez que arranca el motor.

Los módulos de relé comerciales ya traen el transistor, el diodo y, a veces, un optoacoplador que aísla eléctricamente el circuito de control. Son la forma práctica de empezar. Con ellos conviene verificar si se activan con nivel alto o bajo, y si su entrada tolera los 3,3 V del microcontrolador.

04 · Seguridad del dispositivo

Estado seguro y límites duros

Todo actuador debe tener un estado seguro: la posición en la que no causa daño cuando algo falla. Se define al diseñar y se refleja en el hardware y en el firmware.

• Qué es seguro depende de la aplicación. Una válvula de gas debe cerrarse si falla la energía (normalmente cerrada). Un ventilador de refrigeración de un equipo, en cambio, debe quedar encendido. Un calefactor, apagado. La elección «normalmente abierta o cerrada» de una electroválvula es una decisión de seguridad.
• El arranque. Al encender o reiniciar, los pines de un microcontrolador quedan unos instantes sin configurar, a veces flotantes, y una carga conectada puede activarse sola. Una resistencia de pull-down en la entrada del driver fuerza el estado apagado hasta que el firmware tome el control, y el programa debe fijar la salida en el estado seguro antes de hacer cualquier otra cosa.
• La pérdida de red. El dispositivo no puede quedar esperando órdenes indefinidamente. Según el caso, tras un tiempo sin contacto vuelve al estado seguro, mantiene el último valor o pasa a un modo local autónomo. Tiene que estar decidido y probado.
• Límites duros en el firmware. Tiempo máximo de encendido continuo, tiempo mínimo entre conmutaciones, corriente máxima, temperatura máxima. Se aplican en el dispositivo y ninguna orden remota puede saltearlos. Si la nube pide encender una bomba 5 horas y el límite es 30 minutos, la bomba se apaga a los 30.

05 · Órdenes

Comandos remotos que no se equivocan

Las redes pierden mensajes, los repiten y los entregan tarde. Un comando bien diseñado resiste esos tres problemas. Hay tres decisiones de diseño que lo logran.

La propiedad clave se llama idempotencia: ejecutar la misma orden una o varias veces produce el mismo resultado. «Fijar el estado» la tiene; «conmutar» no. En un sistema con reintentos automáticos (como MQTT con calidad de servicio mayor que cero), los duplicados son normales, no excepcionales, y las órdenes tienen que tolerarlos.

Otras tres prácticas completan el diseño:

• Temporizador de seguridad. Las órdenes de encendido llevan una duración o un vencimiento. Si la orden de apagado nunca llega, el dispositivo apaga por sí mismo. Es el seguro contra el peor fallo: la salida atascada en «encendido».
• Vencimiento del comando. Cada orden lleva su hora de emisión y una validez corta (por ejemplo, 60 segundos). Si un dispositivo estuvo sin red y recibe «abrir válvula» media hora después, debe descartarla: la situación que la motivó ya cambió.
• Autenticación. El dispositivo solo acepta órdenes firmadas o enviadas por un canal autenticado. Un actuador accesible sin autenticación es una puerta abierta; lo estudiamos en el bloque de seguridad.

Y un principio de convivencia: el control local manda. Si una persona está presente y presiona el botón de apagado, ninguna orden remota debe contradecirla de inmediato.

06 · Verificación

Confirmar lo que realmente pasó

Ordenar «encender» no significa que se haya encendido. El relé puede estar pegado, el fusible quemado, la bomba sin agua. Hay que distinguir dos estados:

• Estado deseado: lo que el sistema pidió.
• Estado real: lo que está ocurriendo en el mundo físico.

El dispositivo informa el estado real y la plataforma compara. Hay tres niveles de confirmación, de menor a mayor confianza: (1) el firmware informa que escribió el pin; (2) un contacto auxiliar del relé o una lectura del pin de realimentación confirma que cambió; (3) un sensor mide el efecto (una corriente en la bomba, un caudal en la tubería, un fin de carrera en la puerta). Para acciones críticas se debe llegar al nivel 3.

Si el estado real no coincide con el deseado después de un tiempo razonable, el sistema lo trata como una falla: reintenta, corta y avisa. Un panel que muestra «bomba encendida» porque se envió la orden, y no porque se midió corriente, miente.

07 · Vida útil

Desgaste y frecuencia de conmutación

Los actuadores mecánicos se desgastan por cada conmutación. Un relé electromecánico típico soporta del orden de cientos de miles a unos pocos millones de operaciones mecánicas, y bastante menos con carga (el arco eléctrico erosiona los contactos). Un firmware que conmuta de más acorta la vida del producto sin que nadie lo note hasta que se rompe.

Con un relé de 100.000 operaciones: si conmuta una vez por minuto dura unos 69 días; si conmuta cada 15 minutos, unos 1042 días (2,9 años). Por eso los termostatos usan una banda de histéresis (tema 1 del curso anterior), y los compresores un tiempo mínimo entre arranques, que además protege el motor. El firmware debe aplicar un intervalo mínimo entre conmutaciones aunque la lógica o la nube pidan otra cosa.

const int PIN_BOMBA = 26;
const uint32_t DURACION_MAX_MS = 30UL * 60UL * 1000UL;   // límite duro: 30 minutos
const uint32_t PAUSA_MIN_MS    = 60UL * 1000UL;          // al menos 1 minuto entre encendidos

bool encendida = false;
uint32_t instanteEncendido = 0, instanteApagado = 0;
uint32_t vencimiento = 0;              // cuándo se apaga sola por orden con duración

void apagar() {
  digitalWrite(PIN_BOMBA, LOW);
  if (encendida) instanteApagado = millis();
  encendida = false;
}

bool encender(uint32_t duracionMs) {
  if (millis() - instanteApagado < PAUSA_MIN_MS) return false;   // protege el equipo
  if (duracionMs == 0 || duracionMs > DURACION_MAX_MS) duracionMs = DURACION_MAX_MS;
  digitalWrite(PIN_BOMBA, HIGH);
  encendida = true;
  instanteEncendido = millis();
  vencimiento = instanteEncendido + duracionMs;
  return true;
}

void setup() {
  pinMode(PIN_BOMBA, OUTPUT);
  apagar();                            // estado seguro antes que cualquier otra cosa
  instanteApagado = millis() - PAUSA_MIN_MS;
}

void loop() {
  if (encendida && (int32_t)(millis() - vencimiento) >= 0) apagar();   // temporizador de seguridad
  // acá: recibir órdenes de la red y llamar a encender(...) o apagar()
}

El esqueleto reúne las defensas del tema: la salida arranca apagada, toda orden de encendido tiene un vencimiento, hay un límite duro de 30 minutos que ninguna orden puede superar, y hay una pausa mínima entre encendidos. La comparación (int32_t)(millis() − vencimiento) ≥ 0 es la forma segura de comparar instantes sin errores cuando el contador de milisegundos da la vuelta.

08 · Analogía con programación

Probar comandos sobre una red mala en Python

El programa simula miles de veces el mismo pedido: encender una bomba durante 10 minutos, con una orden de ENCENDER a los 0 s y una de APAGAR a los 600 s. Cada mensaje puede perderse con una probabilidad dada; si el servidor no recibe la confirmación, reintenta cada 30 segundos (hasta tres veces), lo que genera duplicados cuando la que se perdió fue la confirmación. El dispositivo implementa tres semánticas: conmutar, estado (fijar el estado) y temporizador (fijar el estado y apagarse solo 600 s después de recibir ENCENDER). Se evalúa el resultado a los 30 minutos y se cuenta cuántos ensayos salieron bien (bomba apagada al final y entre 9 y 11 minutos encendida), el promedio de minutos encendida y cuántas veces quedó encendida.

ENSAYOS = 2000
DURACION_S = 600        # se quiere la bomba encendida 10 minutos
FIN_S = 1800            # se evalúa el estado a los 30 minutos
REINTENTO_S = 30        # el servidor reenvía si no recibe confirmación
MAX_ENVIOS = 4          # el primer envío y hasta tres reintentos


class Aleatorio:
    def __init__(self, semilla=2024):
        self.estado = semilla

    def uniforme(self):
        self.estado = (self.estado * 1664525 + 1013904223) & 0xFFFFFFFF
        return self.estado / 4294967296


def llegadas(azar, perdida, reintentos):
    """Instantes en que el dispositivo recibe una copia de cada orden (ENCENDER a los 0 s, APAGAR a los 600 s)."""
    recibidas = []
    for orden, t0 in (("ON", 0), ("OFF", DURACION_S)):
        for k in range(MAX_ENVIOS if reintentos else 1):
            if azar.uniforme() >= perdida:                      # la orden llegó
                recibidas.append((t0 + REINTENTO_S * k + 1, orden))
                if azar.uniforme() >= perdida:                  # y la confirmación también llegó
                    break
    return sorted(recibidas)


def ejecutar(recibidas, semantica):
    encendida, desde, total, limite = False, 0, 0, None
    def cerrar(t):
        nonlocal encendida, total
        if encendida:
            total += t - desde
            encendida = False
    for t, orden in recibidas:
        if semantica == "temporizador" and encendida and limite is not None and limite <= t:
            cerrar(limite)
        if semantica == "conmutar":
            if encendida:
                cerrar(t)
            else:
                encendida, desde = True, t
        elif orden == "ON":
            if not encendida:
                encendida, desde = True, t
            if semantica == "temporizador":
                limite = t + DURACION_S
        else:
            cerrar(t)
    if semantica == "temporizador" and encendida and limite is not None and limite <= FIN_S:
        cerrar(limite)
    final_encendida = encendida
    cerrar(FIN_S)
    return total, final_encendida


def evaluar(semantica, perdida, reintentos):
    azar = Aleatorio()
    bien = encendidas = suma = 0
    for _ in range(ENSAYOS):
        total, quedo_on = ejecutar(llegadas(azar, perdida, reintentos), semantica)
        suma += total
        encendidas += quedo_on
        if not quedo_on and abs(total - DURACION_S) <= 60:
            bien += 1
    return 100 * bien / ENSAYOS, suma / ENSAYOS / 60, 100 * encendidas / ENSAYOS


print("semántica      pérdida  reintentos   correcto   minutos encendida   queda encendida")
for perdida in (0.1, 0.3):
    for reint in (False, True):
        for sem in ("conmutar", "estado", "temporizador"):
            ok, minutos, queda = evaluar(sem, perdida, reint)
            print(f"{sem:<13}  {perdida:>6.0%}   {'sí' if reint else 'no':<9} {ok:>8.1f} % {minutos:>14.1f} {queda:>14.1f} %")

Resultado con los valores iniciales. Con 10 % de pérdida y sin reintentos, «conmutar» sale bien en 82 % de los ensayos y deja la bomba encendida al final en 16,8 %; «fijar el estado» también 82 %, pero la deja encendida en 8,6 %; con temporizador, 0 %, aunque a costa de no encender nunca si se pierde ENCENDER. Con reintentos, «conmutar» empeora (80,7 % correctos, 18 % encendida) porque los duplicados invierten el estado, mientras que «fijar el estado» sube a casi 100 % y con temporizador a 100 %. Con 30 % de pérdida y reintentos, «conmutar» solo acierta en 56 % de los casos y deja la bomba encendida en 36 %; «fijar el estado», en 96 % con 0,7 % encendida; y con temporizador, 98 % y 0 %.

El modelo ilustra tres lecciones: los reintentos sin idempotencia empeoran las cosas; la semántica de estado más reintentos lo arregla casi todo; y el temporizador elimina el peor resultado, el actuador atascado en encendido, incluso cuando la red es muy mala.

09 · Exploración interactiva

¿Qué tan confiable es mi comando?, de extremo a extremo

Este laboratorio ejecuta el mismo modelo del código anterior, con los mismos 2000 ensayos. Elegí la semántica de la orden, la pérdida de mensajes de la red y si el servidor reintenta. Las barras celestes comparan las tres semánticas en el porcentaje de ensayos correctos; las rojas, en el porcentaje de veces que el actuador quedó encendido al final, el resultado peligroso. La semántica elegida va resaltada.

Recorrido guiado

1. Con los valores iniciales (temporizador, 30 % de pérdida, con reintentos), enviá. 98,4 % de ensayos correctos, 9,8 minutos de promedio y 0 % de veces encendida al final: «Confiable».
2. Cambiá a Conmutar con la misma red. Los ensayos correctos caen a 56,4 % y la bomba queda encendida en 36,4 % de los casos: «Peligroso». Los reintentos generan duplicados y cada duplicado invierte el estado.
3. Con Conmutar, elegí «No» reintentar: 48,3 % correctos. Con una red mala, «conmutar» no tiene salida: ni con reintentos ni sin ellos.
4. Pasá a Fijar el estado con reintentos: 96,2 % correctos. El duplicado no molesta. Pero queda encendida en 0,7 % de los casos: se perdieron los cuatro APAGAR.
5. Con Fijar el estado sin reintentos y 30 % de pérdida: 48,3 % correctos y la bomba queda encendida en 20,9 % de los casos. Es la peor falla posible: una bomba encendida sin que nadie la apague.
6. Con el temporizador y sin reintentos, la bomba nunca queda encendida (0 %), pero solo hay 69,2 % de éxito: si se pierde ENCENDER, simplemente no se enciende. «Falla en silencio», pero de forma segura.

10 · Método de trabajo

Cómo diseñar una salida remota

1. Definí el estado seguro del actuador y qué elemento del hardware lo garantiza si se corta la energía o el programa se cuelga.
2. Elegí el actuador y su circuito de excitación: transistor, MOSFET, relé o módulo; dimensioná las resistencias y agregá el diodo de rueda libre y el desacoplo.
3. Aislá lo que haga falta. Las cargas de red eléctrica, con módulos certificados y cajas aisladas.
4. Escribí los límites duros en el firmware: duración máxima, pausa mínima, protección térmica y de corriente.
5. Diseñá los comandos como fijación de estado, con duración o vencimiento, hora de emisión y autenticación.
6. Resolvé el arranque y la pérdida de red: pull-down, estado inicial seguro y qué hace el equipo sin contacto.
7. Informá el estado real y compará con el deseado; trata la discrepancia como falla.
8. Probá la falla: desconectá la red a mitad de una orden, cortá la energía, enviá comandos duplicados y vencidos. Una salida solo es confiable si resistió esas pruebas.

Una regla de oro final: pensá siempre qué pasa si la peor orden posible llega en el peor momento, y asegurate de que el dispositivo no pueda causar daño aunque la reciba.

11 · Comprensión

Confusiones frecuentes

12 · Práctica guiada

Predecí antes de comprobar

1. Resistencia de un LED

Un LED rojo (2,0 V de caída) se maneja desde un pin de 3,3 V con una corriente de 10 mA. ¿Qué resistencia corresponde y cuál elegirías entre los valores comunes 100, 150 y 220 Ω?

2. Excitar un relé

La bobina de un relé de 5 V consume 70 mA. Un transistor con ganancia mínima 100 la maneja desde un pin de 3,3 V (caída de la unión base-emisor: 0,7 V). Calculá la corriente de base mínima, una con margen de cinco veces y la resistencia de base.

3. Vida de un relé

Un relé soporta 100.000 operaciones. ¿Cuánto dura si el firmware lo conmuta una vez por minuto, y si lo conmuta cada 15 minutos?

4. Conmutar contra fijar el estado

El servidor envía «conmutar» y la confirmación se pierde, por lo que reenvía. ¿Qué pasa con la bomba? ¿Y si la orden fuera «bomba = encendida»?

5. Estado seguro

Indicá si una electroválvula «normalmente cerrada» o «normalmente abierta» conviene en: (a) un suministro de gas a un horno; (b) el agua de refrigeración de un equipo que se sobrecalienta sin ella.

6. Una orden con retraso

El dispositivo recibe «abrir la válvula 10 minutos» emitida 25 minutos antes, con una validez de 60 segundos. ¿Qué hace y qué informa?

13 · Síntesis

Ideas para recordar

¿Listo para el tema 12?

Antes de avanzar, elegí un actuador de tu casa que podría conectarse a la red (un calefactor, una bomba, una cerradura) y respondé: ¿cuál es su estado seguro?, ¿qué límite duro impondrías?, ¿cómo expresarías la orden para que tolere duplicados y pérdidas?, ¿cómo confirmarías que realmente actuó? Si tenés las cuatro respuestas, estás pensando como diseñador de sistemas conectados.

En el próximo tema cerramos el bloque con del sensor al mensaje: cómo se estructura una lectura (valor, unidad, marca de tiempo e identificador del dispositivo) para que viaje por la red sin perder su significado.