Danke Manfred, jetzt habe ich auch das Problem verstanden. Deine Erklärung ist plausibel. Es hat zwar nur 4 Jahre gedauert, aber besser als nie. ;-) Gruß René
Am Mo., 24. Apr. 2023 um 20:20 Uhr schrieb mh <mh...@arcor.de>: > Hallo Micha, > > das Problem entsteht dadurch, dass du einen Datenwert exakt bei der vollen > Minute (Sonntag, 23.04.2023, 22:15Uhr) hast, und das aggregate Script für > diesen Zeitpunkt den nächsten Wert der aggregate Tabelle berechnen will. > > In der SQL Anweisung > > COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - > MIN(agg.prev_timestamp)), > > ist dann (MAX(agg.timestamp) = MIN(agg.prev_timestamp), was zur Division > durch Null führt. > Das Problem tritt übrigens nur auf, weil es nur einen Datenwert in diesem > Minutenslot gibt. > (ich hatte das schon am 24.3. mal geschrieben - zugegebenermaßen etwas > schwer verständlich formuliert). > > Ich habe beim Check meiner Datenbank übrigens das gleiche Problem > entdeckt, das da seit Anfang Januar "schlummert". > > Hier mal zwei Screenshots aus HeidiSQL, einmal die Daten zum kritischen > Zeitpunkt > > > > > und die zugehörige aggregate Tabelle, die am 2023-01-02 15:09:53 abbricht, > weil der Wert für 15:10 immer wieder zur Division durch 0 führt, > weil kein weiterer Datenwert im Zeitslot für 15:10 existiert (sonder erst > um 15:11:37). > > > > Du kannst die SQL Kommandos modifiziert für channel_id und Zeitpunkt bei > dir mal ausprobieren, und solltest etwas ähnliches finden. > > Es gibt zwei Abhilfen: > a. du kannst die aggregate Tabelle für den Kanal neu rechnen lassen, dann > kommt das Skript "über" die kritische Stelle > b. du kannst den Zeitstempel des Datenwertes modifizieren, z.b. ein > Sekunde dazugeben. > > zu b.: > Wenn du HeidiSQL verwendest, geht das einfach durch Ändern der > entsprechenden Zelle. > > In mysql geht das mit folgendem Befehl: > > REPLACE INTO volkszaehler.data (channel_id,timestamp,value) VALUES (3, > 1682280901000 > , <dein value>) > > Falls du mit SQL nicht vertraut bist: > Den Wert von <dein value> kannst du mit dem Kommando > > SELECT * FROM volkszaehler.data WHERE channel_id=3 AND timestamp= > 1682280900000 > > herausfinden. > > Ich werde einen issue aufmachen, um einen fix im Script zu addressieren. > > Gruss > Manfred > > > > Am 24.04.2023 um 17:07 schrieb hartmann-mi...@web.de: > > Hallo Jens, > > > > erwartungsgemäß ist das Problem wieder da! Die Aggregation die ich nun > alle 15min nur noch auf ausgewählte Kanäle laufen lasse schlägt wieder fehl. > > > > Ich habe dein SQL-Statement ausgeführt und hänge die CSV-Datei hier an. > > > > Hier sehe ich mit Timestamp 1682280900000 (Sonntag, 23.04.2023, 22:15Uhr) > Nullwerte. Das passt da ich erstmalig 22:30Uhr die Fehlermeldung bekomme. > > > > Wie muss ich das nun interpretieren. Dabei brauche ich Unterstützung! > > > > Viele Grüße > > > > Micha > > *Von:* Jens Scheidtmann <jens.scheidtm...@gmail.com> > <jens.scheidtm...@gmail.com> > *Gesendet:* Samstag, 25. März 2023 14:30 > *An:* Michael Hartmann <hartmann-mi...@web.de> <hartmann-mi...@web.de>; > volkszaehler.org - users <volkszaehler-users@demo.volkszaehler.org> > <volkszaehler-users@demo.volkszaehler.org> > *Betreff:* Re: [vz-users] Aggregation (minute) schlägt fehl > > > > Hallo Micha, > > > > die Statements sollen im Fehlerfall die Tabellenzeilen finden, die zum > Fehler führen. > > Ohne Fehler gibt es keine 0-Zeilen. > > > > Wenn es jetzt nicht mehr auftritt, dann war die Drohung ausreichend. 😉 > > > > Jens > > > > Michael Hartmann <hartmann-mi...@web.de> schrieb am Sa. 25. März 2023 um > 12:40: > > Hallo Jens, > > > > ich habe das erste SQL-Statement ausgeführt und hänge das CSV hier an. > > > > Einen Nullwert kann ich da nicht ausmachen. Auch scheint mir die Ausgabe > nicht so zu sein wie gewünscht/erwartet? Die Frage ist auch, ob der Ansatz > so funktioniert, da ich die Aggregationstabelle ja neu aufgebaut habe und > das minütliche Aggregieren aktuell fehlerfrei ist. > > […] > > >