[98_statistics] Modul hinkt scheinbar hinterher

[andi11]

ah daher die unterschiedliche Denkweise ich hab ein DeltaReading

Code Auswählen Erweitern

setstate STATISTICS_STROMVERBRAUCH 2021-11-01 08:03:26 .Stromverbrauch_Zaehler1_EHZ:total-get LastValue: 11920.6 ShowDate: 2 DecPlaces: 1
bei mir steht da nur etwas vom letzten Wert drin, überhaupt kein Datum. Addiert wird immer die Differenz zum letzten Wert laut Sourcecode

[KölnSolar]

Es fand dann doch kein Monatswechsel statt.  Also habe ich Allgaeuers Methode angewandt, um einen Monatswechsel zu erzwingen. Hat geklappt. Es wurde aber kein event erzeugt, folglich keine Daten gelogged.
Da ich nur 2 Werte logge, habe ich diese manuell in mein Logfile eingetragen. Alle anderen Monats-Werte nutze ich nur für "visuelle Vergleiche", weshalb ich keine readings manuell ändere. Somit habe ich also den Fehler für mich bereinigt.

Grüße Markus

[Beta-User]

Stelle mal eine neue Zeile #326 zur Diskussion:

Code Auswählen Erweitern

   $dayChangeTime += HOURSECONDS * ($th[8] - (localtime(time + DAYSECONDS))[8]);

[andi11]

Stelle mal eine neue Zeile #326 zur Diskussion:

Code Auswählen Erweitern

   $dayChangeTime += HOURSECONDS * ($th[8] - (localtime(time + DAYSECONDS))[8]);

Ich bin mit der Zeitrechnerei in Perl nicht fit. Versteh ich das richtig?

$th[8] =true entspricht localtime()[8]
=> Sommerzeit => true
Was passiert wenn von true was abgezogen wird?

Erreichen willst du "Wenn aktuell Sommerzeit ist, und im nächsten Durchlauf Winterzeit dann Intervall eine Stunde später" oder?

[Beta-User]

...nicht ganz: Es wird nicht "true" zurückgegeben, sondern jeweils ein nummerischer Wahrheitswert. Erst wird die Differenz dieser beiden Werte ermittelt und dann das Ergebnis mit HOURSECONDS multipliziert und zur bisherigen Tageswechsel-Zeit (im üblichen Sekunden-Format) addiert. Das ergibt also folgende Kombinationsmöglichkeiten für die Verschiebung der Tageswechsel-Zeit:

(0 - 0) * 3600 = 0        (Wi "jetzt" -> Wi in 24h)
(0 - 1) * 3600 = -3600 (Wi "jetzt" -> So in 24h)
(1 - 1) * 3600 = 0        (So "jetzt" -> So in 24h)
(1 - 0) * 3600 = 3600  (So "jetzt" -> Wi in 24h)

Diese Berechnungsmethode sollte also jedenfalls dann passen, wenn sie ab 0:00 Uhr und vor 2:00 bzw. 3:00 Uhr angewendet wird.

[KNUT345]

Hallo Zusammen,
kämpfe mit den gleichen Problemen...

Ich hab meine Readings manuell aktualisiert (waren ne ganze Menge)

Von Hand ändern war mühsam, aber bei einer Variante mit min/max Auswertung erschien mir

Also habe ich Allgaeuers Methode angewandt, um einen Monatswechsel zu erzwingen. Hat geklappt. Es wurde aber kein event erzeugt, folglich keine Daten gelogged.

zielführender, da ich allerdings die Logs in Diagrammen darstelle fehlen mir nun die Einträge.

Habe das nur testweise an einem Device getan und frage mich ob man die Events erzwingen könnte?
Gibt es da eine Vorgehensweise?

Grüße
Knut

[andi11]

...nicht ganz: Es wird nicht "true" zurückgegeben, sondern jeweils ein nummerischer Wahrheitswert. Erst wird die Differenz dieser beiden Werte ermittelt und dann das Ergebnis mit HOURSECONDS multipliziert und zur bisherigen Tageswechsel-Zeit (im üblichen Sekunden-Format) addiert. Das ergibt also folgende Kombinationsmöglichkeiten für die Verschiebung der Tageswechsel-Zeit:

(0 - 0) * 3600 = 0        (Wi "jetzt" -> Wi in 24h)
(0 - 1) * 3600 = -3600 (Wi "jetzt" -> So in 24h)
(1 - 1) * 3600 = 0        (So "jetzt" -> So in 24h)
(1 - 0) * 3600 = 3600  (So "jetzt" -> Wi in 24h)

Diese Berechnungsmethode sollte also jedenfalls dann passen, wenn sie ab 0:00 Uhr und vor 2:00 bzw. 3:00 Uhr angewendet wird.

ah so wie du es beschreibst ist es klarer. Allerdings ist in der Modulhilfe auch ein Tageswechsel in der Früh vorgeschlagen z.b. bei Wetter (ich kann nicht beurteilen ob das Sinn macht) Das wäre dann deutlich nach 3Uhr. Du küpfst deinen Vorschlag das Zeitfenster Tageswechsel zwischen 0 und 3Uhr. Aber ist das überhaupt nötig? Es sollte doch auch klappen mit einem anderen Fenster wenn ich nach deiner Liste gehe.

