¡Hola @StephaneB, gracias por los registros!
Verdict: es la fase 2 (el recálculo de costos), y tu registro lo demuestra por sí solo.
El desarrollo exacto de tu ventana 11:30 → 11:48
Hay dos tareas diferentes en tu registro, y es su comparación la que es esclarecedora:
| Hora |
Lo que se ejecuta |
Duración |
| 11:30:00 → 11:30:07 |
Cálculo del consumo desde los índices (31 pares índice/30-min) |
7 s |
| 11:30:07 |
Cálculo de la producción desde los índices (0 dispositivo) |
instantáneo |
| 11:30:07 → 11:30:15 |
Recálculo de costos, 25 dispositivos, ventana = 30 minutos |
8 s  |
| 11:36:26 → 11:36:27 |
Enedis, consumo diario, desde el 14/08 (8 puntos) |
1 s |
| 11:36:27 → 11:37:02 |
Enedis, curva de carga, desde el 15/08 (384 puntos) |
35 s |
| 11:37:02 → 11:48:03 |
Recálculo de costos, 25 dispositivos, ventana = 8 días |
11 min  |
El mismo código, los mismos 25 dispositivos, ejecutados dos veces con 7 minutos de intervalo: 8 segundos en un caso, 11 minutos en el otro. La única variable es el ancho de la ventana recalculada: 30 minutos contra 8 días.
Y 11:36:26 → 11:48:03 = 11 min 40, lo que coincide con los ~12 min mostrados en la tarea.
De paso, los 36 s de la fase 1 son normales y voluntarias: Gladys inserta los puntos de la curva de carga con un retraso de 50 ms entre cada uno para no saturar el CPU durante la importación. 384 puntos × 50 ms ≈ 35 s. Es exactamente lo que vemos. Nada que corregir por este lado.
Tus 4 preguntas
1. « Mi sincronización no comienza de cero » — Exacto, todo está bien por este lado. after 2026-08-14, es la última fecha sincronizada menos 7 días. El error que temía no está ahí.
Pequeña precisión de paso: si ves dos fechas diferentes (14/08 luego 15/08), no es una anomalía — son tus dos funcionalidades Enedis (consumo diario y curva de carga) que cada una mantiene su propia fecha de última sincronización.
2. « ¿Los Inserting chunk 0 son la señal? » — Sí, es exactamente el buen marcador, pero cuidado de no mezclar los dos bloques:
- 31 líneas entre 11:30:07 y 11:30:15 → la tarea de rutina. ~0,25 s por funcionalidad.
- 32 líneas entre 11:37:20 y 11:48:03 → el recálculo desencadenado por Enedis. ~20 s por funcionalidad.
Relacionado con el número de puntos tratados (384 puntos de curva de carga sobre 8 días contra 1 solo sobre 30 minutos), eso hace aproximadamente 55 ms por punto recalculado. Es demasiado, y ahora es mi problema.
3. Los « Found N » diferentes (79 / 31 / 0 / 0 / 25…) — Todo es normal, son contadores que no cuentan lo mismo:
- 79 = dispositivos que llevan una funcionalidad de categoría
energy_sensor, switch o teleinformation (el vivero amplio donde buscamos índices).
- 31 = entre ellos, el número de pares « índice ↔ 30-minutos » conectados entre sí. Atención, el mensaje dice « devices » pero en realidad cuenta pares de funcionalidades — es por eso que « Contador Zlinky » aparece 7 veces seguidas justo después: tu Zlinky expone varios índices (EASF01…EASF10 para Tempo).
- 0 / 0 = lo mismo del lado de la producción. No tienes un índice de producción declarado (tus paneles son seguidos a través de un enchufe, por lo tanto del lado del consumo), por lo tanto 0. Normal.
- 25 = el filtro del recálculo de costo, que es más restrictivo (solo la categoría
energy_sensor). Esta línea aparece una vez por recálculo de costo — de ahí su repetición.
4. « Dos ciclos que se superponen? » — No, tranquilo, y es incluso imposible: todo pasa por una cola que serializa los tratamientos. Lo que ves son dos tareas distintas:
- la de 11:30, programada cada 30 minutos (a HH:00 y HH:30);
- la de 11:36, la sincronización horaria de Enedis, que llama al recálculo de costos al final.
Las dos llaman a la misma función, de ahí las líneas duplicadas.
¿Por qué 11 minutos en tu caso y 5 segundos en el de @PhilippeMA?
Porque el recálculo post-sincronización no tiene en cuenta ni lo que realmente ha cambiado, ni el tamaño de la instalación:
- comienza desde la fecha más antigua resincronizada, es decir siempre ~J-8 (debido a la red de seguridad de 7 días);
- y vuelve a ejecutar todos tus dispositivos de energía, no solo Enedis.
En tu caso, eso hace ~33 funcionalidades de costo × 8 días × 48 puntos, es decir del orden de 12 000 puntos eliminados, recalculados y reinsertados cada hora — mientras que solo la funcionalidad Enedis ha recibido nuevos datos. En el caso de Philippe, con uno o dos dispositivos, el mismo tratamiento pasa desapercibido.
No estás haciendo nada mal: solo eres el primero en tener una instalación lo suficientemente grande como para hacer visible el problema.
Lo que voy a corregir
Es un verdadero defecto de diseño, no un problema de tu instalación.
He propuesto una PR con:
- Recalcular solo lo que se ha movido: después de una sincronización de Enedis, solo las funcionalidades realmente afectadas deben ser retomadas, no todo el parque.
- Recalcular solo los días realmente modificados, en lugar de una ventana fija de 8 días en cada ciclo.
- Optimizar el bucle interno (los 55 ms por punto): los períodos de validez de las tarifas se reconstruyen con conversión de zona horaria para cada punto, cuando podrían hacerse una sola vez.
- Hacer que la fase 2 avance en la barra de progreso: hoy solo sigue la descarga, de ahí la tarea que permanece « en curso » al 100 % durante 10 minutos.
