En fait le besoin (de mon côté en tout cas), ce n’est vraiment un problème de renommage. Les données de la table states sont bien sur les mêmes capteurs, il n’y a pas de piège pour le calcul de la consommation par jour.
Par exemple, en regardant la table statistics_meta
, je vois que le capteur que j’ai choisi pour le dashboard énergie c’est lui : sensor.index_cummule_global
qui a pour metadata_id 5
.
Via cette requête MySQL :
SELECT
DATE_FORMAT(date_col, '%e %M, %Y, %H:00') AS hour_start,
IFNULL(SUM(value_col - prev_value_col), 0) AS increase_per_hour
FROM
(SELECT
FROM_UNIXTIME(created_ts) AS date_col,
state AS value_col,
LAG(state) OVER (ORDER BY FROM_UNIXTIME(created_ts)) AS prev_value_col
FROM
statistics
WHERE
metadata_id = 5
) AS t
GROUP BY
DATE_FORMAT(date_col, '%e %M, %Y, %H:00')
ORDER BY
hour_start;
Dans un outil de statistique (Metabase, pour les curieux), j’obtiens ça :
Donc information/problème 1 : depuis le 1er mars, toutes les données de la table statistics
sont là et sont bonnes. Mais quand je regarde dans le tableau énergie :
Donc je suis un peu embêté ici. Quelles sont les données qui sont utilisées par le tableau énergie ? Pcq dans mon cas ça ne correspond pas entre la table statistics
et le tableau de bord.
Par exemple, pour aller plus loin j’ai vérifié, pour avant le 1er mars, il n’y a effectivement rien dans la table statistics
. Mais j’ai ce qu’il faut dans states
!
Avec cette requête sur la table states
:
SELECT
DATE_FORMAT(date_col, '%e %M, %Y, %H:00') AS hour_start,
IFNULL(SUM(value_col - prev_value_col), 0) AS increase_per_hour
FROM
(SELECT
FROM_UNIXTIME(last_updated_ts) AS date_col,
state AS value_col,
LAG(state) OVER (ORDER BY FROM_UNIXTIME(last_updated_ts)) AS prev_value_col
FROM
states
WHERE
metadata_id = 4 and attributes_id = 5
ORDER BY last_updated_ts
) AS t
GROUP BY
DATE_FORMAT(date_col, '%e %M, %Y, %H:00')
J’ai bien des données jusqu’au 19 février.
Donc deuxième sujet : comment forcer HA à prendre en compte les données de states historiques dans le tableau énergie ?