ESP32: Reloj con RTC interno, sincronización NTP y Deep Sleep

La idea de este post es aprender sobre tres temas interesantes y útiles del ESP32 que servirán mucho para proyectos actuales y futuros: el RTC, el modo Deep Sleep y la sincronización NTP.

Ya en un post anterior (servidor web con sensor DHT11) tocamos el tema de la sincronización con un servidor NTP, pero hoy vamos a utilizarlo de otra manera.

Qué nos proponemos:

1. Entender el RTC interno: Olvidarnos de módulos externos y aprender a usar el reloj que ya viene dentro del ESP32.
2. Sincronización NTP: Aprender a "preguntar" la hora a Internet para que nuestro reloj sea atómico.
3. Eficiencia con Deep Sleep: Entender cómo poner a dormir el chip para que la batería no se agote en un suspiro.
4. Modularización: Seguir practicando cómo separar el código en archivos para que sea limpio y profesional.
5. Solucionar problemas reales que nos encontramos durante la marcha y nos hacen desesperar y querer tirar todo a la basura: Aprender qué es el Time Drift y cómo ganarle la batalla.

Para este proyecto vamos a usar componentes que probablemente ya tengas en tu cajón de proyectos:

• ESP32: En mi caso uso un WEMOS D1 R32, pero cualquier ESP32 te sirve.
• Pantalla OLED SSD1306: La clásica (primera vez que la uso, pero uno la ve en todos lados ahora) de 128x64 píxeles que se conecta por I2C.
• Pulsador (Push Button): El que va a "despertar" a nuestro microcontrolador.
• Resistencia de 10kΩ: Fundamental para que el botón funcione correctamente (luego te explico por qué).
• Protoboard y cables.

Tabla de Conexiones

Si estás usando el WEMOS D1 R32, aquí tienes el mapa para no perderte. Si tenés otro modelo de ESP32, chequea bien los pines correspondientes. Es importante ubicar los pines SDA/SCL y algún pin marcado como RTC para el botón (push).

Componente	Pin del ESP32	Notas
OLED VCC	3.3V o 5V	Según tu modelo de pantalla
OLED GND	GND	Tierra
OLED SCL	GPIO 22	Reloj I2C
OLED SDA	GPIO 21	Datos I2C
Botón (Terminal 1)	3.3V	Entrada de voltaje
Botón (Terminal 2)	GPIO 27	Señal de entrada
Resistencia 10k	GPIO 27 a GND	Configuración Pull-down

Ojo con el botón: Es MUY importante conectar la resistencia entre el GPIO 27 y GND. Esto mantiene el pin en "bajo" (0V) mientras no tocamos el botón, evitando que el ruido eléctrico despierte al ESP32 por error.

1. ¿Qué es el RTC del ESP32?

El RTC (Real-Time Clock) es un módulo interno del chip capaz de mantener la fecha y la hora "con precisión" (más o menos..., veremos más adelante).

A diferencia de otros microcontroladores que nos obligan a comprar módulos externos (como el famoso DS3231), el ESP32 ya lo trae de serie. Como bien explican en Vasanza - RTC Interno, es vital para proyectos de data logging o riego automático. Eso sí, hay que tener en cuenta que si le quitamos la alimentación por completo, la hora se borra, por eso necesitamos "ayuda" externa para ponerlo en hora al principio.

2. Sincronización vía NTP

Para que nuestro reloj sea exacto, usamos el Network Time Protocol (NTP). Básicamente, es el lenguaje que usa el ESP32 para preguntarle a un servidor en Internet: "¿qué hora es exactamente?".

El ESP32 se conecta a servidores como pool.ntp.org mediante el puerto UDP 123. Es un proceso rápido, pero requiere que configuremos el GMT_OFFSET (para que sepa en qué país estamos) y el DAYLIGHT_OFFSET para el horario de verano. Si quieres profundizar en cómo sincronizarlo, te recomiendo este artículo sobre Sincronizar RTC.

3. Modos Sleep: ¿Cómo ahorrar batería?

Aquí es donde ocurre la magia. Si dejamos el ESP32 encendido a tope, consume unos 160-260 mA (variando un según modelos... en este caso estoy usando un WEMOS D1 R32 que no es el más ahorrador...), por eso usamos los modos de ahorro.

