Bajo consumo en dispositivos conectados

01 · Consumir según la función

Energía y servicio del dispositivo

El tema 45 distinguió una unidad sin contacto de una unidad averiada. Un sensor a batería introduce otra situación: puede estar dormido por diseño. Para ahorrar energía hay que coordinar hardware, firmware, comunicación y expectativas de la plataforma.

Antes de elegir un modo de sueño, definí el servicio: cada cuánto se mide, cuánto puede demorar una alarma, cuándo se aceptan órdenes y cuánto tiempo se admite trabajar sin red. Una estación que informa humedad cada quince minutos tiene requisitos diferentes de una válvula que debe responder a una orden en un segundo.

Ahorrar energía no consiste solamente en reducir la frecuencia del procesador. A menudo conviene completar una tarea y apagar subsistemas cuanto antes. Se compara la carga total de cada alternativa, incluyendo arranques, esperas y reconexiones.

02 · Qué se apaga y qué se conserva

Activo, radio apagada y sueño

Los nombres y dominios de alimentación dependen del microcontrolador. Esta comparación toma como referencia el ESP32 clásico; otras variantes de la familia tienen diferencias en memoria, pines y fuentes de despertar.

La documentación de sueño de ESP-IDF para ESP32 explica los dominios y fuentes de despertar. El deep-sleep no conserva una conexión Wi-Fi o Bluetooth. El light-sleep explícito tampoco la mantiene por sí solo; para conservarla se utiliza la integración de ahorro del controlador, como modem-sleep y light-sleep automático, con sus requisitos de gestión de energía.

Una espera no garantiza sueño profundo

delay() cede ejecución durante un tiempo. No expresa por sí mismo una política de apagado de radio, periféricos y alimentación. El sistema podría aplicar otras optimizaciones si está configurado para ello, pero una pausa en el programa no demuestra que la placa haya alcanzado su consumo de sueño.

Desconectar Wi-Fi tampoco apaga el regulador, el sensor o el LED de alimentación. Separá las decisiones de software del resultado eléctrico que vas a medir.

03 · Del arranque al próximo despertar

Diseñar el ciclo de trabajo

DESPERTAR → INICIALIZAR → MEDIR → PROCESAR
                                  ↓
                       ¿corresponde transmitir?
                           sí ↓          ↓ no
                 CONECTAR CON PLAZO       |
                 ENVIAR / CONFIRMAR       |
                           ↓              |
                 APAGAR RADIO ←───────────┘
                           ↓
             GUARDAR LO NECESARIO → DORMIR

Cada estado tiene una condición de salida y un plazo. Si no hay red, el equipo conserva lo necesario y duerme según su política. Quedarse esperando indefinidamente transforma una falla de cobertura en una descarga de batería.

Período completo y duración del sueño

El período es el tiempo entre inicios consecutivos del ciclo. Incluye la actividad. Si se requieren ciclos de 60 segundos y el trabajo demora 6, quedan 54 segundos para dormir. Si se programa siempre un sueño de 60 segundos, el período real será de unos 66, más las demoras no contabilizadas.

Si la actividad supera el período objetivo, el cronograma es inviable. No se corrige convirtiendo el sueño negativo en cero y mostrando un resultado aparentemente normal: hay que cambiar el trabajo, los plazos o el período.

Dormir cambia el contrato con la nube

Una unidad profundamente dormida no recibe inmediatamente una orden de red. Se puede consultar trabajo pendiente al despertar, abrir una ventana de recepción o usar un gateway apropiado. La latencia depende del protocolo y de esas ventanas, no de que el backend haya guardado el estado deseado.

El monitoreo debe conocer la cadencia esperada y su tolerancia. Publicar «voy a dormir» ayuda al contexto, pero no prueba un despertar futuro. Al superar el plazo esperado sin evidencia, la plataforma vuelve a clasificar el contacto según su política.

04 · Sumar lo que ocurre durante todo el ciclo

Presupuesto de corriente y carga

