Actualización del firmware de la miniestación meteorológica, añadiendo la previsión del tiempo y salida/puesta del sol. El firmware puede compilarse tanto para ESP8266 como para ESP32 utilizando el IDE de Arduino. Incluye autodetección de librerías y configuración automática según el microcontrolador. Explicación del tiempo UNIX, Epoch y timestamp. Funcionamiento del protocolo NTP y problema del año 2038 (Y2038).
Estación Meteorológica NTP con ESP: reloj sincronizado por NTP y estado del tiempo local
Origen de los servidores horarios y el tiempo UNIX
En los sistemas informáticos y de telecomunicaciones, mantener la coherencia temporal entre dispositivos distribuidos geográficamente es esencial. Desde los años 60, con la expansión de redes y sistemas electrónicos interconectados, surgió la necesidad de una referencia temporal común y precisa.
Para resolver este problema se estableció el Tiempo Universal Coordinado (UTC) y se creó el concepto de epoch UNIX, una referencia absoluta desde la cual se mide el tiempo en segundos.
El epoch UNIX comienza el 1 de enero de 1970 a las 00:00:00 UTC. Desde ese momento, el tiempo se mide como el número de segundos transcurridos, conocido como timestamp UNIX.
Por ejemplo:
1700000000 (timestamp UNIX) → 14/11/2023 06:13:20 UTC
Este formato simplifica el cálculo de diferencias horarias, conversiones y sincronizaciones entre sistemas. Es utilizado por la mayoría de los sistemas operativos modernos, bases de datos y servidores.
El NTP (Network Time Protocol) fue desarrollado en 1985 por David Lennox Mills. Es un protocolo que permite sincronizar los relojes de los dispositivos conectados a Internet con una precisión de milisegundos, consultando servidores jerárquicos (llamados stratum). Los servidores NTP de alto nivel (stratum 1) están directamente conectados a relojes atómicos o señales GPS.
Un esquema simplificado del funcionamiento de NTP sería:
Los microcontroladores (ESP32, ESP8266) utilizan esta infraestructura para sincronizar su hora local mediante bibliotecas que interpretan y corrigen el timestamp UNIX recibido.
La conversión entre UTC y hora local depende del desplazamiento horario y de la aplicación de horario de verano. El desplazamiento se expresa en segundos (por ejemplo, +3600 segundos para UTC+1).
localTime = utcTime + timezoneShift;
Problema del año 2038 (Y2038)
El problema del año 2038 (Y2038) es un fallo de desbordamiento de la representación de tiempo en sistemas que almacenan la marca temporal (timestamp) como un entero con signo de 32 bits que cuenta los segundos desde el 1 de enero de 1970 00:00:00 UTC (tiempo Unix). Este entero alcanzará su valor máximo el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el valor se desbordará y provocará comportamientos erróneos en sistemas que no gestionen correctamente el desbordamiento.
Causa del problema
El tipo de dato ‘time_t’ se utiliza ampliamente en sistemas Unix y en lenguajes como C y C++ para representar tiempos. En arquitecturas de 32 bits, ‘time_t’ se implementa como un entero con signo de 32 bits, cuyo rango es de -2.147.483.648 a 2.147.483.647. Este último valor corresponde exactamente al 19 de enero de 2038 a las 03:14:07 UTC. Al sumarse un segundo más, el valor se desborda y se convierte en negativo, lo que produce fechas incorrectas (por ejemplo, en 1901) o fallos del sistema.
Escenarios de fallo típicos
- Logging: marcas de tiempo incorrectas en los registros.
- Expiración de credenciales o tokens errónea.
- Jobs programados que fallan o se ejecutan en el pasado.
- Bases de datos con índices temporales incorrectos.
- Dispositivos embebidos en bucles de reinicio por errores de tiempo.
ESP_NTP_Weather (v1.14)
En esta actualización se ha priorizado el mantener la compatibilidad con el ES8266, teniendo que realizar algunos procesos mucho más elaborados de los que se requieren con el ESP32. Aunque el ESP32 puede manejar JSON completos con facilidad, el objetivo del proyecto era mantener compatibilidad total con ESP8266.
El ESP8266 tiene una memoria RAM reducida (≈40 KB disponibles), lo que impedía almacenar la respuesta JSON completa del forecast, que supera fácilmente los 15–25 KB.
Problemas detectados:
- Fragmentación del buffer al intentar usar ArduinoJson.
- Reinicios por Watchdog al manipular cadenas grandes.
- Pérdida de datos cuando el parsing se hacía de forma secuencial.
Solución:
La solución que adopté al final fue realizar la lectura por streaming, procesando el JSON “en bruto” mediante búsqueda de fragmentos relevantes con indexOf() y extracción manual. Con este método se redujo en gran medida el uso de memoria, pero a cambio este método requiere una lógica mucho más precisa y sensible a errores. Utilicé un sistema de ventanas dinámicas, relocalizando la búsqueda y “recortando” el buffer cuando superaba cierto tamaño, manteniendo solo la región útil y sincronizando la búsqueda, usando el campo dt_txt como “ancla”.
Utilizando ‘OpenWeatherMap’
Descargar el firmware
Puedes descargar de forma gratuita el firmware, accediendo al siguiente enlace: ESP_WeatherClock_NTP
¿Dónde fabricar el PCB?
Actualmente hay muchas empresas que se dedican a fabricar circuitos impresos, pero no en todas podemos conseguir pequeñas tiradas a buen precio. Por suerte, ahora disponemos de Internet y es mucho más fácil que antes. Podemos buscar empresas en cualquier parte del mundo, y es más fácil encontrar un fabricante que haga nuestros prototipos (PCB) a buen precio. Una de las empresas más grandes del sector es PCBWay.
