MySQL: Staat stil op: "Stats: Missing consumption data for: 2019-12-22" #909

jBRNDnl · 2020-02-27T10:15:45Z

Ik gebruik

DSMR-reader versie: v3.4
Hardware: RaspberryPi 2 Model B
Native of Docker: Native
DSMR-protocol slimme meter: v4
Database: MySQL op een externe server.

M'n dsmr-reader setup is een 1/2 jaar defect geweest en heeft dus in die periode niks meer geschreven in de database. Sinds 21 december 2019 staat hij weer aan. Ik heb al handmatig waardes toegevoegd via het admin panel voor de dag en uur statistieken, maar toch krijg ik onderstaande meldingen.

[2020-02-27 09:32:35,749] DEBUG    SP: 0 backend service(s) ready to run
[2020-02-27 09:32:35,815] DEBUG    dsmr_backend.management.commands.dsmr_backend: Sleeping 1.0s
[2020-02-27 09:32:36,834] DEBUG    SP: 1 backend service(s) ready to run
[2020-02-27 09:32:36,838] DEBUG    SP: Running "Generate day and hour statistics" (dsmr_stats.services.run)
[2020-02-27 09:32:37,465] DEBUG    Stats: Missing consumption data for: 2019-12-22
[2020-02-27 09:32:37,611] DEBUG    SP: Rescheduled "Generate day and hour statistics" to 2020-02-27 10:32:37.469682+01:00 (ETA 0:59:59.858194)
[2020-02-27 09:32:37,694] DEBUG    dsmr_backend.management.commands.dsmr_backend: Sleeping 1.0s
[2020-02-27 09:32:38,711] DEBUG    SP: 0 backend service(s) ready to run
[2020-02-27 09:32:38,799] DEBUG    dsmr_backend.management.commands.dsmr_backend: Sleeping 1.0s
[2020-02-27 09:32:39,816] DEBUG    SP: 0 backend service(s) ready to run

Zou je me op weg kunnen helpen om het probleem op te lossen?

The text was updated successfully, but these errors were encountered:

dennissiemensma · 2020-02-27T18:58:01Z

Bedankt voor je melding. Wat krijg je hierbij te zien in de DB?

select read_at from dsmr_consumption_electricityconsumption where read_at > '2019-12-21 00:00:00' order by read_at asc limit 5

jBRNDnl · 2020-02-28T05:23:20Z

Als ik dat doe komt het volgende eruit.

Showing rows 0 -  4 (5 total, Query took 0.0020 seconds.)

select read_at from dsmr_consumption_electricityconsumption where read_at > '2019-12-21 00:00:00' order by read_at asc limit 5

read_at   	
2019-12-21 01:44:00.000000	
2019-12-21 01:48:00.000000	
2019-12-21 02:07:00.000000	
2019-12-21 02:08:00.000000	
2019-12-21 02:09:00.000000

dennissiemensma · 2020-02-28T07:11:29Z

Je kunt hetzelfde doen voor de twee dagen erna:

select read_at from dsmr_consumption_electricityconsumption where read_at > '2019-12-22 00:00:00' order by read_at asc limit 5

select read_at from dsmr_consumption_electricityconsumption where read_at > '2019-12-23 00:00:00' order by read_at asc limit 5

Als er voor de 22e inderdaad geen data is en voor de 23e wel. Dan heb je twee keuze:

Handmatig de 22e toevoegen aan de dagtotalen, zodat die verder gaat
Wachten tot ik er een fix voor kan maken

Als beide dagen geen data hebben, is het eerst een kwestie van uitzoeken hoe lang of groot het gat is.

jBRNDnl · 2020-02-28T23:44:31Z

Hierbij m'n data.

Hier de 22e.

MariaDB [dsmrreader]> select read_at from dsmr_consumption_electricityconsumption where read_at > '2019-12-22 00:00:00' order by read_at asc limit 5
    -> ;
+----------------------------+
| read_at                    |
+----------------------------+
| 2019-12-22 00:01:00.000000 |
| 2019-12-22 00:02:00.000000 |
| 2019-12-22 00:03:00.000000 |
| 2019-12-22 00:04:00.000000 |
| 2019-12-22 00:05:00.000000 |
+----------------------------+
5 rows in set (0.022 sec)

en hierbij de 23e.