Para cada etapa se registra la corriente media y su duración. Todas las corrientes deben estar referidas al mismo punto de alimentación. En este ejemplo son corrientes equivalentes en la entrada de batería del dispositivo completo; no se mezclan consumos del chip a 3,3 V con capacidad de una batería a otra tensión.

La carga por ciclo es 0,14936 mAh; la corriente promedio, 8,9617 mA; el consumo diario, 215,08 mAh. Aunque el equipo duerme el 90 % del tiempo, la radio aporta aproximadamente el 89,27 % de la carga del ciclo.

Promedio y pico responden preguntas distintas

El promedio ayuda a estimar duración. Los picos condicionan si la batería, el regulador y las conexiones sostienen la tensión durante una transmisión. Un promedio de 9 mA no significa que alcance una fuente capaz de entregar solo 9 mA.

Dentro de cada etapa, la corriente real cambia. Los 120 mA de radio representan un promedio ficticio que incluye sus ráfagas; no un límite máximo. Para un perfil medido se integra la corriente en el tiempo y se obtiene la carga con mayor detalle.

05 · Una estimación con hipótesis explícitas

De la batería a la autonomía

La capacidad nominal se especifica bajo ciertas condiciones de descarga, temperatura y tensión de corte. Parte puede no ser utilizable por el producto. El modelo usa un factor de capacidad utilizable elegido por el alumno; no representa una constante universal ni sustituye la caracterización de la batería.

Con 2000 mAh nominales y factor 0,8 hay 1600 mAh presupuestados. Para el ciclo anterior resultan 178,54 horas, unos 7,44 días. Esa cifra describe el modelo. No incluye explícitamente autodescarga, variaciones de cobertura, envejecimiento ni eventos extraordinarios como una descarga OTA.

Cuando cambian las tensiones, trabajá con energía

Si la corriente se midió del lado de una carga regulada, el cálculo directo con los mAh de la batería puede ser incorrecto. Para tensiones aproximadamente constantes se puede trabajar en Wh y W, incorporando la eficiencia del convertidor:

La eficiencia depende de la carga y puede cambiar mucho en reposo. Si ya mediste la corriente total en la batería, las pérdidas del regulador están incluidas: no las vuelvas a sumar. Del mismo modo, elegí qué cubre el factor utilizable para evitar descontar dos veces la misma pérdida.

El límite de extender el intervalo

Con el mismo trabajo cada 600 segundos, el promedio del ejemplo baja a 0,9412 mA y la estimación sube a 70,83 días. Al espaciar todavía más los ciclos, el consumo de sueño adquiere mayor peso. La autodescarga y las fugas pueden terminar dominando: extender el período no produce autonomía ilimitada.

06 · La conexión también cuesta

Radio, lotes y reintentos

Enviar pocos bytes puede exigir encender el módem, buscar red, asociarse, obtener configuración IP, resolver DNS, establecer TLS y autenticar la aplicación. El costo del mensaje incluye esas etapas, sus esperas y la confirmación requerida por el servicio.

Agrupar lecturas

Se puede medir cada minuto y transmitir diez muestras juntas cada diez minutos. Se amortiza parte de la conexión, pero aumenta la demora de entrega y se necesita almacenamiento. No equivale exactamente al ciclo de 600 segundos del laboratorio: allí también se mide una sola vez por ciclo. Para modelar lotes hay que sumar los diez despertares y las diez mediciones, además del tamaño de envío.

Los temas 31 a 35 aportan filtrado, eventos y almacenamiento. Descartar ruido o resumir una ventana puede ahorrar tráfico, siempre que conserve la información que necesita el usuario. Una alarma puede justificar un envío anticipado y consumir parte de una reserva energética.

Un presupuesto para la falla de red

Definí máximo de intentos, plazo de conexión, plazo total activo y espera entre ciclos fallidos. Un backoff que mantiene CPU y radio encendidas también consume. Si el producto lo admite, parte de esa espera puede transcurrir dormido.

