Casi todos los casos de «la programación se dispara cuando no toca» tienen la misma causa: la hora del equipo. Y se concentran en dos fechas, el último domingo de marzo y el último de octubre. Este año el cambio a horario de invierno es el domingo 25 de octubre: a las 03:00 los relojes vuelven a las 02:00, y España pasa de UTC+2 a UTC+1.
Cómo obtiene la hora un Shelly
Los Shelly no llevan reloj con batería — salvo la gama Pro, que se verá abajo. Al arrancar piden la hora UTC a un servidor SNTP, por defecto time.google.com, y la convierten a hora local con la zona horaria configurada. De esos dos datos, y de las coordenadas, salen:
- las programaciones (encender a las 20:00, apagar a las 23:30);
- la salida y la puesta de sol, que además necesitan latitud y longitud;
- las escenas con condición horaria;
- el reparto por horas y días del histórico de los medidores.
Las programaciones se guardan y se ejecutan en el propio equipo, no en la nube. Por eso funcionan sin internet una vez el equipo tiene hora, y por eso todo depende de que esa hora sea la buena.
Comprobarlo desde la API
En un equipo Gen2 o posterior, la configuración de hora está en Sys.GetConfig, dentro de location (tz, lat, lon) y sntp (server):
http://<ip>/rpc/Sys.GetConfigLo que hay que ver es que tz sea una zona con nombre, Europe/Madrid o Atlantic/Canary, y no un desfase. Para fijarla:
http://<ip>/rpc/Sys.SetConfig?config={"location":{"tz":"Europe/Madrid"}}Y para saber si el equipo tiene hora en este momento, Sys.GetStatus: los campos time y unixtime vienen a null mientras no ha sincronizado. Si después de un corte están a null, ninguna programación va a saltar hasta que cambien.
http://<ip>/rpc/Sys.GetStatusSíntoma y causa
| Síntoma | Causa | Dónde mirar |
|---|---|---|
| Salta una hora antes o después | Zona horaria mal | location.tz |
| Salida o puesta de sol corridas | Zona o coordenadas mal | location.lat / lon |
| Tras un apagón no salta nada | Arrancó sin red y no tiene hora | time = null |
| Se descuadra en marzo y octubre | Desfase fijo en lugar de zona | location.tz |
Zona con nombre o desfase fijo
Con Europe/Madrid, el equipo conoce las reglas del horario de verano y aplica el cambio solo; no hay que tocar nada. Con un desfase fijo — UTC+2 puesto a mano — el equipo no sabe que el 25 de octubre España pasa a UTC+1, y todo se ejecuta una hora tarde hasta que alguien lo corrija. Lo mismo, al revés, en marzo.
Hay además una franja ambigua que no depende de la configuración: el día del cambio de octubre, la hora entre las 02:00 y las 03:00 ocurre dos veces; el de marzo, no ocurre. No programes nada crítico en esa franja, o asume que ese día puede ejecutarse dos veces o ninguna.
Después de un apagón
Un equipo que arranca sin conexión no tiene hora, y sin hora no ejecuta programaciones. En cuanto recupera la red y sincroniza, vuelve a la normalidad; pero si la Wi-Fi tarda en levantar más que el Shelly — lo normal cuando vuelve la luz a la vez a todo —, hay un rato en que los horarios están en pausa.
SNTP va por UDP, puerto 123. En redes con salida a internet filtrada, una regla que bloquee ese puerto deja al equipo sin hora aunque todo lo demás funcione. Si la instalación no sale a internet, apunta sntp.server a un servidor de hora local; si sale, déjalo por defecto.
Los equipos de la gama Pro llevan reloj de tiempo real (RTC) y mantienen la hora aunque caigan internet o el servidor SNTP. Para una programación que no puede fallar — una persiana de seguridad, un riego —, ese margen es el argumento para un Pro.
Y en los medidores
En un EM, un Plug S o cualquier equipo con medición, la hora decide en qué franja del histórico cae cada medida. Los kWh acumulados no se pierden: el contador suma igual. Lo que se desplaza es cuándo aparece cada consumo:
- Zona mal: el pico de las 21:00 aparece a las 20:00 o a las 22:00; la curva es correcta pero está corrida.
- Corte de medianoche desplazado: el total diario de la app no cuadra con el del contador de la compañía.
- Día del cambio: en octubre una hora sale doble, en marzo falta una.
- Apagón sin red: hueco en el histórico hasta que el equipo recupera la hora.
Lista de comprobación
location.tzenEurope/Madrid(o detección automática), nunca un desfase.location.latyloncon tus coordenadas reales, si usas salida o puesta de sol.- Salida a internet por UDP 123, o un
sntp.serverlocal si la red está aislada. - Cobertura Wi-Fi suficiente para que sincronice nada más arrancar.
- Nada crítico programado entre las 02:00 y las 03:00.
- Tras el cambio del 25, abrir dos o tres programaciones clave y confirmar la hora.
Si la salida o la puesta de sol no coinciden con las de tu localidad, la detección automática puso unas coordenadas genéricas. Ajústalas a mano y el cálculo se afina al minuto.