Merci pour ta réponse cela va vraiment beaucoup m’aider.
En ce qui concerne la conso de la veille je n’ai pas été très claire et je me suis embrouillé. Je débute et j’ai encore un peu de mal.
1 « J'aime »
Bon j’ai un peu réfléchi sur les raisons de ce souci…et je trouve pas d’explication 
Je vais avoir besoin de ton aide !
Contacte moi en MP ! Ou sur discord.
Edit : Oh j’ai ptet compris ! Je dois faire des tests
1 « J'aime »
Bonjour,
Pour palier à ce problème j’ai mis un attributs Time dans mon sensor, en plus de la valeur de Conso
La valeur, même si elle est identique à la précédente, sera enregistrée car l’attribut Time lui sera différent.
OK j’ai trouvé !
Quand pas de conso, y’a plus d’enregistrements dans influx et au final l’index -2min devient le même que l’index actuel. Mais, la date d’enregistrement du -2min et actuel est aussi la même, puisque l’index n’est pas enregistré plusieurs fois s’il ne change pas (pour des raisons évidentes d’économies de database…)
Du coup le calcul qui fait la différence de temps entre les 2 indexes donne 0.
Ensuite on fait différence d’index (ici 0) divisé par différence de temps (ici encore 0) soit 0/0 !
Shit ! On divise par 0 ! On va créer un trou noir ou un truc comme ça ! lol
Pour palier à ça, soit on continue d’enregistrer les indexes même s’ils ne changent pas. J’aime pas…
Soit on vérifie que la différence de temps est = 0 et dans ce cas la conso aussi ! Je préfère !
Je vais faire un update 
@Bigmat Ta solution est valide aussi, mais lourde au niveau stockage. Si tu veux garder cette solution, tu peux aussi virer le noeud RBE avec l’envoi de l’index en Wh (si tu utilise les flows de ce tuto hein !). C’est ce noeud qui fait des économies
@Dakara j’ai update le flow 2 Part 1 !
En gros un petit ajustement du code du noeud function qui est à la sortie du join :
old = msg.payload.old.old_state;
current = msg.payload.new.new_state;
diff_index = current - old;
diff_seconds = (msg.payload.new.new_date - msg.payload.old.old_date) / 1000;
if (diff_seconds == 0) {
conso = 0;
} else {
coeff = diff_seconds / 3600
conso = diff_index / coeff
conso = Math.round(conso*100)/100
}
msg2 = {};
msg2.payload = {};
msg2.payload.conso = conso;
msg2.payload.diff_sec = diff_seconds;
msg2.payload.old_time = msg.payload.old.old_date;
msg2.payload.new_time = msg.payload.new.new_date;
return msg2;
à la place de :
old = msg.payload.old.old_state;
current = msg.payload.new.new_state;
diff_index = current - old;
diff_seconds = (msg.payload.new.new_date - msg.payload.old.old_date) / 1000;
coeff = diff_seconds / 3600
conso = diff_index / coeff
conso = Math.round(conso*100)/100
msg2 = {};
msg2.payload = {};
msg2.payload.conso = conso;
msg2.payload.diff_sec = diff_seconds;
msg2.payload.old_time = msg.payload.old.old_date;
msg2.payload.new_time = msg.payload.new.new_date;
return msg2;
2 « J'aime »
Impec ! ça marche nickel !! t’est vraiment un chef !! 
Encore une question: est-il normal que la « conso instantané » soit en réalité en retard ? Quand je compare mes deux graph de conso (celui de pinst, et celui que me fournis mon onduleur solaire lorsqu’il consomme sur le résau), pinst semble en retard d’environ une minute (+/-) par rapport a la réalité (bon je pinaille mais j’essaie de comprendre)
Et encore une autre: est-il possible en config triphasé de voir la consommation phase par phase ? (le linky le fait lui donc je me dit que ça doit pouvoir ce faire)
Oui, c’est normal, on fait le calcul avec l’index d’il y a deux minutes et l’index actuel, donc au final on est sur la « conso moyenne » sur les 2 minutes qui sont passées. On fait ce calcul toutes les 90sec, donc si on lisse tout ça on a un décalage de 1m45 en gros
Tu peux réduire ça mais avec le risque que le calcul soit sur des valeurs trop proches et donc se mettre à foirer…
Si tu veux réduire, commencer par faire le calcul toutes les 60 secondes (le 1er noeud inject du Flow 2 Part 1).
Là je vois pas… Sur la doc Enedis je ne trouve pas cette info :
https://www.enedis.fr/sites/default/files/Enedis-NOI-CPT_54E.pdf
Page 16/38 - détail des trames en mode historique pour un compteur triphasé.
Ton compteur affiche le nom de l’information ?
oui dans la page que tu indique c’est le PAPP : Puissance apparente triphasée soutirée (en VA), arrondi à la dizaine la plus proche.
(je ne savais pas qu’on pouvait trouvé ça directement sur le site d’enedis!)
Donc si c’est la PAPP tu peux récupérer cette valeur en sortie du noeud structure payload
Elle est dans msg.payload.PAPP
Edit : En soit, toutes les infos disponibles de la téléinfo sont à la sortie de ce noeud structure payload, suffit d’activer le débug à la sortie de ce noeud pour voir ce qui est exploitable !
Yes !! J’avais compris grace à ton pdf !
Jusque là je voyais pas comment tu pouvais savoir qui était quoi ! (bien que je me doute qu’il y avais un moyen, mais là le pdf c’est la révélation !)
Dans structure payload on récupère bien tout ce qui est possible a récupéré ?
Oui a la sortie de structure payload tu as tout.
1 « J'aime »
Pourrais-tu expliquer cette partie templating ?
`where: '"entity" = ''conso_day'' AND time >= {{(as_timestamp(now()) - (now().hour * 3600) - (now().minute * 60) - (now().second) - 120) | round(0)}}s AND time < {{(as_timestamp(now()) - (now().hour * 3600) - (now().minute * 60) - (now().second)) | round(0)}}s'`
[/quote]
(as_timestamp(now()) : date et heure courantes ?
(now().hour * 3600) : l’heure courante multipliée par 3600 ?
(now().minute * 60) : la minute courante multipliée par 60?
(now().second) : la seconde courante
- 120 ?
- as_timestamp(now()) : date et heure courante en timestamp secondes
- now().hour * 3600 : heure courante en secondes
- now().minute * 60 : minute courant en secondes
- now().second : la seconde courante
On fait donc :
date_heure_courante en secondes - heure courante en secondes - minute courante en seconde - seconde courante - 120 (secondes) => hier 23h58 en timestamp secondes
ok merci.
à la place de -120 pourquoi ne pas mettre - 60 pour hier 23h59 ?
Dans l’objectif d’archiver des consommations mensuelles, est-il possible de faire une requête similaire pour le mois de janvier, une autre pour février, etc. ?
Comme on fait le calcul toutes les 90 secondes autant avoir un peu de marge, de toute façon j’encadre la requête de la veille 23h58 à aujourd’hui 0h00 et je vais chercher la valeur MAX, donc on est certain d’avoir la conso la plus haute de la veille.
Alors…la réponse est pas simple. En théorie oui, mais si vraiment tu les veux fais les !
La vraie réponse est différente, tu veux archiver ? Alors ne fais pas des requêtes dans ta base influxDB depuis HA pour archiver. Influxdb à déjà tout archivé…
Avec grafana par exemple tu peux aller check la valeur max de chaque entité pour une plage de temps donnée.
La grosse limitation c’est que influxDB ne sait pas faire de group_by par mois. Au maxi il sait faire des jours…
Je ne te demandais pas de les faire mais je cherche des pistes pertinentes à explorer.
Oui pour l’afficher dans un panel Grafana mais comment comment exploiter le résultat du check dans une varaible HA ?
De plus on a pas de group-by pour les mois qui n’ont pas nombre de jours identiques.
Il est peut-être plus simple de le faire avec Node-Red et le noeud Cron-plus en écrivant en fin de mois la valeur max du conso_month dans un sensor ?
C’est une piste oui, chaque fin de mois tu stocke la conso quelque part.
Mais si c’est pour de l’archive, stocker dans un sensor HA encore une fois c’est pas la bonne méthode.
Mon avis perso qui n’engage que moi, pour les données récentes (hier, le mois dernier, cette année, aujourd’hui) OK pour les afficher dans HA.
Si j’ai besoin de la conso d’il y a 3 mois, je vais dans mon p’tit grafana et je regarde ! J’en aurai pas besoin tous les matins.
Je stocke où si ce n’est pas dans un sensor ? Dans Influxdb ?
Ou tu veux mais pas dans une database éphémère comme celle de HA.
Non, pour le tuto j’ai créé une database pour node-red sans politique de rétention. je suppose que ça convient ?
