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

Andreas Goetz cpuidle at gmail.com
Sat Jun 15 13:43:09 CEST 2019


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 <http://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 <http://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 <mailto:vz at jahp.de>
> Gesendet: Samstag, 15. Juni 2019 08:25
> An: volkszaehler.org - users <mailto:volkszaehler-users at demo.volkszaehler.org>
> 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/32ca03d8/attachment-0001.html>


More information about the volkszaehler-users mailing list