Apparemment ma teleinformation (MQTT) a des index alors que le reste a une puissance consommée (MQTT et Z2M).
Au top l’information du jour dans les tâches, ça permet aussi de voir où en est le calcul pour les impatients 
Etrange, je les ai bien de mon côté, peux-tu me confirmer que tu as bien :
- te rendre sur la page mqtt
- Ensuite fais F12 et va dans l’onglet « Réseau »
- Ensuite tu tape dans la recherche « Borne VE » pour n’avoir que celui-ci
- Sélectionne le dernier « device?order_dir=asc&search=… » et déploie les features du device
- Recherche la feature de l’Energie consommée (type « energy ») et observe son id.
- Recherche ensuite la feature du type « thirty-minutes-consumption » et regarde son « energy_parent_id », il doit correspondre à l’id précédent. Releve ensuite son id
- Pareillement, recherche la feature « thirty-minutes-consumption-cost » et regarde son « energy_parent_id », il doit correspondre à l’id précédent cette fois de la feature de type « thirty-minutes-consumption ».
Si ces conditions ne sont pas remplies ça ne fonctionnera pas. Mais du coût cela voudrait dire que dans l’arborescence « Mes appareils » du « Suivi de l’énergie » il ne sont pas bien caler. J’ai mis cette limitation pour :
- d’une part éviter une liste trop longue
- d’autre part éviter de lancer un calcul sur une mauvaise arborescence.
Tu avais créer ces fonctionnalités manuellement avant la mise à jour de Pierre-Gilles ou en automatique avec la maj ?
J’avais créé toutes ces fonctionnalités bien avant, et comme je suis sur le téléphone pour l’instant, je regarderai en détail plus tard en web.
1 « J'aime »
Je viens de vérifier et les enfant/parent sont bons.
Par contre j’ai le parent_id de la borne VE qui ne correspond pas à l’id de mon compteur de tête alros que mon arbo Suivi d’énergie est bonne et je ne sais pas si c’est normal :
Après vérif, le parent_id de mes index de téléinformation est le même que le parent_id de la borne VE, et est aussi le même que pour le parent_id de mes prises zigbee, et tous sont en Niv1 sous le compteur de tête.
Salut @mutmut,
Désolé, une urgence familiale m’a empêché de poursuivre.
Je viens de relancer un build de l’image avec les modifications évoquées plus haut
ET un correctif qui, je l’espère résoudra le problème sur les fonctionnalités que tu ne voyais pas !!
terdious/gladys:dev-energy-calculate
-
Si tu peux retester.
-
Ainsi que faire un test de redémarrage de Gladys pendant un recalcul pour me dire ce que tu penses des logs dans les tâches (par exemple tu attends 5 minutes avant de couper et à la reconnexion tu vas dans les tâches, tu devrais voir où il en était - quel jour - il en était au moment de la coupure, permettant de reprendre le recalcul à cette même date)
-
Si tu lances une tâches longues qui met plus d’1h, tu devrais voir une accumulation de tâches « 30 minutes », j’ai ajouter des logs pour être certains que les tâches « Consommation » et « Coût » calculs bien les mêmes périodes.
Build terminé :
Merci @Terdious je vais retester cette semaine, je viens seulement de me dépatouiller d’un problème de fuite mémoire qui dure depuis une semaine et qui me freezait le frontend 
Et le pire de tout ça c’est que le coupable est un module NOUS B3Z qui envoyait 4 updates par seconde à mon z2m et qui ensuite me mettait Gladys en PLS, la misère à trouver 
Dans la bataille, mon matter/matterbridge est hs, je verrais donc cette partie plus tard.
Maintenant ça semble tourner de nouveau correctement (enfin je croise les doigts) donc je vais laisser un peu comme ça histoire que les backups Gladys Plus se relancent tranquillement.
Je te tiens au courant dès que j’ai testé ta dernière image avec tes demandes.
1 « J'aime »
Et du coup tu as fait comment pour réduire le nombre d’envoi de tes prises NOUS?
@_Will_71 Je suis allé dans l’onglet Paramètres du module et j’ai mis 10s de délai pour les envois de payloads :
Un reboot de z2m, ensuite de Gladys et c’était réglé.
J’en ai aussi profité pour désactiver les historiques des fonctionnalités et ça a supprimé tout l’historique en même temps.
Ce n’est pas un relais double vital, juste allumage de 2 lumières différentes, donc pas de conséquence sur mon système.
2 « J'aime »
Premier post de l’année alors meilleurs voeux pour 2026 qui démarre, et un beau feedback pour @Terdious 
Au top les infos dans le log des tâches, c’est super explicite !
Les dates c’est parfait !
Juste une question sur
Progression : date AAAA-MM-JJ, ça veut dire que la date affichée est faite ou est en cours de calcul ?Comme je ne savais, j’ai relancé le calcul la veille pour être sûr.
Côté log docker, c’est normal que ce soit aussi verbeux ?
Car j’ai ça pour chaque jour calculé sur un seul appareil et je me dis que si c’est pour tous, les logs vont gonfler comme une baudruche. En tout cas on voit bien que ça travaille
1 « J'aime »
Salut @mutmut,
Merci pour tes tests et tes retours ce 1er de l’an ^^
Il s’agit du jour en cours de progression. Donc si besoin de relancer, il faut relancer ce même jour (ça permet d’avoir une info cohérente avec la sélection à faire pour la relance). Je peux ajouter « Progression en cours » plutôt que simplement « Progression » pour plus de compréhension. Pour s’en aperçevoir, en affichant le jour en question on peut voir que le calcul s’est arrêté en cours de journée / ou regarder le jour précédent pour voir que toutes les heures de la journées sont bien remplies ^^
Oui, je me disais que ça pouvait être intéressant en cas de debug d’avoir suffisamment d’info et je suis parti du principe que Gladys gérait une taille de log max. Mais en effet c’est peut-être de trop …
Je viens de voir que j’avais le même soucis que @froch pour les horaires en Tempo :
Je devrais avoir uniquement les 6 premières barres pour les HC dans mon exemple (de 0h à 6h) mais j’ai des valeurs HC qui viennent à 6h alors que je devrais être en HP.
J’ai l’impression que si une valeur dépasse l’horaire de fin et est enregistrée après alors elle va se mettre sur le créneau suivant.
Ce qui est bizarre c’est que le coût de cette portion est bien basé sur le coût HC bleu (qui s’arrête à 6h).
Je fais suite à mon post ici sur une valeur erronée d’un de mes index Tempo (sans doute suite à une erreur d’envoi de données de mon système teleinfo2mqtt).
Je viens de récupérer les valeurs du 11/11/25 (avec Yaak) pour vérifier ce qu’il s’est passé et j’ai une valeur erronée qui s’est installée (800kWh en trop)
Il y a moyen de changer/supprimer cette valeur ?
Il n’y a pas de vérification de valeur avant/après lors du calcul du suivi énergétique et ne pas prendre en compte/supprimer une valeur erronée ?
Certes il faudrait définir ce qu’est une valeur erronée pour Gladys…
Et pour les calculs de conso 30mn, ça se fait sur la somme de chaque valeur de chaque ligne ou sur une moyenne, ou sur chaque valeurs toutes les 30mn, etc. ?
J’ai aussi fait une demande pour avoir un nettoyage de valeurs inutiles pour les index
Salut @mutmut
Bien vu, en effet ça ressemblait fort à une mauvaise valeur enregistrée.
Pour modifier ou supprimer des valeurs pour ma part j’utilise 
DBeaver pour ouvrir et visualiser la base de donnée après avoir arrêté Gladys et backup la DB.
Ensuite, j’ai demandé à chatGPT de me faire la requete, bon j’ai galéré avec le format de la colonne ‹ created_at › donc je ne te colle pas toutes ses réponses, mais la requete globale avec vérification avant/après donne :
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';
Pour exécuter la requete sous DBeaver (après avoir ouvert la table - cela configure le script directement sur la bonne DB / table) :
Ensuite tu colles la requete dans la fenêtre et tu remplaces le
device_feature_id de chaque partie de requete (j’ai déjà mis normalement les bonnes valeurs et dates dans la requete en fonction de ton tableau - mais vérifie quand même ^^).Tu peux vérifier sur quoi la requête va se faire avant intervention en lançant seulement la 1ère requete. Pour ce faire tu places ton curseur n’importe où dans la 1ère requete avant le « ; » puis tu lances avec le 1er bouton :
Et tu vérifies en bas de page si c’est bien la bonne valeur/date
Enfin, si c’est bon, tu lances la globalité avec ce bouton :
Tu auras les 2 onglets des select Avant/Après en bas de page :
1 « J'aime »
C’est le problème … Et en t’écrivant mon cas personnel qui est que, en cette période hivernale, je consomme jusqu’à 140kWh / jour, j’ai réalisé que @pierre-gilles avait intégré une case dans les tarifs d’énergie qui pourrait être très intéressante pour détecter une incohérence :
En effet, il faudrait juste préciser que la valeur est à écrire en kVA, et donc en nombre seulement. Ensuite, on connait les courbes de déclenchement d’un disjoncteur d’abonné et notamment, qu’il est impossible de fonctionner à plus de 18kWh + 10% soit 19,8kWh donc sur 30 minutes = 19,8 / 2 = 9,9kWh.
Pour le coup on pourrait intégrer cette formule mathématique pour :
- Ne pas inclure les valeurs supérieurs dans les calculs
- Remonter et sauvegarder les valeurs détectées comme incohérentes
- Dans le futur intégrer ces incohérences également pour les appareils annexes (déclarer dans une feature les valeurs max de consommation d’un appareil comme un lave-vaisselle). Je pense à certains appareils Tasmota qui m’ont déjà remonté des valeurs à ‹ 0 › sur 1 maj en 2024 et qui auront donc ce même effet que tu viens de rencontrer.
C’est la somme des différences entre toutes les valeurs successives dans la tranche, ce n’est ni une moyenne, ni une prise ponctuelle.
Enfin, je suis assez d’accord depuis longtemps pour avoir un moyen de vérifier/corriger/inclure directement dans Gladys les valeurs des features. Mais cela représente un très gros travail, et je comprend que ce ne soit pas évident de développer cela. On le voit dans HA, c’est lourd et je trouve à l’utilisation pas du tout évident/simple à utiliser. Donc il faut en plus réfléchir à quelque chose de très convivial alors que finalement très peu l’utiliserons. Ca ne donne pas forcément envie de bosser dessus ^^
PS : Sur un projet personnel entre ami, nous avons également cette nécessité, et on repousse le travail sur cette partie depuis des années 
1 « J'aime »
J’aime beaucoup ton idée sur un max lié à l’abonnement à ne pas dépasser sous peine de déterminer une valeur erronée.
Alors je comprends mieux pourquoi c’est si long avec mes 6 index !
Pour les index qui ne bougent pas sur la journée, un seul calcul serait nécessaire au lieu de +30000 par index par jour
Bon c’est par tranche de 30mn alors mon raisonnement n’est pas totalement juste mais si je passe à 48 calculs c’est déjà énorme !
Ce que j’ai du mal à comprendre dans cette tranche de 30mn de calcul :
- 10:36:53 → 158021
- 10:36:55 → 958021 soit une diff de +800000
- 10:37:01 → 158021 soit une diff de -800000
Le total devrait être de 0, non ?
Je me rappelle une discussion sur un changement potentiel de matériel mais toujours lié au même device. Est-ce que ce serait ça le fameux Reset counter qui empêche de faire l’addition =0 ?
1 « J'aime »
C’est exactement ça. Comme il y une « valeur négative », il le considère comme soit une remise à 0, soit le remplacement du compteur par un qui avait une valeur négative.
Il faut réussir à trouver le juste milieu entre tous les usage et cas possible. Pour le coup dans le cas d’une valeur erroné positive avec retour à la bonne valeur comme tu as eu, cela nous démontre que tous les cas de figures ne sont pas envisagés.
Du coup la solution pour « détecter au mieux » une valeur incohérente résoudra bien ce cas de figure.
Il restera toutefois les cas ou un appareil renvoi des valeur erronées qui sont comprise dans la plage de « sécurité » qu’on pourrait mettre en place, mais là pour le coup c’est impossible à vérifier donc la seul solution restera entre les mains des utilisateurs.
En effet, à voir si il peut modifier cette logique. Mais pour le coup ce n’est vraiment lourd que pour les calculs initiaux. Dans le suivi ensuite des intervalles de 30 minutes, cela n’a pas d’impact temps perceptible.
Non, l’intégration Matter ne gère pas le nouveau développement du suivi de l’énergie, c’est un développement à faire !
Je suis d’accord qu’un éditeur dans Gladys permettant de visualiser/modifier les valeurs des capteurs, ça serait top.
En tout cas, c’est beaucoup plus simple à développer qu’une pseudo-détection de valeurs incohérentes, qui ne couvrira jamais tous les cas et qui ne règle pas le cas des fausses valeurs qui resteraient dans les bornes.
Est-ce que tu peux créer une demande de fonctionnalité ?
En attendant, le tuto de @Terdious est top pour faire la modification directement en DB !
2 « J'aime »
1 « J'aime »