MariaDB [dsmrreader]> select read_at from dsmr_consumption_electricityconsumption where read_at > '2019-12-23 00:00:00' order by read_at asc limit 5;
+----------------------------+
| read_at                    |
+----------------------------+
| 2019-12-23 00:01:00.000000 |
| 2019-12-23 00:02:00.000000 |
| 2019-12-23 00:03:00.000000 |
| 2019-12-23 00:04:00.000000 |
| 2019-12-23 00:05:00.000000 |
+----------------------------+
5 rows in set (0.000 sec)

Niet veel geks aan te zien. Helaas geen ontbrekende data.

dennissiemensma · 2020-02-29T10:45:00Z

Ik denk dat ik een aparte branch voor je maak met wat extra debug logging om te zien wat er precies mis gaat. Het is ongetwijfeld iets heel kleins wat ik over het hoofd zie.

Ik kom daar later op terug, momenteel zit ik wat krap in de tijd.

dennissiemensma · 2020-03-01T18:44:24Z

Bij nader inzien hellpt meer logging niet. Zou je eens willen proberen om handmatig een record voor de Dag-totalen te maken voor de 22e?
Ik ben benieuwd of die bij de 23e tegen hetzelfde aanloopt. Ik zie niet in waarom die de melding geeft terwijl er wel data is.

jBRNDnl · 2020-03-02T06:07:02Z

Helaas heeft het niets geholpen. Inmiddels voor de 22e en 23e data toegevoegd.

[2020-03-02 07:05:49,062] DEBUG    SP: Running "Generate day and hour statistics" (dsmr_stats.services.run)
[2020-03-02 07:05:49,730] DEBUG    Stats: Missing consumption data for: 2019-12-24

dennissiemensma · 2020-03-02T17:19:03Z

Kun je eens kijken of er wel voor elke dag records zijn? Ik weet niet of de mysql query klopt, maar zoiets:

select date_format("%Y-%m-%d", read_at) as dag, count(id) as aantal 
from dsmr_consumption_electricityconsumption 
where read_at > '2019-12-21 00:00:00' 
group by dag
order by dag asc;

jBRNDnl · 2020-03-03T06:27:21Z

Ik kwam op dit commando uit.

SELECT DATE_FORMAT(read_at, "%Y-%m-%d") as dag, count(id) as aantal FROM `dsmr_consumption_electricityconsumption` WHERE `read_at` > '2019-04-11 00:00:00' GROUP BY DATE_FORMAT(dag, "%Y-%m-%d") ORDER BY 'dag' DESC

Zoals je ziet is de meting gestopt op 17 april 2019 en heb ik de boel weer aangeslingerd op 21 december 2019.

+------------+--------+
| dag        | aantal |
+------------+--------+
| 2019-04-11 |   1431 |
| 2019-04-12 |   1429 |
| 2019-04-13 |   1430 |
| 2019-04-14 |   1433 |
| 2019-04-15 |   1432 |
| 2019-04-16 |   1432 |
| 2019-04-17 |    331 |
| 2019-12-21 |   1184 |
| 2019-12-22 |   1440 |
| 2019-12-23 |   1440 |
| 2019-12-24 |   1440 |
| 2019-12-25 |   1440 |
| 2019-12-26 |   1440 |
| 2019-12-27 |   1439 |
| 2019-12-28 |   1440 |
| 2019-12-29 |   1439 |
| 2019-12-30 |   1426 |
| 2019-12-31 |   1440 |
| 2020-01-01 |   1440 |
| 2020-01-02 |   1440 |
| 2020-01-03 |   1440 |
| 2020-01-04 |   1440 |
| 2020-01-05 |   1440 |
| 2020-01-06 |   1440 |
| 2020-01-07 |   1440 |
| 2020-01-08 |   1432 |
| 2020-01-09 |   1437 |
| 2020-01-10 |   1440 |
| 2020-01-11 |   1440 |
| 2020-01-12 |   1440 |
| 2020-01-13 |   1440 |
| 2020-01-14 |   1440 |
| 2020-01-15 |   1439 |
| 2020-01-16 |   1440 |
| 2020-01-17 |   1440 |
| 2020-01-18 |   1440 |
| 2020-01-19 |   1440 |
| 2020-01-20 |   1440 |
| 2020-01-21 |   1440 |
| 2020-01-22 |   1427 |
| 2020-01-23 |   1369 |
| 2020-01-24 |   1428 |
| 2020-01-25 |   1440 |
| 2020-01-26 |   1440 |
| 2020-01-27 |   1428 |
| 2020-01-28 |   1440 |
| 2020-01-29 |   1440 |
| 2020-01-30 |   1440 |
| 2020-01-31 |   1440 |
| 2020-02-01 |   1440 |
| 2020-02-02 |   1440 |
| 2020-02-03 |   1436 |
| 2020-02-04 |   1438 |
| 2020-02-05 |   1440 |
| 2020-02-06 |   1440 |
| 2020-02-07 |   1440 |
| 2020-02-08 |   1440 |
| 2020-02-09 |   1440 |
| 2020-02-10 |   1440 |
| 2020-02-11 |   1440 |
| 2020-02-12 |   1305 |
| 2020-02-13 |   1433 |
| 2020-02-14 |   1434 |
| 2020-02-15 |   1433 |
| 2020-02-16 |   1433 |
| 2020-02-17 |   1433 |
| 2020-02-18 |   1432 |
| 2020-02-19 |   1423 |
| 2020-02-20 |   1423 |
| 2020-02-21 |   1432 |
| 2020-02-22 |   1433 |
| 2020-02-23 |   1433 |
| 2020-02-24 |   1431 |
| 2020-02-25 |   1432 |
| 2020-02-26 |   1432 |
| 2020-02-27 |   1411 |
| 2020-02-28 |   1419 |
| 2020-02-29 |   1420 |
| 2020-03-01 |   1419 |
| 2020-03-02 |   1428 |
| 2020-03-03 |    383 |
+------------+--------+
81 rows in set (0.208 sec)