Según fuentes como Luis Llamas o Last Minute Engineers, el ESP32 tiene varios estados. Nosotros usaremos el Deep Sleep. En este modo, el CPU y el Wi-Fi se apagan por completo, pero —y aquí está el secreto— el módulo RTC se queda encendido. El consumo baja a unos increíbles 10 ~ 150 µA.

Para este proyecto, el ESP32 se despertará solo cuando pulsemos un botón (despertador externo GPIO).

---

El reto: El "Time Drift" (o por qué mi reloj se atrasa o se adelanta volviéndome loco)

Durante mis pruebas armando este proyecto me golpee la cabeza contra la pared durante un rato largo (por decir poco...). El oscilador interno del ESP32 no es perfecto. Sin un cristal de cuarzo externo de 32kHz, el reloj tiende a desviarse varios minutos en unas pocas horas.

¿La solución? En cada despertar, el código hace una sincronización NTP rapidísima. Así, aunque el reloj interno haya "derrapado" un poco mientras dormía, al mostrarte la hora siempre será la correcta. Admito que no era la idea original mientras armaba este proyecto, la idea era sincronizar una sola vez el RTC del ESP32 y luego (mientras se mantuviera conectado) leer siempre la información del mismo.

Estructura Modular

Como ya vimos en nuestro post sobre modularización, hemos separado el código en trocitos lógicos:

• wifi_connect: Para entrar y salir de Internet sin dramas.
• time_manager: El encargado de hablar con el NTP y ajustar el RTC.
• display_utils: El artista que dibuja en la pantalla OLED.

Ventajas de la encapsulamiento! Si mañana queŕes usar una pantalla distinta, solo cambias el archivo del display y el resto del proyecto sigue funcionando perfectamente.

Consejos finales para tu montaje

1. ¡Apaga el display! Muchos se olvidan de usar displayPowerOff() antes de dormir. Si el display se queda encendido, de nada sirve que el ESP32 esté en Deep Sleep; la batería adiós gracias.

2. Hardware: Usa una resistencia de 10kΩ en modo Pull-down para el botón del GPIO 27. Si no, "despertares fantasma" que te van a enloquecer.

3. Alimentación: Alimenta por el pin 5V/VIN para que el regulador de la placa haga su trabajo y proteja tu ESP32.

Como siempre, todo el código estará disponible en github: https://github.com/mcattani/reloj_esp32_rtc_ntp_dsleep

Espero que este post les haya interesado. Todos los comentarios son bienvenidos. Y si quieren, pueden invitarme un cafecito!

Separando archivos en Arduino y ESP: .ino, .h y .cpp

Cuando uno empieza a programar en Arduino o ESP, lo más común es trabajar con un único archivo .ino.

Eso funciona bien para ejemplos chicos y pruebas rápidas. El problema aparece cuando el proyecto empieza a crecer. “Modularizar” el código no solo es una buena práctica, sino que además nos da la gran ventaja de poder reutilizarlo de manera muy sencilla.

Para introducir este tema me pareció un buen ejemplo la conexión a WiFi, dado que es algo que utilizaremos bastante, sobre todo con los ESP.

1. El problema del .ino único

Un sketch típico suele empezar así:

#include <WiFi.h>

const char* ssid = "MiWiFi";
const char* password = "MiPassword";

void setup() {
  Serial.begin(115200);
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("Conectado!");
}

void loop() {
  // código principal
}

Al principio es claro y fácil de entender. El problema es que, con el tiempo, empiezan a aparecer:

• más configuraciones
• más funciones
• más lógica

Y el archivo .ino termina teniendo:

• código de WiFi
• código de red
• lógica de la aplicación
• configuraciones globales

Y todo esto puede dificultar la lectura del sketch, no escalar bien a medida que el proyecto crece e incluso hacer que reutilizar código termine siendo más costoso que volver a escribirlo.

2. El rol de cada archivo: .ino, .h y .cpp




Archivo .ino

• Punto de entrada
• Contiene setup() y loop()
• Orquesta el flujo general

Archivo .h

• Declara qué ofrece un módulo
• Define funciones, constantes y estructuras públicas
• Actúa como contrato

Archivo .cpp

• Implementa la lógica real
• Contiene los detalles internos

Resumen