En el laboratorio, cada intento extra agrega otro bloque completo de 4 segundos a 120 mA y reduce el sueño dentro del mismo período. Es una simplificación conservadora del recorrido, sin backoff adicional ni probabilidad de éxito. Un intento fallido real puede durar más o menos que uno exitoso: se mide y se incorpora su perfil.

La seguridad forma parte del presupuesto: se contabiliza TLS y se conserva la validación de certificados. Bajar el consumo requiere optimizar la política de comunicación y el hardware, manteniendo las comprobaciones de identidad.

07 · El chip no es el producto completo

El consumo de toda la placa

Un valor de deep-sleep de la hoja de datos suele corresponder al circuito integrado y a una configuración concreta. Una placa de desarrollo agrega regulador, conversor USB-serie, LEDs, resistencias y sensores. El total puede superar ampliamente al del chip dormido.

Por ejemplo, un divisor de 100 kΩ en total conectado permanentemente a 3,3 V toma 33 µA. Puede ser significativo junto a un sueño de 50 µA. Aumentar resistencias o conmutar el divisor exige comprobar impedancia de entrada del ADC, tiempo de establecimiento y precisión.

Apagar un sensor requiere revisar sus señales

Un periférico sin alimentación puede recibir corriente por sus entradas si la CPU mantiene una señal alta. Se revisan las hojas de datos y se diseña la conmutación y el estado de los pines. También se evita que una salida quede flotante y active accidentalmente una carga.

El sueño debe respetar el estado físico seguro del producto. Un actuador que necesita alimentación sostenida puede dominar todo el presupuesto; dormir el procesador no elimina ese consumo.

08 · Retomar una tarea con contexto válido

Despertar y conservar contexto

El temporizador permite un despertar periódico sin una conexión activa. Otra opción es una señal externa admitida por el chip y el modo: un pulsador, un sensor con interrupción o un circuito de detección. Las fuentes y pines compatibles se consultan para el modelo exacto.

Una fuente por nivel que sigue activa al volver a dormir puede causar despertares inmediatos. Se atiende la causa, se limpia la condición y se comprueba el nivel antes de rearmar. Los rebotes o el ruido pueden generar ciclos repetidos y gastar la batería.

Qué recordar entre ciclos

En deep-sleep la RAM ordinaria no conserva el contexto de ejecución. En ESP32 se puede usar memoria RTC para algunos datos retenidos, bajo las condiciones de alimentación y configuración de ese dominio. No equivale a almacenamiento persistente ante una pérdida de energía.

Un contador retenido sirve para correlacionar despertares, pero necesita una política al perder alimentación. Para mediciones pendientes se elige una cola con tamaño máximo y política de descarte. Persistir cada detalle en flash también cuesta energía, tiempo y desgaste.

Los certificados, claves y configuraciones siguen la política de los temas anteriores. El reloj y la referencia temporal requieren atención después del sueño o de un corte; un contador de despertares no reemplaza la fecha necesaria para validar certificados ni una identidad de sesión robusta.

09 · Un recorrido mínimo en hardware

Ejemplo de sueño profundo en ESP32

Este sketch para Arduino-ESP32 en ESP32 clásico muestra arranque, contador RTC, intento Wi-Fi acotado, apagado de radio y despertar por temporizador. No instala un sensor ni publica telemetría. La adquisición y el envío real deben agregarse con sus propios plazos y confirmaciones antes de dormir.

Dejá SSID vacío para probar solamente sueño y despertar. Si configurás una red de laboratorio, la asociación espera como máximo unos 8 segundos en el bucle de consulta. No es un límite duro de todo el arranque: inicialización, llamadas al controlador y salida serie agregan tiempo.

#include <Arduino.h>
#include <WiFi.h>
#include "esp_sleep.h"

constexpr char SSID[] = "";  // Red de laboratorio, opcional
constexpr char CLAVE[] = "";
constexpr uint32_t PLAZO_WIFI_MS = 8000;
constexpr uint64_t SUENO_S = 60;
RTC_DATA_ATTR uint32_t despertares = 0;

