[vz-users] SQLSTATE[22012]: Division by zero

[René W.]

Hey,
ich habe die Tabelle „Aggregate“ geleert und dann „php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null“ ausgeführt. Das lief ohne Fehler. Danach habe ich es nochmal ausgeführt und in der Tabelle wurde ein Datensatz entfernt. Seit dem läuft es wieder.

Danke

Von: Andreas Goetz
Gesendet: Samstag, 15. Juni 2019 13:52
An: volkszaehler.org - users
Betreff: Re: [vz-users] SQLSTATE[22012]: Division by zero

Hi Rene,

Das hat wie vermutet mit vzlogger überhaupt gar nicht zu tun:

> Subject: Cron <pi at raspberrypi> php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null

Irgendwie hast Du es geschafft einen Fehler zu provozieren den es noch nie gab. Mach mal bitte ein 

	aggregate clear (oder so ähnlich)

dann den Befehl von oben.

Mal schauen ob die Tabelle sauber wieder aufgebaut werden kann. Irgendwas ist da sehr krumm…

Viele Grüße, Andreas




On 15. Jun 2019, at 12:04, René W. <tylonhh at gmail.com> wrote:

Hallo Zusammen,
 
da habe ich wohl zu weit Gedacht und nur auf meine Anfängererfahrung vertraut. Manchmal ist es aber nicht gut wenn man „mitdenkt“. Daher meine zielgerichtete Frage.
 
Also dann mal von ganz Anfang:
In SSH erhalte ich die Meldung das ich eine „Mail“ habe
 
pi at raspberrypi:~ $ cat /var/mail/pi
>From pi at raspberrypi Sat Jun 15 11:50:02 2019
Return-path: <pi at raspberrypi>
Envelope-to: pi at raspberrypi
Delivery-date: Sat, 15 Jun 2019 11:50:02 +0200
Received: from pi by raspberrypi with local (Exim 4.92)
        (envelope-from <pi at raspberrypi>)
        id 1hc5Jy-0004aw-An
        for pi at raspberrypi; Sat, 15 Jun 2019 11:50:02 +0200
From: root at raspberrypi (Cron Daemon)
To: pi at raspberrypi
Subject: Cron <pi at raspberrypi> php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/home/pi>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=pi>
Message-Id: <E1hc5Jy-0004aw-An at raspberrypi>
Date: Sat, 15 Jun 2019 11:50:02 +0200
 
 
In AbstractMySQLDriver.php line 106:
 
  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, "1", "1", 1, "1"]:
 
  SQLSTATE[22012]: Division by zero: 1365 Division by 0
 
In PDOStatement.php line 119:
  SQLSTATE[22012]: Division by zero: 1365 Division by 0
 
In PDOStatement.php line 117:
  SQLSTATE[22012]: Division by zero: 1365 Division by 0
 
run [-l|--level LEVEL] [-m|--mode MODE] [-p|--periods PERIODS] [-v|--verbose] [--] [<uuid>...]
 
Das ist erstmal die Ausgangssituation.
Wenn ich jetzt aber so über die Sinnhaftigkeit der aggtime nachdenke, macht es dann nicht eher Sinn mit den Gesamtzählerständen zu arbeiten? Mein Ziel ist es jedenfalls den momentanen Verbrauch (also die Differenz zweier Gesamtstände) darzustellen. Das hätte zumindest den Vorteil das mir kein Verbrauch flöten geht. Oder?
Ich würde stand jetzt erstmal den Intervall bei den Leistungswerten deaktivieren, wenn ich das richtig verstanden habe.
 
LG
 
Von: Daniel Lauckner
Gesendet: Samstag, 15. Juni 2019 08:25
An: volkszaehler.org - users
Betreff: Re: [vz-users] SQLSTATE[22012]: Division by zero
 
Hallo,
 
 
am Samstag, 15. Juni 2019 um 04:30 hat René W. geschrieben:
> ich erhalte eine SQL Fehlermeldung „SQLSTATE[22012]: Division by Zero“.
 
Details?
 
> Ich vermute sehr stark das es an den aggtime und interval
> liegt.
 
Glaube ich ehrlich gesagt nicht.
 
> Kann da bitte jemand mal auf meine conf schauen?
 
Jupp, kann ja nix schaden.
 
> Welche Werte würden denn dort sonst Sinn machen?
 
Bei d0-Zählern stellt sich eigentlich die Frage: Entweder/Oder
Es ergibt keine Sinn den Zähler(stand) mehrfach abzufragen nur um
dann die Werte zu aggregieren. Es genügt die Anwendung von Intervall.
 
Bei Leistungswerten muss man aber jeden verfügbaren Wert abgreifen um
einen möglichst aussgekräftigen Mittelwert zu erhalten. Da würde man
auch bei einem D0-Zähler auf Aggregation zurückgreifen. Aber ohne
Intervall.
 
 
mfg Daniel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20190615/63378742/attachment.html>