id_ecq | hp | hc | ptec | lastvalue | variation | date_upd | tmp_value |
---|---|---|---|---|---|---|---|
147 | 1100000 | null | HP | 1000 | 0 | null | null |
148 | 0 | null | HP | 0 | 0 | null | null |
149 | 1000 | null | HP | 0 | 0 | null | null |
170 | 354509267 | 325446 | HP | 354834713 | 1816 | 2020-06-05 14:15:29 | 0.55537 |
171 | 16582701 | 329 | HP | 16583030 | 0 | 2020-06-05 14:15:31 | 0.305362 |
272 | 84421 | null | HP | 84421 | 1817 | 2020-06-05 09:55:33 | 0.25 |
Est ce que réellement ta pompe a arrêtée de consommer à 14h15?
Non, j’ai fait le select au moment où j’ai posté la réponse (donc vers 16h15) et la pompe est toujours en marche depuis 8h48.
Je me demande si je n’ai pas un problème d’horloge sur mon RPi.
J’ai des logs qui sont horodatés avec 2 heures de retard.
Donc le problème vient de là. Le champs date_upd est utilisé dans le calcul que tu peux voir sur le log pour déterminer l’écart de temps entre le nouveau relevé et l’ancien. Et toi tu as 2h de retard.
C’est pas un problème de fuseau horaire?
El plugin utilise la fonction NOW() sql pour renseigner la date et l’heure dans la table.
Coté Jeedom l’heure et le fuseau sont correctes. Côté Linux j’arrive au limite de mes compétences pour vérifier ça.
Essaies cette requête et regarde si l’heure est correcte.
select now() from dual
Cela me retourne l’heure exacte
Mince alors, j’étais persuadé que tu aurais 2h de décalage
pi@raspberrypi:~ $ date
Fri 5 Jun 17:51:11 CEST 2020
pi@raspberrypi:~ $ date -u
Fri 5 Jun 15:51:13 UTC 2020
Il n’y a que le log de GoogleCast qui est affiché en UTC.
j’ai déjà vu un problème de fuseau horaire dans les logs. Mais je ne me rappelle plus la solution.
C’est bizarre, je lance le select * from conso_tmp plusieurs fois, il m’affiche parfois l’heure exacte, parfois - 2 heures
Ça veut dire que l’interprétation de l’heure par la base n’est pas stable. Peut-être un problème de paramétrage de la time zone dans la base.
@Thibaut_T Est que cela te dit quelque chose?
Tu peux regarder ça c’est instructif [Résolu] Timezone MYSQL par Fireicefly - page 1 - OpenClassrooms
et ça MySQL :: MySQL 5.7 Reference Manual :: 5.1.13 MySQL Server Time Zone Support
Du coup execute cette requête pour voir comment c’est paramétré:
SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;
@@GLOBAL.time_zone | @@SESSION.time_zone |
---|---|
SYSTEM | +02:00 |
Ton session.time_zone devrait être à SYSTEM d’après ce que j’ai lu et ce que j’ai moi même sur mon Jeedom
Comment fait-on pour changer ça ?
Tu peux tenter
SET time_zone = SYSTEM;
oui, j’ai essayé mais cela ne change rien, a moins qu’il faille relancer mysql ?
Bizare le SELECT @@SESSION.time_zone; revoie SYSTEM sur l’interface Mysql en SSH et me renvoie +02:00 dans l’interface Jeedom
Tu as essayé de faire le set dans Jeedom?