void setup() {
  Serial.begin(115200);
  ++despertares;
  Serial.printf("Ciclo %lu; causa de despertar: %d\n",
                (unsigned long)despertares,
                (int)esp_sleep_get_wakeup_cause());

  // Aquí: inicializar sensor, esperar estabilización y medir.
  // Esta demostración no produce una lectura real.
  if (SSID[0] != '\0') {
    WiFi.mode(WIFI_STA);
    WiFi.setAutoReconnect(false);
    WiFi.begin(SSID, CLAVE);
    const uint32_t inicio = millis();
    while (WiFi.status() != WL_CONNECTED &&
           (uint32_t)(millis() - inicio) < PLAZO_WIFI_MS) {
      delay(50);
    }
    if (WiFi.status() == WL_CONNECTED) {
      Serial.println("Wi-Fi asociado; no se envió telemetría.");
      // Aquí: TLS y envío con plazos, validación y confirmación.
    } else {
      Serial.println("Sin asociación; terminar el ciclo y dormir.");
      // Aquí: guardar lectura pendiente según la política del producto.
    }
  }

  // No se inició Bluetooth. Si se usa, también debe detenerse.
  WiFi.mode(WIFI_OFF);
  // Aquí: apagar sensores y fijar estados seguros de las salidas.
  const esp_err_t error = esp_sleep_enable_timer_wakeup(
      SUENO_S * 1000000ULL);
  if (error != ESP_OK) {
    Serial.println("No se pudo armar el temporizador de sueño.");
    // Error de configuración: evitar un bucle rápido de reinicios.
    while (true) { delay(1000); }
  }
  Serial.println("Dormir 60 segundos a partir de este punto.");
  Serial.flush();
  esp_deep_sleep_start();  // El próximo despertar vuelve a setup().
}

void loop() {
  // No se alcanza después de entrar correctamente en deep-sleep.
}

1000000ULL convierte segundos a microsegundos con aritmética de 64 bits. El temporizador se arma antes de entrar en sueño. El intervalo solicitado tiene precisión y deriva dependientes del reloj RTC; no constituye un calendario exacto.

El período de este sketch es actividad + 60 segundos de sueño. En cambio, el laboratorio fija el período completo y calcula el sueño restante. Para una cadencia fija, medí el tiempo activo y descontalo del período; si ya se agotó, registrá el incumplimiento y aplicá una política explícita.

El contador RTC puede sobrevivir al deep-sleep, pero no se usa como garantía de persistencia ante un corte. El manejo del error del temporizador deja el equipo despierto para diagnóstico: en un producto se define además la recuperación apropiada y su costo.

Compará el recorrido con el ejemplo oficial TimerWakeUp de Arduino-ESP32 y verificá la placa y versión del core que uses. Los valores del presupuesto de esta lección no se deducen de ejecutar este sketch.

10 · Convertir una hipótesis en evidencia

Medir y verificar

1. Elegí el punto de medida: preferentemente la entrada de batería si querés conocer el sistema completo. Anotá tensión, placa, firmware y periféricos.
2. Eliminá caminos alternativos: el USB o un programador pueden alimentar parte del circuito y falsear el resultado. Prepará también un método de recuperación y programación.
3. Capturá un ciclo completo: arranque, sensor, asociación, envío, espera de confirmación, apagado y sueño.
4. Integrá carga: registrá duración y corriente media de cada etapa; identificá también los picos y la caída de tensión.
5. Repetí con fallas: red ausente, señal débil, servidor lento, credencial rechazada, reinicio y fuente de despertar activa.
6. Probá mantenimiento: OTA, diagnóstico y renovación de credenciales, con una reserva de energía y una política de batería baja.
7. Compará con el presupuesto: corregí tiempos, corrientes y capacidad utilizable; comprobá los requisitos de latencia y pérdida de datos.

Elegir una herramienta que vea el fenómeno