dennissiemensma · 2020-03-03T17:37:31Z

Helder. Ik ga dan hier nog wat dieper kijken naar dit mechanisme i.cm. MySQL. In #899 loopt iemand tegen hetzelfde aan.

Wellicht is het iets in het ORM wat wel werkt voor PostgreSQL maar niet lekker voor MySQL.

dennissiemensma · 2020-03-03T17:51:30Z

@jBRNDnl @peternijssen hebben jullie in MySQL de tijdzone-definities aanstaan?

(https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)

dennissiemensma · 2020-03-03T18:16:29Z

En geeft deze query output voor jullie?

@jBRNDnl

SELECT (1) AS `a` FROM `dsmr_consumption_electricityconsumption` WHERE DATE(CONVERT_TZ(`dsmr_consumption_electricityconsumption`.`read_at`, 'UTC', 'Europe/Amsterdam')) = '2019-12-24' LIMIT 1

@peternijssen

SELECT (1) AS `a` FROM `dsmr_consumption_electricityconsumption` WHERE DATE(CONVERT_TZ(`dsmr_consumption_electricityconsumption`.`read_at`, 'UTC', 'Europe/Amsterdam')) = '2020-01-02' LIMIT 1

peternijssen · 2020-03-03T18:17:53Z

Dit klinkt als een heel bekend probleem waar ik in het dagelijks leven ook een keer tegenaan ben gelopen. De tabel die de timezones bevat is inderdaad leeg en dan kun je inderdaad die convert_tz niet gebruiken. Je query geeft me ook 0 output.

Even kijken hoe ik die tabel netjes kan vullen op mijn NAS. Ik kom er op terug.

dennissiemensma · 2020-03-03T18:20:41Z

Ik denk dat dat dan de oorzaak is. Het project is timezone-aware en dat is ook de reden dat ik ooit voor Postgres heb gekozen als default DB, omdat die ondersteuning native is.

Je kunt proberen om deze stap uit de dev-setup-guide te volgen: https://dsmr-reader.readthedocs.io/en/v3/development.html#setting-up-a-development-environment-in-ubuntu-18-04

mysql_tzinfo_to_sql /usr/share/zoneinfo | sudo mysql --defaults-file=/etc/mysql/debian.cnf mysql
sudo mysql --defaults-file=/etc/mysql/debian.cnf

Eventueel kun je ze ook los van elkaar uitvoeren. De eerste genereert simpelweg queries.

peternijssen · 2020-03-03T18:24:46Z

Je query geeft inmiddels "1" terug. Ik ben via SSH mijn nas ingegaan, vervolgens naar /usr/local/mariadb10/bin en daar het commando ./mysql_tzinfo_to_sql /usr/share/zoneinfo | ./mysql -u root -p mysql gedraaid.

ik geloof dat hij om 20:02 weer een poging waagt om de data te berekenen.

dennissiemensma · 2020-03-03T18:27:07Z