[KölnSolar]

Hallo Knut,

Habe das nur testweise an einem Device getan und frage mich ob man die Events erzwingen könnte?
Gibt es da eine Vorgehensweise?

Mit der Allgaeuer-Methode hatte ich ja zumindest keine events(bzw. Logeinträge) beobachten können.

Wenn Du nun ein raw definition im frontend des devices machst, siehst Du ja ne Menge setstate. Wenn Du nun im raw-Editor alles löschst bis auf die gewünschte Zeile

Code Auswählen Erweitern

setstate RPi_OW_TA 2021-11-02 00:37:47 statTemperatureMonthLast Min: 3.437 Avg: 12.246 Max: 21.562, diese dann änderst in

Code Auswählen Erweitern

setreading RPi_OW_TA statTemperatureMonthLast Min: 3.437 Avg: 12.246 Max: 21.562(wichtig: aus setstate wird setreading), dann wird ein event ausgelöst und dieses löst einen Logeintrag aus. Allerdings mit AKTUELLEM timestamp. Ich weiß nicht, ob Dir das genügt.(Ggfs. später den timestamp im Log anpassen)

Grüße Markus

[KNUT345]

Hallo Markus,
ja sowas habe ich gesucht.

Danke und Grüße

[Beta-User]

ah so wie du es beschreibst ist es klarer. Allerdings ist in der Modulhilfe auch ein Tageswechsel in der Früh vorgeschlagen z.b. bei Wetter (ich kann nicht beurteilen ob das Sinn macht) Das wäre dann deutlich nach 3Uhr. Du küpfst deinen Vorschlag das Zeitfenster Tageswechsel zwischen 0 und 3Uhr. Aber ist das überhaupt nötig? Es sollte doch auch klappen mit einem anderen Fenster wenn ich nach deiner Liste gehe.

Offen gestanden, war ich heute morgen schlicht nicht sicher, wie es sich in anderen Konstellationen verhält. An sich müßte das "immer" passen, wobei es eventuell eine Ausnahme gibt, wenn man grade für den Zeitpunkt der Umstellung am nächsten Tag fragt... (Wer Lücken für Sonder-sonder-Konstellationen findet, darf sie behalten oder bessere Vorschläge machen...).

[tupol]

Bei mir ist (mal wieder) die SD-Karte von der Raspberry Pi abgeschmiert. Wird aber leider noch eine Weile dauern bis ich dies und die Bug hier fixen kann.

[andi11]

meine Erfahrung mit Raspi und FHEM mittlerweile: SD Karte loswerden, man merkt wenn man Pech hat lange nichtmal dass Sie defekt ist. Bis zum Neustart z.b.....

[Beta-User]

Beileid.

Nachtrag noch zu dem Patch-Vorschlag: Da der Tageswechsel bei statistics verschoben werden kann (und hier sekundengenau gerechnet wird), gibt es uU. Probleme, wenn jemand den Tagesanfang genau auf 2:00 Uhr bzw. 3:00 Uhr legt. Evtl. könnte man in der commandref erläutern, dass diese beiden Werte (7200 und 10800) nicht zu empfehlen sind, alles andere sollte unschädlich gehen. Alternativ müßte man die Rechnerei so umstellen, dass diese beiden Zeitpunkte nicht getroffen werden können...

[rob]

...was passiert, wenn jemand den dayChange um genau 2h (bzw. 3h) verschiebt...

...gibt es uU. Probleme, wenn jemand den Tagesanfang genau auf 2:00 Uhr bzw. 3:00 Uhr legt...

Ich hab kurzerhand im Testsystem geschaut, ob mir etwas auffällt ohne Patch von #326 im Vergleich zu mit Patch. Bin mir allerdings unschlüssig, ob mein Testszenario überhaupt Sinn macht 
Habe aus Post #1 die Rawdef hergenommen und die Zeit verstellt auf 2Uhr und 3Uhr. Wahrscheinlich reicht das noch nicht ans fragliche Szenario heran.
Welche Devices soll ich mal testweise anlegen, um das System an der richtigen Stelle zu kitzeln? Einen periodischen Counter könnte ich z.B. mit einem endlosen at simulieren, das alle 10sec. einen Counter setzt o.ä.

VG
rob

[Beta-User]

Na ja, es sollte dann noch (mind) ein zu überwachendes Device geben (also "stat.*"-Readings dort erzeugt und optimalerweise geloggt werden), und dann sollte eben der fingierte Monatswechsel Ende Okt. drüber laufen, also von vor der Uhrzeitumstellung bis nach dem Monatswechsel.

Wann du startest, ist egal, wichtig wäre nur, dass nicht grade das Attribut "periodChangePreset" auf 7200 bzw. 10800 gesetzt wird (nur einer der beiden Werte ist bei dieser Art Wechsel potentiell kritisch, und ich will mir grade nicht das Hirn zermartern, welcher davon (vielleicht?...)).

Ziel sollte sein, dass der Tageswechsel dann wirklich um 00:00 Uhr stattfindet (ab dann gibt es "lastday"-Readings) und der Monatswechsel nicht ausfällt, also auch da wieder saubere "Wechselreadings" erzeugt werden.

PS: DANKE für's Aufgreifen der Testanfrage!!!