Un multímetro puede ayudar a observar un reposo estable, pero su actualización puede ocultar ráfagas de radio. Un analizador de potencia o un shunt con adquisición adecuada permite ver el perfil. El rango debe cubrir tanto microamperios de reposo como picos de actividad sin introducir una caída de tensión que reinicie el circuito.

La resistencia interna de medida y los cambios de rango pueden alterar el comportamiento. Verificá la tensión en la placa durante la transmisión. Un reinicio repetido puede ser una limitación de alimentación o del montaje de medida, además de un posible error de firmware.

11 · Un cálculo reproducible

Modelo ejecutable en Python

El modelo reproduce el laboratorio: arranque de 1 s a 40 mA, medición de 1 s a 15 mA y uno o más intentos de radio a 120 mA. La corriente de sueño representa el dispositivo completo medido en batería. El período es fijo y una combinación que no entra se rechaza.

Podés copiar el código a Python 3 o ejecutarlo aquí. El botón descarga Pyodide la primera vez; el cálculo no contacta equipos ni consulta una nube.

from math import isfinite, isclose


def estimar(periodo=60, radio_s=4, extras=0, sueno_ma=0.05,
            capacidad=2000, utilizable=0.8):
    valores = (periodo, radio_s, sueno_ma, capacidad, utilizable)
    if any(type(v) not in (int, float) or not isfinite(v)
           for v in valores):
        raise ValueError("Se requieren números finitos")
    if (periodo <= 0 or radio_s <= 0 or sueno_ma < 0
            or capacidad <= 0 or not 0 < utilizable <= 1):
        raise ValueError("Magnitudes fuera de rango")
    if type(extras) is not int or not 0 <= extras <= 10:
        raise ValueError("Intentos extra: entero entre 0 y 10")

    tiempo_radio = radio_s * (1 + extras)
    activo = 2 + tiempo_radio
    if activo > periodo:
        raise ValueError("La actividad supera el período")
    sueno = periodo - activo
    etapas = [
        ("Arranque", 40, 1),
        ("Medición", 15, 1),
        ("Radio", 120, tiempo_radio),
        ("Sueño", sueno_ma, sueno),
    ]
    carga_mas = sum(i * t for _, i, t in etapas)
    promedio = carga_mas / periodo
    return {
        "etapas": etapas,
        "sueno_s": sueno,
        "activo_pct": 100 * activo / periodo,
        "ciclo_mah": carga_mas / 3600,
        "promedio_ma": promedio,
        "diario_mah": promedio * 24,
        "dias": capacidad * utilizable / (promedio * 24),
        "radio_pct": 100 * 120 * tiempo_radio / carga_mas,
    }


for nombre, opciones in [
    ("Base", {}),
    ("Cada diez minutos", {"periodo": 600}),
    ("Sueño de placa de 5 mA", {"sueno_ma": 5}),
    ("Dos intentos extra", {"extras": 2}),
    ("Radio más breve", {"radio_s": 1}),
]:
    r = estimar(**opciones)
    print(f"{nombre}: {r['promedio_ma']:.4f} mA; "
          f"{r['dias']:.2f} días; sueño {r['sueno_s']:.0f} s")

base = estimar()
assert isclose(base["promedio_ma"], 537.7 / 60)
assert isclose(base["ciclo_mah"], 537.7 / 3600)
assert base["sueno_s"] == 54
assert estimar(periodo=600)["promedio_ma"] < base["promedio_ma"]
assert estimar(extras=2)["sueno_s"] == 46
assert estimar(extras=2)["dias"] < base["dias"]
assert estimar(sueno_ma=5)["dias"] < base["dias"]
assert isclose(estimar(capacidad=4000)["dias"], 2 * base["dias"])
assert estimar(periodo=6)["sueno_s"] == 0
assert estimar(sueno_ma=0)["promedio_ma"] > 0

