Semana del 27 de abril al 3 de mayo de 2026

Resumen: Una semana muy productiva en la que el satélite Meteosat ha ganado tres nuevas capas de análisis, los gráficos de clima futuro han corregido un sesgo importante frente a ERA5, el pipeline de previsión se ha vuelto mucho más resistente con nuevas fuentes de datos, y el sistema de vigilancia automática ha recibido varias correcciones críticas.

🛰️ Meteosat MTG: nuevas capas para el streaming

Esta semana he añadido tres nuevas capas de satélite al pool de vídeos que alimentan el directo. La primera es Water Vapor 6.2 μm (vapor de agua en capas medias y altas de la troposfera), que complementa al infrarrojo ya disponible y es especialmente útil para ver la dinámica de las masas de aire antes de que llegue la nube. La segunda es Fog/Stratus RGB, una composición en color que detecta nieblas de radiación y estratos bajos: muy pertinente en primavera, cuando las mañanas de niebla en el interior son frecuentes.

Empecé con una tercera capa de microfísica de nubes de día (Microphysics RGB), pero la descarté rápidamente: de noche el resultado quedaba completamente blanco y de día era demasiado parecido a la capa Fog, así que no aportaba nada diferente. La sustituí por el Índice de Lifted Index (inestabilidad convectiva global), que sí tiene personalidad propia y es muy relevante en primavera para anticipar tormentas. Esta última capa incluye algunas mejoras visuales respecto al patrón habitual: fondo gris neutro en zonas sin dato, leyenda oficial descargada directamente del servidor WMS de EUMETSAT y pegada en la esquina inferior, y contornos geográficos engrosados para mejorar la legibilidad.

🌡️ Clima futuro: sesgo ERA5 corregido en las proyecciones CMIP6

Los gráficos que muestran cómo puede evolucionar la temperatura máxima de verano en distintos escenarios CMIP6 tenían un error que he tardado varios intentos en localizar. La causa era sutil: para calcular el sesgo histórico usaba la temperatura media diaria de ERA5, que en verano ronda los 24 °C en la Península, pero los modelos CMIP6 trabajan con la temperatura máxima (tasmax), que se acerca a los 30 °C. El resultado era un sesgo ficticio de entre 6 y 8 grados negativos aplicado a todas las ciudades, haciendo que las proyecciones parecieran más frescas de lo que realmente indican los modelos.

La solución fue cambiar el producto ERA5 descargado: en lugar de la media diaria, ahora descargo la media mensual a las 14:00 UTC (16:00 hora local CEST, el momento de máxima temperatura del día). Es un proxy fiable de la tasmax sin necesidad de descargar series de datos diarias, que serían mucho más pesadas. Aprovecho también para añadir al final del vídeo un frame de pausa de 4 segundos con una caja de estadísticas en la esquina: temperatura estimada hoy (2026), y las proyecciones para 2050, 2075 y 2100 con el delta respecto a hoy, coloreado en naranja si el incremento es menor de 3 °C y en rojo si supera ese umbral.

Por otro lado, la tarea programada que descarga los datos CAMS de primavera (pólenes, UV) ha cambiado su hora de disparo de las 8:00 a las 12:00. El motivo es que el run 00Z de CAMS no termina de publicarse hasta las 8:00-10:00 UTC, así que a las 8:00 hora local (6:00 UTC) el dato nunca estaba disponible y el script siempre caía al día anterior.

🔮 Previsión más robusta: AEMET XML + Open-Meteo + mejor fallback

El script que construye el texto de previsión diaria (previsioavui.py) ha recibido una revisión importante. Hasta ahora dependía del boletín nacional de AEMET en formato OpenData, que durante períodos de tiempo estable puede no actualizarse durante días (el del 27 de abril aguantó hasta el 2 de mayo sin renovarse). Ahora hay un Nivel 0 nuevo: la API api-eltiempo de AEMET, que publica los meteorólogos manualmente cada día en XML y no requiere clave de acceso. La cadena completa de fallback queda así: XML api-eltiempo → boletín nacional OpenData (≤2 días de antigüedad) → boletines de las 17 CCAA concatenados → datos de las 52 capitales de provincia → boletín nacional aunque sea viejo. Siempre habrá algo con lo que trabajar.

Además he creado un nuevo script, previ_openmeteo.py, que descarga el modelo ECMWF IFS de Open-Meteo (sin API key, con caché diario) para diez zonas representativas de España: Galicia, Cantábrico, País Vasco/Pirineos, Meseta Norte, Madrid/Centro, Cataluña, Mediterráneo, Andalucía, Baleares y Canarias. El gpt_redactor.py incorpora ahora este fichero como fuente suplementaria de datos numéricos frescos, de modo que aunque el boletín AEMET lleve días sin actualizarse, GPT siempre tendrá valores concretos de temperatura, viento y precipitación con los que redactar.

🤖 Watchdog y automatización: muchos flecos resueltos

El sistema de vigilancia automática (watchdog.py) tenía tres fallos encadenados que impedían la auto-reparación. El primero era un UnicodeEncodeError al intentar escribir ciertos caracteres en el log de Windows. El segundo, que el tiempo de espera para verificar si un script se había recuperado (180 segundos) era demasiado corto: las descargas de Copernicus y ECMWF pueden tardar más de tres minutos. Subí el límite a 600 segundos. El tercero es que durante esa espera el indicador de estado dejaba de latir, lo que hacía que el propio watchdog pareciera muerto. Ahora actualiza su heartbeat en cada comprobación. Como añadido, hay un nuevo indicador visual: una ventanita de 20×20 píxeles siempre visible en la esquina inferior derecha de la pantalla que cambia de color (verde = vivo, amarillo = fallo detectado, rojo = watchdog caído) y abre el log al hacer clic.

En el apartado de streaming también hubo que apagar varios incendios. El token OAuth de YouTube para actualizar el stream había caducado (Google lo revoca si el proyecto OAuth lleva más de 7 días en modo «prueba») y fue necesario renovarlo manualmente. Los scripts de reinicio del stream y del OBS tenían problemas de codificación de caracteres en Windows que causaban fallos silenciosos. Y como nota curiosa de la semana, he creado mapflow_analysis.py: un script que analiza con optical flow RAFT (GPU, PyTorch) los vídeos del panel de mapas y genera un resumen en texto (velocidad, dirección dominante, zona más activa) usando Ollama local con el modelo Qwen 2.5. La salida alimenta al redactor automático como contexto adicional.

🧪 Lo que ha quedado en el tintero

previsioavui.py – parámetro de día en la URL api-eltiempo: la URL incluye /6 al final, que probé en sábado y funcionó (sábado = día ISO 6). Queda pendiente confirmar que el domingo (día ISO 7) no rompe la llamada; si cambia la URL habrá que sustituir el 6 fijo por fecha.isoweekday().
Task Scheduler «Aemet actualitzacio prevision»: la cadena de scripts está verificada, pero falta comprobar que la tarea resuelve correctamente el entorno conda cams_api al lanzarse desde el planificador de Windows.

📆 Próxima entrada: semana del 4 al 10 de mayo de 2026.