Re: [vz-users] Absolute Zählerstände mit Peaks
Hallo, am Montag, 20. März 2023 um 13:32 hat René W geschrieben: > Ein Schuss ins Blaue: Könntest du die Werte per SML abfragen? Das wäre der erste mir bekannte Zähler der beide Protokolle unterstützt... mfg Daniel
Re: [vz-users] Aggregation (minute) schlägt fehl
Ich hatte „damals“ auch schon diese nervige Meldung: https://demo.volkszaehler.org/pipermail/volkszaehler-users/2019-June/013374.html Vielleicht sind dort ja noch ein paar Hinweise. Ich selber nutze VZ nicht mehr dafür. Gruß René Michael Hartmann schrieb am Mo. 20. März 2023 um 15:03: > Hallo Christian, > > > > ich hatte erst an negative Werte gedacht und keine um den > „Ausstiegszeitpunkt“ gefunden. Das scheidet aber auch aus, da sich die > Werte im Zähler befinden und somit keine Division durch Null hervorrufen > können. > > > > Was mich irritiert ist das nach Löschen der aggregierten Daten deren > Neuerstellung fehlerfrei durchläuft. > > > > Kann jemand aus der Fehlermeldung erkennen um welchen Kanal (Channel_ID) > es gehen könnte? > > > > Grüße > > > > Micha > > > > *Von:* volkszaehler-users [mailto: > volkszaehler-users-boun...@demo.volkszaehler.org] *Im Auftrag von *Christian > Lange > *Gesendet:* Montag, 20. März 2023 11:29 > *An:* volkszaehler-users@demo.volkszaehler.org > *Betreff:* Re: [vz-users] Aggregation (minute) schlägt fehl > > > > Hi Micha, > > ich hab leider keine Ahnung, wie die Datenbank aussieht (ich nutze selbst > eine andere), aber der Fehler sagt aus, dass eine Division durch 0 > vorliegt. > > Die einzige Zeile in der SQL Query, die mir da ins Auge sticht ist diese > hier: > > > COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - > MIN(agg.prev_timestamp)), > > Das Maximum des Timestamps minus dem Minimum des vorherigen Timestamps aus > der (on the fly) erzeugten "agg" Tabelle sind zusammen 0. Daher klappt die > Division und damit die SQL Query nicht. Die Daten stammen (soweit ich das > sehen kann) aus der "data" Tabelle. Vielleicht fällt dir ja da etwas auf in > den Daten bei den Timestamps. Den Rest überlasse ich den Experten, die das > Tool so im Einsatz haben ;) > > Viel Erfolg, > Christian > > > > > > Am 20.03.2023 um 10:37 schrieb Michael Hartmann: > > Hallo, > > > > ich hole das hier noch einmal vor, da es ziemliche nervt. > > > > Via cronjob lasse ich alle 10min eine Aggregation auf die Minute laufen. > Bereits vor einigen Wochen ist diese dann plötzlich mit der folgenden > Fehlermeldung ausgestiegen: > > > > In AbstractMySQLDriver.php line 128: > > > > An exception occurred while executing 'REPLACE INTO aggregate > (channel_id, > > type, timestamp, value, count) SELECT channel_id, ? AS type, > MAX(agg.timest > > amp) AS timestamp, COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) > - M > > IN(agg.prev_timestamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS > coun > > t FROM ( SELECT channel_id, timestamp, value, value * (timestamp - > @prev_ti > > mestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS prev_timestamp, > @p > > rev_timestamp := timestamp FROM data CROSS JOIN (SELECT @prev_timestamp > := > > UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d > %H:% > > i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND > aggreg > > ate.channel_id = ?) AS vars WHERE channel_id = ? AND timestamp >= > IFNULL((S > > ELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, > "%Y-%m-% > > d %H:%i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? > AND > > aggregate.channel_id = ? ), 0) AND timestamp < > UNIX_TIMESTAMP(DATE_FORMAT(N > > OW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, > YEAR(FROM_ > > UNIXTIME(timestamp/1000)), DAYOFYEAR(FROM_UNIXTIME(timestamp/1000)), > HOUR(F > > ROM_UNIXTIME(timestamp/1000)), MINUTE(FROM_UNIXTIME(timestamp/1000))' > with > > params [1, 1, "3", "3", 1, "3"]: > > > > SQLSTATE[22012]: Division by zero: 1365 Division by 0 > > > > > > In Exception.php line 18: > > > > SQLSTATE[22012]: Division by zero: 1365 Division by 0 > > > > > > In PDOStatement.php line 117: > > > > SQLSTATE[22012]: Division by zero: 1365 Division by 0 > > > > Die Aggregation auf Stunde und Tag bereitet (bisher) keine Probleme. > > > > Beim letzten Mal hatte ich die Aggregationstabelle gelöscht und neu > aufgebaut. Nach einigen Wochen kommt der Fehler nun wieder. > > > > Kann mir jemand erklären wo das Problem liegt? Die Fehlermeldung kann ich > nicht interpretieren. > > > > Viele Grüße > > > > Micha > >
Re: [vz-users] Aggregation (minute) schlägt fehl
Hallo Christian, ich hatte erst an negative Werte gedacht und keine um den „Ausstiegszeitpunkt“ gefunden. Das scheidet aber auch aus, da sich die Werte im Zähler befinden und somit keine Division durch Null hervorrufen können. Was mich irritiert ist das nach Löschen der aggregierten Daten deren Neuerstellung fehlerfrei durchläuft. Kann jemand aus der Fehlermeldung erkennen um welchen Kanal (Channel_ID) es gehen könnte? Grüße Micha Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Christian Lange Gesendet: Montag, 20. März 2023 11:29 An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Aggregation (minute) schlägt fehl Hi Micha, ich hab leider keine Ahnung, wie die Datenbank aussieht (ich nutze selbst eine andere), aber der Fehler sagt aus, dass eine Division durch 0 vorliegt. Die einzige Zeile in der SQL Query, die mir da ins Auge sticht ist diese hier: > COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - > MIN(agg.prev_timestamp)), Das Maximum des Timestamps minus dem Minimum des vorherigen Timestamps aus der (on the fly) erzeugten "agg" Tabelle sind zusammen 0. Daher klappt die Division und damit die SQL Query nicht. Die Daten stammen (soweit ich das sehen kann) aus der "data" Tabelle. Vielleicht fällt dir ja da etwas auf in den Daten bei den Timestamps. Den Rest überlasse ich den Experten, die das Tool so im Einsatz haben ;) Viel Erfolg, Christian Am 20.03.2023 um 10:37 schrieb Michael Hartmann: Hallo, ich hole das hier noch einmal vor, da es ziemliche nervt. Via cronjob lasse ich alle 10min eine Aggregation auf die Minute laufen. Bereits vor einigen Wochen ist diese dann plötzlich mit der folgenden Fehlermeldung ausgestiegen: In AbstractMySQLDriver.php line 128: An exception occurred while executing 'REPLACE INTO aggregate (channel_id, type, timestamp, value, count) SELECT channel_id, ? AS type, MAX(agg.timest amp) AS timestamp, COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - M IN(agg.prev_timestamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS coun t FROM ( SELECT channel_id, timestamp, value, value * (timestamp - @prev_ti mestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS prev_timestamp, @p rev_timestamp := timestamp FROM data CROSS JOIN (SELECT @prev_timestamp := UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d %H:% i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggreg ate.channel_id = ?) AS vars WHERE channel_id = ? AND timestamp >= IFNULL((S ELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-% d %H:%i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_FORMAT(N OW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, YEAR(FROM_ UNIXTIME(timestamp/1000)), DAYOFYEAR(FROM_UNIXTIME(timestamp/1000)), HOUR(F ROM_UNIXTIME(timestamp/1000)), MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, 1, "3", "3", 1, "3"]: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In Exception.php line 18: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In PDOStatement.php line 117: SQLSTATE[22012]: Division by zero: 1365 Division by 0 Die Aggregation auf Stunde und Tag bereitet (bisher) keine Probleme. Beim letzten Mal hatte ich die Aggregationstabelle gelöscht und neu aufgebaut. Nach einigen Wochen kommt der Fehler nun wieder. Kann mir jemand erklären wo das Problem liegt? Die Fehlermeldung kann ich nicht interpretieren. Viele Grüße Micha
Re: [vz-users] Absolute Zählerstände mit Peaks
Moin René, im Datenblatt zum Zähler finde ich nur Angaben zu d0. Ist also leider nichts mit SML :( Am 20.03.2023 um 13:32 schrieb René W: Ein Schuss ins Blaue: Könntest du die Werte per SML abfragen? Ich meine, da werden doch weniger Daten übertragen. Kann aber auch sein, dass ich völlig daneben liege. Am Mo., 20. März 2023 um 12:04 Uhr schrieb Christian Lange : Hi Frank, ja, das sind die Stände, wie sie in der DB stehen. In den Logs sehe ich auch nur 2 Nachkommastellen und auch der Zähler selbst zeigt nur zwei Stellen an. Scheint also einfach am Zähler zu liegen. Das Auslesen dauert aber tatsächlich recht lange, weil eine Vielzahl von Daten abgefragt werden. Nicht nur ein Haufen OBIS Codes sondern auch noch ein Haufen Vorwertzählerstände. Wie ich die loswerde muss ich wohl mit dem Hersteller mal klären ... Das sieht dann für einen einzigen Code so aus: [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0, value=000149.98, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*01, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87, value=00.00, unit=kWh) Korrigiert habe ich jetzt die Position der Leseköpfe nochmal, aber ich erwarte da keine Wunder :/ Bleibt also wohl nur das manuelle korrigieren, nachdem die Daten in der DB gelandet sind. Vielen Dank aber in jedem Fall für die Tips! Christian Am 17.03.2023 um 21:11 schrieb Frank Richter: Hallo Christian, aggmode: max ist schon richtig für Zählerstände, alles andere verfälscht nur das Ergebnis. Zu deinem Screenshot: sind das die Zählerstände so wie sie in der DB stehen? Dann würde ich am ehesten einen Übertragungsfehler vermuten. D0 bringt ja leider keine Checksumme oder ähnliches mit, um diese auszusortieren. Hast du versucht die Positionierung des Lesekopfs zu optimieren? Liefert der Zähler nur 2 Dezimalstellen, oder sind die abgeschnitten? Grüße Frank Christian Lange schrieb am Fr., 17. März 2023, 14:57: Ahoi, die 20s stammen vom Debuggen. Vielleicht war da auch der Flaschenhals. Ich kann das ja nochmal messen und berichten, wie lange es dauert bis sich in den Logs ein "parsed Value" findet. Wieder was gelernt mit dem inexistenten Intervall ;) Bleibt die Frage nach dem sinnvollen Aggmode :/ Die Timestamps enden auf 0, weil ich die Query für's bessere Vergleichen/Lesen dahingehend gebaut habe (timestamp DIV 60*60). Real sind die Werte andere. Viele Grüße, Christian Am 17.03.2023 um 14:51 schrieb Frank Richter: 20 s dauert einmal Auslesen? Puh, das ist lang. Ohne interval sollte er das einfach in Dauerschleife machen. Warum enden deine Timestamps glatt auf :00? Grüße Frank Christian Lange schrieb am Fr., 17. März 2023, 13:02: Hi Frank, das mit der Aggregation war gestern Abend auch schon mein Gedanke. Ich bin jetzt mal mit aggTime: 60 und Interval: 30 ins Rennen gegangen. Das reine Auslesen dauert knapp unter 20s - 30s Intervall sollte also passen. Die Anzahl der Ausreißer ist auch geringer geworden. Es gibt sie aber weiterhin. Der AggMode ist aktuell "max" - das dürfte aber auch eigentlich nichts bringen - wenn innerhalb des Aggregationszeitraumes ein fehlerhafter Wert ausgelesen wird, dann ist der i.d.R. = dem Max Wert und wird also reported. Zu deinem Vorschlag, mit dem Intervall zu spielen: Wie bekomme ich
Re: [vz-users] Hohe CPU Last > mysql
Hallo, hohe last kann so ziemlich alles bedeuten und auf viele Ursachen haben: - Schreibt das System in den swap? - Hat es I.O. Wait? - verbraucht ein Prozess / mehere Prozesse die ganze cpu? Interessant im top sind diese Zeilen: top - 08:56:54 up 12 min, 1 user, load average: 0,95, 0,97, 0,67 %CPU(s): 1,5 us, 1,0 sy, 0,0 ni, 97,3 id, 0,2 wa, 0,0 hi, 0,0 si, 0,0 st Aber Ungeachtet dessen halte ich eine SD-Karte nicht für das Richtige Medium für eine Datenbank. - Auf Grund Ihrer Bauweise habe die bescheidene Schreibperformance - begrenze Schreibleistung - schlechte I/O Performance - Wie schnell geht so ein Ding kaputt? - Wie wichtig sind dir die Daten? Grüße Sebastian On 20.03.23 07:02, w...@gmx.at wrote: Hallo, mein RaspberryPi (3B+) zeigt unter „top“ eine hohe CPU Last von user mysql an. Auch fällt regelmäßig MQTT aus. Könnte das damit zusammenhängen und woher kommt das? Danke Markus
Re: [vz-users] Absolute Zählerstände mit Peaks
Ein Schuss ins Blaue: Könntest du die Werte per SML abfragen? Ich meine, da werden doch weniger Daten übertragen. Kann aber auch sein, dass ich völlig daneben liege. Am Mo., 20. März 2023 um 12:04 Uhr schrieb Christian Lange < brln...@gmail.com>: > Hi Frank, > > ja, das sind die Stände, wie sie in der DB stehen. In den Logs sehe ich > auch nur 2 Nachkommastellen und auch der Zähler selbst zeigt nur zwei > Stellen an. Scheint also einfach am Zähler zu liegen. > > Das Auslesen dauert aber tatsächlich recht lange, weil eine Vielzahl von > Daten abgefragt werden. Nicht nur ein Haufen OBIS Codes sondern auch noch > ein Haufen Vorwertzählerstände. Wie ich die loswerde muss ich wohl mit dem > Hersteller mal klären ... > > Das sieht dann für einen einzigen Code so aus: > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0, value=000149.98, > unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*01, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87, > value=00.00, unit=kWh) > > Korrigiert habe ich jetzt die Position der Leseköpfe nochmal, aber ich > erwarte da keine Wunder :/ Bleibt also wohl nur das manuelle korrigieren, > nachdem die Daten in der DB gelandet sind. > > Vielen Dank aber in jedem Fall für die Tips! > > Christian > > > Am 17.03.2023 um 21:11 schrieb Frank Richter: > > Hallo Christian, > > aggmode: max ist schon richtig für Zählerstände, alles andere verfälscht > nur das Ergebnis. > > Zu deinem Screenshot: sind das die Zählerstände so wie sie in der DB > stehen? Dann würde ich am ehesten einen Übertragungsfehler vermuten. D0 > bringt ja leider keine Checksumme oder ähnliches mit, um diese > auszusortieren. Hast du versucht die Positionierung des Lesekopfs zu > optimieren? > Liefert der Zähler nur 2 Dezimalstellen, oder sind die abgeschnitten? > > Grüße > Frank > > Christian Lange schrieb am Fr., 17. März 2023, 14:57: > >> Ahoi, >> >> die 20s stammen vom Debuggen. Vielleicht war da auch der Flaschenhals. >> Ich kann das ja nochmal messen und berichten, wie lange es dauert bis sich >> in den Logs ein "parsed Value" findet. >> >> Wieder was gelernt mit dem inexistenten Intervall ;) Bleibt die Frage >> nach dem sinnvollen Aggmode :/ >> >> Die Timestamps enden auf 0, weil ich die Query für's bessere >> Vergleichen/Lesen dahingehend gebaut habe (timestamp DIV 60*60). Real sind >> die Werte andere. >> Viele Grüße, >> Christian >> Am 17.03.2023 um 14:51 schrieb Frank Richter: >> >> 20 s dauert einmal Auslesen? Puh, das ist lang. >> >> Ohne interval sollte er das einfach in Dauerschleife machen. >> >> Warum enden deine Timestamps glatt auf :00? >> >> Grüße >> Frank >> >> Christian Lange schrieb am Fr., 17. März 2023, 13:02: >> >>> Hi Frank, >>> >>> das mit der Aggregation war gestern Abend auch schon mein Gedanke. Ich >>> bin jetzt mal mit aggTime: 60 und Interval: 30 ins Rennen gegangen. Das >>> reine Auslesen dauert knapp unter 20s - 30s Intervall sollte also passen. >>> Die Anzahl der Ausreißer ist auch geringer geworden. Es gibt sie aber >>> weiterhin. Der AggMode ist aktuell "max" - das dürfte aber auch eigentlich >>> nichts bringen - wenn innerhalb des Aggregationszeitraumes ein fehlerhafter >>> Wert ausgelesen wird, dann ist der i.d.R. = dem Max Wert und wird also >>> reported. >>> >>> Zu deinem Vorschlag, mit dem Intervall zu spielen: Wie bekomme ich den >>> Pull Zähler zum reden, wenn ich kein Intervall angebe? >>> Hier mal ein Beispiel - um 23:24:00 ist der ermittelte Wert weit höher >>> als vorher und(!) nachher. Ich brauche also irgendeine Möglichkeit diesen >>> Fehler zu korrigieren. Für's menschliche Auge easy - für eine elegante >>> softwarelösung nicht ganz so trivial ;) >>> >>> Ideen sind willkommen :)) >>> >>> Viele Grüße, >>> Christian >>> Am 17.03.2023 um 00:10
Re: [vz-users] Absolute Zählerstände mit Peaks
Hi Frank, ja, das sind die Stände, wie sie in der DB stehen. In den Logs sehe ich auch nur 2 Nachkommastellen und auch der Zähler selbst zeigt nur zwei Stellen an. Scheint also einfach am Zähler zu liegen. Das Auslesen dauert aber tatsächlich recht lange, weil eine Vielzahl von Daten abgefragt werden. Nicht nur ein Haufen OBIS Codes sondern auch noch ein Haufen Vorwertzählerstände. Wie ich die loswerde muss ich wohl mit dem Hersteller mal klären ... Das sieht dann für einen einzigen Code so aus: [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0, value=000149.98, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*01, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87, value=00.00, unit=kWh) Korrigiert habe ich jetzt die Position der Leseköpfe nochmal, aber ich erwarte da keine Wunder :/ Bleibt also wohl nur das manuelle korrigieren, nachdem die Daten in der DB gelandet sind. Vielen Dank aber in jedem Fall für die Tips! Christian Am 17.03.2023 um 21:11 schrieb Frank Richter: Hallo Christian, aggmode: max ist schon richtig für Zählerstände, alles andere verfälscht nur das Ergebnis. Zu deinem Screenshot: sind das die Zählerstände so wie sie in der DB stehen? Dann würde ich am ehesten einen Übertragungsfehler vermuten. D0 bringt ja leider keine Checksumme oder ähnliches mit, um diese auszusortieren. Hast du versucht die Positionierung des Lesekopfs zu optimieren? Liefert der Zähler nur 2 Dezimalstellen, oder sind die abgeschnitten? Grüße Frank Christian Lange schrieb am Fr., 17. März 2023, 14:57: Ahoi, die 20s stammen vom Debuggen. Vielleicht war da auch der Flaschenhals. Ich kann das ja nochmal messen und berichten, wie lange es dauert bis sich in den Logs ein "parsed Value" findet. Wieder was gelernt mit dem inexistenten Intervall ;) Bleibt die Frage nach dem sinnvollen Aggmode :/ Die Timestamps enden auf 0, weil ich die Query für's bessere Vergleichen/Lesen dahingehend gebaut habe (timestamp DIV 60*60). Real sind die Werte andere. Viele Grüße, Christian Am 17.03.2023 um 14:51 schrieb Frank Richter: 20 s dauert einmal Auslesen? Puh, das ist lang. Ohne interval sollte er das einfach in Dauerschleife machen. Warum enden deine Timestamps glatt auf :00? Grüße Frank Christian Lange schrieb am Fr., 17. März 2023, 13:02: Hi Frank, das mit der Aggregation war gestern Abend auch schon mein Gedanke. Ich bin jetzt mal mit aggTime: 60 und Interval: 30 ins Rennen gegangen. Das reine Auslesen dauert knapp unter 20s - 30s Intervall sollte also passen. Die Anzahl der Ausreißer ist auch geringer geworden. Es gibt sie aber weiterhin. Der AggMode ist aktuell "max" - das dürfte aber auch eigentlich nichts bringen - wenn innerhalb des Aggregationszeitraumes ein fehlerhafter Wert ausgelesen wird, dann ist der i.d.R. = dem Max Wert und wird also reported. Zu deinem Vorschlag, mit dem Intervall zu spielen: Wie bekomme ich den Pull Zähler zum reden, wenn ich kein Intervall angebe? Hier mal ein Beispiel - um 23:24:00 ist der ermittelte Wert weit höher als vorher und(!) nachher. Ich brauche also irgendeine Möglichkeit diesen Fehler zu korrigieren. Für's menschliche Auge easy - für eine elegante softwarelösung nicht ganz so trivial ;) Ideen sind willkommen :)) Viele Grüße, Christian Am 17.03.2023 um 00:10 schrieb Frank Richter: Hallo Christian, denke das liegt am fixen Intervall. Manchmal erwischst du den Zählerstand wenn er frisch umgesprungen ist, und manchmal liegt er schon ein paar Sekunden an bis er gelesen
Re: [vz-users] Aggregation (minute) schlägt fehl
Hi Micha, ich hab leider keine Ahnung, wie die Datenbank aussieht (ich nutze selbst eine andere), aber der Fehler sagt aus, dass eine Division durch 0 vorliegt. Die einzige Zeile in der SQL Query, die mir da ins Auge sticht ist diese hier: > COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_timestamp)), Das Maximum des Timestamps minus dem Minimum des vorherigen Timestamps aus der (on the fly) erzeugten "agg" Tabelle sind zusammen 0. Daher klappt die Division und damit die SQL Query nicht. Die Daten stammen (soweit ich das sehen kann) aus der "data" Tabelle. Vielleicht fällt dir ja da etwas auf in den Daten bei den Timestamps. Den Rest überlasse ich den Experten, die das Tool so im Einsatz haben ;) Viel Erfolg, Christian Am 20.03.2023 um 10:37 schrieb Michael Hartmann: Hallo, ich hole das hier noch einmal vor, da es ziemliche nervt. Via cronjob lasse ich alle 10min eine Aggregation auf die Minute laufen. Bereits vor einigen Wochen ist diese dann plötzlich mit der folgenden Fehlermeldung ausgestiegen: In AbstractMySQLDriver.php line 128: An exception occurred while executing 'REPLACE INTO aggregate (channel_id, type, timestamp, value, count) SELECT channel_id, ? AS type, MAX(agg.timest amp) AS timestamp, COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - M IN(agg.prev_timestamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS coun t FROM ( SELECT channel_id, timestamp, value, value * (timestamp - @prev_ti mestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS prev_timestamp, @p rev_timestamp := timestamp FROM data CROSS JOIN (SELECT @prev_timestamp := UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d %H:% i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggreg ate.channel_id = ?) AS vars WHERE channel_id = ? AND timestamp >= IFNULL((S ELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-% d %H:%i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_FORMAT(N OW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, YEAR(FROM_ UNIXTIME(timestamp/1000)), DAYOFYEAR(FROM_UNIXTIME(timestamp/1000)), HOUR(F ROM_UNIXTIME(timestamp/1000)), MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, 1, "3", "3", 1, "3"]: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In Exception.php line 18: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In PDOStatement.php line 117: SQLSTATE[22012]: Division by zero: 1365 Division by 0 Die Aggregation auf Stunde und Tag bereitet (bisher) keine Probleme. Beim letzten Mal hatte ich die Aggregationstabelle gelöscht und neu aufgebaut. Nach einigen Wochen kommt der Fehler nun wieder. Kann mir jemand erklären wo das Problem liegt? Die Fehlermeldung kann ich nicht interpretieren. Viele Grüße Micha
[vz-users] Aggregation (minute) schlägt fehl
Hallo, ich hole das hier noch einmal vor, da es ziemliche nervt. Via cronjob lasse ich alle 10min eine Aggregation auf die Minute laufen. Bereits vor einigen Wochen ist diese dann plötzlich mit der folgenden Fehlermeldung ausgestiegen: In AbstractMySQLDriver.php line 128: An exception occurred while executing 'REPLACE INTO aggregate (channel_id, type, timestamp, value, count) SELECT channel_id, ? AS type, MAX(agg.timest amp) AS timestamp, COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - M IN(agg.prev_timestamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS coun t FROM ( SELECT channel_id, timestamp, value, value * (timestamp - @prev_ti mestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS prev_timestamp, @p rev_timestamp := timestamp FROM data CROSS JOIN (SELECT @prev_timestamp := UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d %H:% i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggreg ate.channel_id = ?) AS vars WHERE channel_id = ? AND timestamp >= IFNULL((S ELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-% d %H:%i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_FORMAT(N OW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, YEAR(FROM_ UNIXTIME(timestamp/1000)), DAYOFYEAR(FROM_UNIXTIME(timestamp/1000)), HOUR(F ROM_UNIXTIME(timestamp/1000)), MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, 1, "3", "3", 1, "3"]: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In Exception.php line 18: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In PDOStatement.php line 117: SQLSTATE[22012]: Division by zero: 1365 Division by 0 Die Aggregation auf Stunde und Tag bereitet (bisher) keine Probleme. Beim letzten Mal hatte ich die Aggregationstabelle gelöscht und neu aufgebaut. Nach einigen Wochen kommt der Fehler nun wieder. Kann mir jemand erklären wo das Problem liegt? Die Fehlermeldung kann ich nicht interpretieren. Viele Grüße Micha
[vz-users] Hohe CPU Last > mysql
Hallo, mein RaspberryPi (3B+) zeigt unter top eine hohe CPU Last von user mysql an. Auch fällt regelmäßig MQTT aus. Könnte das damit zusammenhängen und woher kommt das? Danke Markus