rechazos = [
    {"periodo": 5}, {"periodo": 0}, {"radio_s": 0},
    {"sueno_ma": -1}, {"capacidad": 0}, {"utilizable": 1.1},
    {"extras": 0.5}, {"extras": True}, {"periodo": float("nan")},
]
for opciones in rechazos:
    try:
        estimar(**opciones)
    except ValueError:
        pass
    else:
        raise AssertionError(f"Debía rechazar: {opciones}")
print("Comprobaciones superadas. Estimación didáctica, no medición.")

Se comprueban carga, tiempos, efecto de reintentos y límites. Un sueño de cero segundos es matemáticamente válido, aunque ya no hay descanso entre ciclos; una duración negativa se rechaza.

12 · Cambiar una variable y explicar el resultado

Laboratorio de autonomía

Los controles recalculan el presupuesto. Arranque y medición son fijos; la radio incluye un intento inicial y los extras indicados. No se simula una probabilidad de entrega. Todos los valores son ficticios y se refieren a la entrada de batería.

Recorrido guiado

1. Con los valores iniciales verificá 54 s de sueño, 8,9617 mA promedio y unos 7,44 días. El tiempo activo es 10 %, pero la radio consume cerca de 89,27 % de la carga.
2. Cambiá el período a 600 s. La actividad sigue durando 6 s y la estimación pasa a unos 70,83 días. También aumenta la demora posible hasta la próxima comunicación.
3. Conservá 600 s y subí el sueño a 5 mA, representando una placa con consumo permanente alto. Observá cómo el reposo domina la carga y limita el ahorro.
4. Restaurá el ejemplo y elegí dos intentos extra. Hay 12 s de radio, 46 s de sueño y unos 2,67 días de autonomía. Los intentos no garantizan entrega.
5. Restaurá y bajá la duración de radio a 1 s. Compará el ahorro con reducir solamente el sueño de 0,05 a 0,01 mA. En este escenario conviene investigar primero la etapa de radio.
6. Restaurá y fijá el período en 5 s. El cronograma se rechaza: hacen falta 6 s de actividad. Con 6 s es válido, pero no queda sueño.
7. Dejá vacío un campo o poné una capacidad utilizable mayor que 100 %. La vista oculta los resultados anteriores y explica el error; no muestra cifras que parezcan corresponder a entradas inválidas.

13 · Práctica guiada

Predecí antes de comprobar

1. Dormir no es fijar el período

Una medición y su envío demoran 7 s. Después se programan 300 s de sueño. ¿Cuál es el período aproximado? ¿Cuánto debería dormirse para un período de 300 s?

2. Corriente promedio de dos estados

Un equipo toma 100 mA durante 2 s y 0,1 mA durante 98 s. Calculá su promedio y su carga por ciclo.

3. Autonomía estimada

Con el promedio anterior, batería de 1000 mAh y factor utilizable de 0,75, ¿cuántos días estima el modelo?

4. Una conexión que nunca termina

El punto de acceso desaparece y el firmware espera hasta conectarse. ¿Qué requisito falta?

5. Una placa que consume más que el chip

La CPU entra en deep-sleep, pero se miden varios mA en batería. ¿Qué revisarías?

6. Una orden durante el sueño

El backend guarda una orden mientras el dispositivo permanece diez minutos en deep-sleep. ¿Puede prometerse ejecución inmediata?

7. El error de las tensiones

Se midieron 20 mA a 3,3 V en la salida de un convertidor alimentado por una batería de distinta tensión. ¿Se divide directamente su capacidad en mAh por 20 mA?

8. El pico que reinicia

La autonomía calculada es suficiente, pero cada transmisión reinicia el equipo. ¿El promedio demuestra que la alimentación es adecuada?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 47?

Antes de avanzar, armá una tabla con estados, corrientes, tiempos y punto de medida de tu dispositivo. Explicá qué ocurre sin cobertura, cómo recibe órdenes, qué conserva al dormir y cómo medirías la autonomía sin confundir promedio con pico.

En el próximo tema, Diseño de un dispositivo IoT completo, integramos hardware, firmware, comunicación, seguridad y mantenimiento en una misma arquitectura.