Je kunt dit versnellen/forceren door in de webinterface naar /admin/dsmr_backend/scheduledprocess/ te gaan. Zoek Generate day and hour statistics, open die en pas de tijd aan naar nu of eerder.

peternijssen · 2020-03-03T18:33:07Z

Data processing is on schedule: March 2, 2020 🎉

Opgelost!

dennissiemensma · 2020-03-03T18:34:51Z

Fijn om te horen, bedankt voor het snelle uitproberen!

dennissiemensma · 2020-03-03T18:35:40Z

@jBRNDnl zie de laatste paar comments. Waarschijnlijk moet je ook bij jou zoeken in de richting van tijdzone-support.

Ik zal in de volgende versie een eenmalige check opnemen die voor mysql-gebruikers kijkt of het aanstaat. En zo nee, ze waarschuwt.

peternijssen · 2020-03-03T18:37:23Z

Bedankt voor je ondersteuning, ondanks dat ik nog als een oude rot op MySQL zit ;)

jBRNDnl · 2020-03-03T21:48:59Z

Dennis dit was de oplossing. Hij is nu bezig met het bijwerken van het archief. Hartelijk dank voor de ondersteuning.

dennissiemensma assigned jBRNDnl Feb 27, 2020

dennissiemensma added this to the Other milestone Feb 27, 2020

dennissiemensma mentioned this issue Mar 3, 2020

Datum blijft "hangen" #899

Closed

dennissiemensma changed the title ~~Staat stil op: "Stats: Missing consumption data for: 2019-12-22"~~ MySQL: Staat stil op: "Stats: Missing consumption data for: 2019-12-22" Mar 3, 2020

dennissiemensma added a commit that referenced this issue Mar 3, 2020

MySQL: Staat stil op: "Stats: Missing consumption data for: ..." #909

fb62707

dennissiemensma added a commit that referenced this issue Mar 3, 2020

MySQL: Staat stil op: "Stats: Missing consumption data for: ..." #909

dc3edcd

dennissiemensma added a commit that referenced this issue Mar 3, 2020

MySQL: Staat stil op: "Stats: Missing consumption data for: ..." #909

b67791b

dennissiemensma closed this as completed Mar 4, 2020

dennissiemensma mentioned this issue Apr 20, 2020

Dag rapporten worden niet meer gegenereerd #974

Closed

dennissiemensma mentioned this issue Aug 4, 2020

dsmr-reader als add-on in Home Assistant #1041

Closed

azhiltsov mentioned this issue Dec 19, 2020

Add mysql libraries to the image? xirixiz/dsmr-reader-docker#159

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MySQL: Staat stil op: "Stats: Missing consumption data for: 2019-12-22" #909

MySQL: Staat stil op: "Stats: Missing consumption data for: 2019-12-22" #909

jBRNDnl commented Feb 27, 2020 •

edited

dennissiemensma commented Feb 27, 2020

jBRNDnl commented Feb 28, 2020

dennissiemensma commented Feb 28, 2020 •

edited

jBRNDnl commented Feb 28, 2020

dennissiemensma commented Feb 29, 2020

dennissiemensma commented Mar 1, 2020

jBRNDnl commented Mar 2, 2020

dennissiemensma commented Mar 2, 2020 •

edited

jBRNDnl commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020 •

edited

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020

jBRNDnl commented Mar 3, 2020

MySQL: Staat stil op: "Stats: Missing consumption data for: 2019-12-22" #909

MySQL: Staat stil op: "Stats: Missing consumption data for: 2019-12-22" #909

Comments

jBRNDnl commented Feb 27, 2020 • edited

dennissiemensma commented Feb 27, 2020

jBRNDnl commented Feb 28, 2020

dennissiemensma commented Feb 28, 2020 • edited

jBRNDnl commented Feb 28, 2020

dennissiemensma commented Feb 29, 2020

dennissiemensma commented Mar 1, 2020

jBRNDnl commented Mar 2, 2020

dennissiemensma commented Mar 2, 2020 • edited

jBRNDnl commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020 • edited

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

dennissiemensma commented Mar 3, 2020

peternijssen commented Mar 3, 2020

jBRNDnl commented Mar 3, 2020

jBRNDnl commented Feb 27, 2020 •

edited

dennissiemensma commented Feb 28, 2020 •

edited

dennissiemensma commented Mar 2, 2020 •

edited

peternijssen commented Mar 3, 2020 •

edited