El programa principal (.ino) tiene el programa, pero no las funciones que usa. Esas se definen en otro lado. El archivo .h trae las definiciones de las funciones y los parámetros que recibe y que devuelve, (pero no el código propiamente dicho) y nos permite ver que funciones tenemos disponibles para trabajar: Nos da la información precisa para usar las funciones del [archivo] .cpp - El fichero .cpp, tiene el código final de las funciones y aquí es donde podemos añadir o modificar funciones, siempre y cuando las definamos en el fichero .h

Fuente: https://www.prometec.net/organizando-tus-programas-arduino/

Archivo	Responsabilidad
.ino	Orquestación
.h	Interfaz
.cpp	Implementación

3. WiFi como módulo reutilizable

Para este ejemplo estaré usando un ESP32 (Wemos D1 R32)

La estructura de archivos será la siguiente:

/
├── main.ino
├── config.h
├── wifi_connect.h
└── wifi_connect.cpp

config.h

#pragma once

// WiFi
const char* WIFI_SSID = "TU_WIFI_AQUI";
const char* WIFI_PASSWORD = "TU_PASSWORD_AQUI";

// mDNS
const char* MDNS_NAME = "NOMBRE_DE_RED_AQUI";

En los lenguajes de programación C y C++, #pragma once es una directiva del preprocesador no estándar pero con un extenso soporte. Está diseñado para asegurar que el código fuente que lo invoca sea incluido una única vez. [...] Usando #pragma once en lugar de la protección de macros (también visto como protección de inclusiones (include) ) generalmente aumentará la velocidad de compilación puesto que es un mecanismo de nivel más alto.

Fuente: https://es.wikipedia.org/wiki/Pragma_once

wifi_connect.h

#pragma once
void conectarWiFi();

wifi_connect.cpp

#include <WiFi.h>
#include <ESPmDNS.h>
#include "config.h"
#include "wifi_connect.h"

void conectarWiFi() {
  Serial.println();
  Serial.print("Conectando a: ");
  Serial.println(WIFI_SSID);

  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);

  // Bucle mientras se conecta
  while (WiFi.status() != WL_CONNECTED) {
    delay(100);
    Serial.print(".");
  }

  // Conexión exitosa -> mostramos los datos de conexión
  Serial.println("");
  Serial.println("WiFi Conectado!");
  Serial.print("SSID: ");
  Serial.println(WiFi.SSID());
  Serial.print("IP asignada: ");
  Serial.println(WiFi.localIP());

  // mDNS
  if (!MDNS.begin(MDNS_NAME)) {  // Seteamos el hostname 
    Serial.println("Error iniciando mDNS");
    return;
  }

  // Mostramos los datos de mDNS
  Serial.print("mDNS iniciado: http://");
  Serial.print(MDNS_NAME);
  Serial.println(".local");
}

main.ino

#include "wifi_connect.h"

void setup() {
  Serial.begin(115200);
  // Llamamos a la función para conectar a WiFi
  conectarWiFi();
}

void loop() {}

4. Credenciales, .gitignore y repositorios públicos

Como vimos en el ejemplo de arriba, el archivo config.h contendrá las credenciales para la conexión (entre otras cosas) y debemos tener cuidado de no subir este archivo a nuestro repositorio.

Debemos siempre agregarlo al archivo .gitignore al crear nuestro repo. En su lugar podemos crear un archivo config_example.h por ejemplo y aclarar que el mismo debe renombrarse antes de subirse al microcontrolador.

// config_example.h
#pragma once

/* Renombrar este archivo a config.h
y completar con tus credenciales*/

// WiFi
const char* WIFI_SSID = "TU_WIFI_AQUI";
const char* WIFI_PASSWORD = "TU_PASSWORD_AQUI";

// mDNS
const char * MDNS_NAME = "NOMBRE_DE_RED_AQUI";

En conclusión, separar el código desde el inicio tiene sus ventajas:

• mejora la organización
• facilita el mantenimiento
• permite reutilizar módulos

Es una buena práctica a adquirir (ya sé que nunca lo hice hasta ahora...) e intentaré mantenerla para proyectos futuros.

Espero que este post les haya interesado. Como siempre, todos los comentarios son bienvenidos. Y si quieren, pueden invitarme un cafecito!