Al parecer, mi teleinformación (MQTT) tiene índices, mientras que el resto tiene una potencia consumida (MQTT y Z2M).
En la parte superior, la información del día en las tareas, también permite ver en qué punto está el cálculo para los impacientes 
Raro, yo los tengo de mi lado, ¿puedes confirmarme que tienes:
- ir a la página mqtt
- Luego haz F12 y ve a la pestaña « Red »
- Luego escribe en la búsqueda « Borne VE » para tener solo ese
- Selecciona el último « device?order_dir=asc&search=… » y despliega las características del dispositivo
- Busca la característica de la Energía consumida (tipo « energy ») y observa su id.
- Luego busca la característica del tipo « thirty-minutes-consumption » y mira su « energy_parent_id », debe corresponder al id anterior. Luego anota su id
- De manera similar, busca la característica « thirty-minutes-consumption-cost » y mira su « energy_parent_id », debe corresponder al id anterior esta vez de la característica de tipo « thirty-minutes-consumption ».
Si estas condiciones no se cumplen no funcionará. Pero de todos modos, esto significaría que en la jerarquía « Mis dispositivos » del « Seguimiento de energía » no están bien alineados. Puse esta limitación para:
- por un lado evitar una lista demasiado larga
- por otro lado evitar lanzar un cálculo en una jerarquía incorrecta.
¿Creamos estas funcionalidades manualmente antes de la actualización de Pierre-Gilles o automáticamente con la actualización?
Creé todas estas funciones hace mucho tiempo, y como ahora estoy en el teléfono, las revisaré en detalle más tarde en la web.
Acabo de verificar y los hijos/padres están bien.
Por otro lado, tengo el parent_id del cargador VE que no coincide con el id de mi contador principal, aunque mi árbol de seguimiento de energía está bien y no sé si es normal:
Después de verificar, el parent_id de mis índices de teleinformación es el mismo que el parent_id del cargador VE, y también es el mismo que el parent_id de mis enchufes Zigbee, y todos están en Nivel 1 bajo el contador principal.
Hola @mutmut,
Lo siento, una emergencia familiar me ha impedido continuar.
Acabo de relanzar un build de la imagen con las modificaciones mencionadas anteriormente
Y un parche que, espero, resolverá el problema con las funciones que no veías !!
terdious/gladys:dev-energy-calculate
-
Si puedes volver a probar.
-
Y hacer una prueba de reinicio de Gladys durante un recálculo para decirme qué opinas de los registros en las tareas (por ejemplo, esperas 5 minutos antes de cortar y al reconectar vas a las tareas, deberías ver en qué punto estaba - qué día - estaba en el momento del corte, permitiendo reanudar el recálculo en la misma fecha)
-
Si lanzas una tarea larga que dura más de 1 hora, deberías ver una acumulación de tareas « 30 minutos », he añadido registros para asegurarnos de que las tareas « Consumo » y « Costo » calculan bien los mismos períodos.
Construcción terminada:
Gracias @Terdious, voy a volver a probarlo esta semana, acabo de resolver un problema de fuga de memoria que duraba desde hace una semana y que me congelaba el frontend 
Y lo peor de todo es que el culpable es un módulo NOUS B3Z que enviaba 4 actualizaciones por segundo a mi z2m y que luego me dejaba Gladys en PLS, fue una miseria encontrarlo 
En la batalla, mi matter/matterbridge está HS, así que veré esa parte más tarde.
Ahora parece que funciona correctamente de nuevo (bueno, cruzo los dedos), así que lo dejaré así un tiempo para que los backups Gladys Plus se reinicien tranquilamente.
Te mantendré informado en cuanto pruebe tu última imagen con tus solicitudes.
¿Y cómo lo hiciste para reducir el número de envíos de tus tomas NOUS?
@_Will_71 Fui a la pestaña Configuración del módulo y puse un retraso de 10s para los envíos de payloads:
Un reinicio de z2m, luego de Gladys y se resolvió.
También aproveché para desactivar los historiales de las funciones y eso eliminó todo el historial a la vez.
No es un relé doble vital, solo el encendido de 2 luces diferentes, por lo que no hay consecuencias en mi sistema.
¡Primer post del año, así que mejores deseos para 2026 que comienza, y un buen feedback para @Terdious 
¡Las informaciones en el registro de las tareas son geniales, es muy explícito!
¡Las fechas son perfectas!
Solo una pregunta sobre
Progreso: fecha AAAA-MM-JJ, ¿eso significa que la fecha mostrada está hecha o está en proceso de cálculo?Como no lo sabía, volví a lanzar el cálculo el día anterior para estar seguro.
En cuanto al registro de Docker, ¿es normal que sea tan verboso?
Porque tengo esto para cada día calculado en un solo dispositivo y me pregunto si es para todos, los registros se inflarán como un globo. En cualquier caso, se ve claramente que está trabajando
Hola @mutmut,
Gracias por tus pruebas y comentarios el 1 de enero ^^
Se trata del día en curso de progreso. Por lo tanto, si es necesario reiniciar, hay que reiniciar el mismo día (esto permite tener una información coherente con la selección que hay que hacer para el reinicio). Puedo añadir « Progreso en curso » en lugar de simplemente « Progreso » para una mejor comprensión. Para darse cuenta, al mostrar el día en cuestión se puede ver que el cálculo se detuvo a mitad del día / o mirar el día anterior para ver que todas las horas del día están bien completas ^^
Sí, pensé que podría ser interesante en caso de depuración tener suficiente información y partí del principio de que Gladys gestiona un tamaño máximo de registro. Pero sí, es posible que sea demasiado…
Acabo de ver que tengo el mismo problema que @froch con los horarios en Tempo:
Debería tener solo las primeras 6 barras para las horas valle en mi ejemplo (de 0h a 6h), pero tengo valores de horas valle a las 6h cuando debería estar en horas punta.
Me parece que si un valor supera la hora de finalización y se registra después, se colocará en el siguiente intervalo.
Lo raro es que el coste de esta parte se basa correctamente en el coste de horas valle azul (que termina a las 6h).
Sigo a mi publicación aquí sobre un valor incorrecto de uno de mis índices Tempo (probablemente debido a un error de envío de datos de mi sistema teleinfo2mqtt).
Acabo de recuperar los valores del 11/11/25 (con Yaak) para verificar qué sucedió y tengo un valor incorrecto que se instaló (800kWh de más)
¿Hay alguna manera de cambiar/eliminar este valor?
No hay verificación de valores antes/después durante el cálculo del seguimiento energético y no tener en cuenta/eliminar un valor incorrecto?
Por supuesto, habría que definir qué es un valor incorrecto para Gladys…
Y para los cálculos de consumo de 30 minutos, ¿se hace sobre la suma de cada valor de cada línea o sobre un promedio, o sobre cada valor cada 30 minutos, etc.?
También hice una solicitud para tener una limpieza de valores innecesarios para los índices
Hola @mutmut
Bien visto, en efecto parecía mucho un valor incorrecto registrado.
Para modificar o eliminar valores, yo uso 
DBeaver para abrir y visualizar la base de datos después de detener Gladys y hacer una copia de seguridad de la DB.
Luego, le pedí a chatGPT que me hiciera la consulta, bueno, tuve problemas con el formato de la columna ‹ created_at ›, así que no te pego todas sus respuestas, pero la consulta global con verificación antes/después da:
SELECT device_feature_id, value, created_at
FROM t_device_feature_state
WHERE device_feature_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND created_at >= TIMESTAMPTZ '2025-11-11 10:36:55.911+0000'
AND created_at < TIMESTAMPTZ '2025-11-11 10:36:55.912+0000';
UPDATE t_device_feature_state
SET value = 158021
WHERE device_feature_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND created_at >= TIMESTAMPTZ '2025-11-11 10:36:55.911+0000'
AND created_at < TIMESTAMPTZ '2025-11-11 10:36:55.912+0000'
AND value = 958021;
SELECT device_feature_id, value, created_at
FROM t_device_feature_state
WHERE device_feature_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
AND created_at >= TIMESTAMPTZ '2025-11-11 10:36:55.911+0000'
AND created_at < TIMESTAMPTZ '2025-11-11 10:36:55.912+0000';
Para ejecutar la consulta en DBeaver (después de abrir la tabla - esto configura el script directamente en la DB / tabla correcta):
Luego pegas la consulta en la ventana y reemplazas el
device_feature_id de cada parte de la consulta (ya he puesto normalmente los valores y fechas correctos en la consulta según tu tabla - pero verifica de todos modos ^^).Puedes verificar en qué se va a realizar la consulta antes de la intervención ejecutando solo la primera consulta. Para hacerlo, colocas el cursor en cualquier parte de la primera consulta antes del « ; » y luego la ejecutas con el primer botón:
Y verifica al final de la página si es el valor/fecha correcto
Finalmente, si todo está bien, ejecutas todo con este botón:
Tendrás las 2 pestañas de los select Antes/Después al final de la página:
Ese es el problema… Y al escribirte mi caso personal, que es que, en este período invernal, consumo hasta 140kWh/día, me di cuenta de que @pierre-gilles había integrado un campo en las tarifas de energía que podría ser muy interesante para detectar una incoherencia:
De hecho, solo habría que especificar que el valor debe escribirse en kVA, y por lo tanto en número. Luego, conocemos las curvas de disparo de un interruptor de abonado y, en particular, que es imposible funcionar a más de 18kWh + 10% es decir 19,8kWh por lo que en 30 minutos = 19,8 / 2 = 9,9kWh.
En este caso, podríamos integrar esta fórmula matemática para:
- No incluir los valores superiores en los cálculos
- Reportar y guardar los valores detectados como incoherentes
- En el futuro, integrar estas incoherencias también para los dispositivos auxiliares (declarar en una característica los valores máximos de consumo de un dispositivo como un lavavajillas). Pienso en ciertos dispositivos Tasmota que ya me han reportado valores de ‹ 0 › en 1 actualización en 2024 y que tendrán, por lo tanto, el mismo efecto que acabas de encontrar.
Es la suma de las diferencias entre todos los valores sucesivos en el intervalo, no es ni un promedio ni una toma puntual.
Finalmente, estoy bastante de acuerdo desde hace mucho tiempo en tener un medio para verificar/corregir/incluir directamente en Gladys los valores de las características. Pero esto representa un trabajo muy grande, y entiendo que no sea evidente desarrollarlo. Lo vemos en HA, es pesado y lo encuentro, al usarlo, nada evidente/simple de usar. Por lo tanto, también hay que pensar en algo muy amigable cuando, en realidad, muy pocos lo usarán. No da muchas ganas de trabajar en ello ^^
PS: En un proyecto personal entre amigos, también tenemos esta necesidad, y hemos pospuesto el trabajo en esta parte durante años 
Me encanta tu idea sobre un máximo vinculado a la suscripción que no debe excederse bajo pena de determinar un valor incorrecto.
Ahora entiendo mejor por qué es tan largo con mis 6 índices.
Para los índices que no se mueven durante el día, solo sería necesario un cálculo en lugar de +30000 por índice por día
Bueno, es por tramos de 30 minutos, así que mi razonamiento no es totalmente correcto, pero si paso a 48 cálculos ya es enorme.
Lo que no entiendo de este tramo de 30 minutos de cálculo:
- 10:36:53 → 158021
- 10:36:55 → 958021, es decir, una diferencia de +800000
- 10:37:01 → 158021, es decir, una diferencia de -800000
El total debería ser 0, ¿no?
Recuerdo una discusión sobre un posible cambio de hardware, pero siempre vinculado al mismo dispositivo. ¿Sería ese el famoso Reset counter que impide que la suma sea = 0?
Exactamente. Como hay un « valor negativo », lo considera como un reinicio a 0 o el reemplazo del contador por uno que tenía un valor negativo.
Hay que encontrar el justo medio entre todos los usos y casos posibles. En este caso, con un valor positivo erróneo y el retorno al valor correcto como has tenido, esto nos demuestra que no todos los casos se han considerado.
Por lo tanto, la solución para « detectar lo mejor posible » un valor incoherente resolverá este caso.
Sin embargo, quedarán los casos en los que un dispositivo envía valores erróneos que están dentro del rango de « seguridad » que podríamos establecer, pero en este caso es imposible de verificar, por lo que la única solución quedará en manos de los usuarios.
Efectivamente, habrá que ver si puede modificar esta lógica. Pero en este caso, solo es pesado para los cálculos iniciales. En el seguimiento posterior de los intervalos de 30 minutos, no tiene un impacto en el tiempo perceptible.
No, la integración de Matter no gestiona el nuevo desarrollo del seguimiento de energía, ¡es un desarrollo que hay que hacer!
Estoy de acuerdo en que un editor en Gladys que permita visualizar/modificar los valores de los sensores sería genial.
En cualquier caso, es mucho más fácil de desarrollar que una pseudo-detección de valores incoherentes, que nunca cubrirá todos los casos y que no resuelve el problema de los valores falsos que permanezcan dentro de los límites.
¿Puedes crear una solicitud de funcionalidad?
Mientras tanto, el tutorial de @Terdious es genial para hacer la modificación directamente en la base de datos.