seit Rev. 16117 von 98_SVG.pm kein Jahreswechsel im Jahresplot mehr möglich

Begonnen von pappn, 20 Februar 2018, 20:18:22

Vorheriges Thema - Nächstes Thema

pappn

Seit Rev. 16117 der 98_SVG.pm kann ich nicht mehr über die "prev" und "next" Pfeile von einem Jahr auf das Vorherige oder Nächste Jahr wechseln. Mit Rev. 16025 klappt das hingegen (reproduzierbar) einwandfrei.

An der Def wurde nichts geändert.
defmod 05_Jahresuebersicht SVG BrennerGraphDaten.File:BrennerJahresuebersicht:CURRENT
attr 05_Jahresuebersicht fixedrange year
attr 05_Jahresuebersicht group Verbräuche Monats-/Jahresübersicht
attr 05_Jahresuebersicht label sprintf("Jahresübersicht (Verbrauch gesamt:%.2f Liter)", $data{sum3}-$data{firstval3}+$data{sum2}-$data{firstval2})
attr 05_Jahresuebersicht plotsize 900,220
attr 05_Jahresuebersicht room 01 Heizung


Alle anderen Übersichten Tag, Woche und Monat sind nicht betroffen.

Was tun?
"When all else fails, read the instructions."

CUL868, RFXTFX433 und CCU3
FS20, S300TH, UNIRoll, Homematic IP, OZW672, diverse HOMEEASY, IT kompatible und China Zeugs

rudolfkoenig


pappn

Danke für die schnelle Reaktion. Bewegung durch die Jahre funktioniert wieder. Leider scheint jetzt allerdings das letzte Element der Reihe zu fehlen. Die Berechnung in der Titelleiste stimmt daher auch nicht. (Siehe Anhang)
"When all else fails, read the instructions."

CUL868, RFXTFX433 und CCU3
FS20, S300TH, UNIRoll, Homematic IP, OZW672, diverse HOMEEASY, IT kompatible und China Zeugs

rudolfkoenig

Von wann genau ist das letzte Element der Reihe?
Der aktuelle Kode nimmt alles von Jan01 00:00:00 bis Dec31 23:59:59, jeweils inklusive.
Die alte Variante hat bis Jan01 00:00:01 des Folgejahres inklusive genommen, was mAn falsch ist.

pappn

die letzten Einträge im Log sehen wie folgt aus:
2017-12-31_24:00:00 Brenner_HZG1 appOpHoursPerDay: 0
2017-12-31_24:00:00 Brenner_HZG1 appOpHoursPerWeek: 28.4383333333333
2017-12-31_24:00:00 Brenner_HZG1 appOpHoursPerMonth: 161.311666666666
2017-12-31_24:00:00 Brenner_HZG1 appOpHoursPerYear: 895.052499999999
2017-12-31_24:00:00 Brenner_WW1 appOpHoursPerDay: 0
2017-12-31_24:00:00 Brenner_WW1 appOpHoursPerWeek: 4.21166666666666
2017-12-31_24:00:00 Brenner_WW1 appOpHoursPerMonth: 17.4569444444443
2017-12-31_24:00:00 Brenner_WW1 appOpHoursPerYear: 182.811111111109
2017-12-31_24:00:00 BrennerTest1 appOpHoursPerDay: 0
2017-12-31_24:00:00 BrennerTest1 appOpHoursPerWeek: 32.6516666666667
2017-12-31_24:00:00 BrennerTest1 appOpHoursPerMonth: 178.771944444444
2017-12-31_24:00:00 BrennerTest1 appOpHoursPerYear: 1071.01166666666
2017-12-31_24:00:00 cp_S300TH T_avg_day: 9.6
2017-12-31_24:00:00 cp_S300TH T_max_day: 12.8
2017-12-31_24:00:00 cp_S300TH T_min_day: 3.9
2017-12-31_24:00:00 cp_S300TH T_avg_month: 2.0
2017-12-31_24:00:00 cp_S300TH T_max_month: 12.8
2017-12-31_24:00:00 cp_S300TH T_min_month: -4.2


Für die Jahresübersicht relevant sind aber nur:
...
2017-12-31_24:00:00 BrennerTest1 appOpHoursPerMonth: 178.771944444444
...
2017-12-31_24:00:00 cp_S300TH T_avg_month: 2.0
...

Alle Werte mit diesem Timestamp sind aber "händisch" nachgetragen, um die vollständigen Jahreswerte zu haben. Insofern könnte ich natürlich auch den Timestamp anpassen...
"When all else fails, read the instructions."

CUL868, RFXTFX433 und CCU3
FS20, S300TH, UNIRoll, Homematic IP, OZW672, diverse HOMEEASY, IT kompatible und China Zeugs

rudolfkoenig

Eine Uhrzeit 24:00:00 ist nicht definiert, mWn gibt es nur 23:59:59, selbst die Schaltsekunde (23:59:60) dringt nicht zu den Programmen durch.
FileLog ist relativ tolerant, was das betrifft, aber die DB-Leute sind Spassverderber, und bestehen auf gueltige Datumsfelder :)

pappn

Hab ich mir nach deinem Beitrag schon gedacht. Ich korrigiere das. Danke für die Mühe.
Noch eine kleine Frage: Es scheint so zu sein, dass für die Tagesübersichten die Einträge für den nächsten Tag mit 00:00:00 noch mitgenommen werden.

Beispiel:
Folgende Werte nehme ich für meine Tagesübersicht.
Von
...
2018-02-20_00:00:00 Brenner_WW1 appOpHoursPerDayTemp: 0
...
2018-02-20_00:00:00 BrennerTest1 appOpHoursPerDayTemp: 0
...
2018-02-20_00:00:00 Brenner_HZG1 appOpHoursPerDayTemp: 0
...
Bis ...
2018-02-20_23:00:00 Brenner_WW1 appOpHoursPerDayTemp: 0.508333333333333
...
2018-02-20_23:40:39 BrennerTest1 appOpHoursPerDayTemp: 7.91083333333333
...
2018-02-20_23:40:39 Brenner_HZG1 appOpHoursPerDayTemp: 7.40194444444444

Dann geht es wieder mit ...
2018-02-21_00:00:00 BrennerTest1 appOpHoursPerDayTemp: 0
...
2018-02-21_00:00:00 Brenner_HZG1 appOpHoursPerDayTemp: 0
...
2018-02-21_00:00:00 Brenner_WW1 appOpHoursPerDayTemp: 0
weiter.
Wenn ich nun in der Historie zurück gehe, ist in der Darstellung der letzte Wert immer auf 0 gezogen und das Attribut sprintf("Verbrauch (Gesamt:%.2f Liter - Heizung:%.2f Liter - Warmwasser:%.2f Liter)", $data{currval5}, $data{currval7}, $data{currval6}) für die Titelzeile liefert als Wert 0 für alle $data{currvalx} (siehe Screenshot). Wenn ich mir im Plot Editor den pre pocessed input für z.B. Brenner_WW1.appOpHoursPerDayTemp ansehe, erscheint als letzter Wert der nächste Tag 2018-02-21_00:00:00 0. 2018-02-20_00:00:00 0.873148148425
2018-02-20_00:00:00 0
2018-02-20_01:00:00 0
...
2018-02-20_04:29:58 0
2018-02-20_04:39:58 0.253086419833334
2018-02-20_05:00:00 0.253086419833334
...
2018-02-20_11:39:59 0.253086419833334
2018-02-20_11:49:59 0.506172839666666
2018-02-20_13:00:01 0.506172839666666
...
2018-02-20_18:00:00 0.506172839666666
2018-02-20_18:40:50 0.506172839666666
2018-02-20_18:51:20 0.771913580491666
2018-02-20_19:46:18 0.771913580491666
...
2018-02-20_23:00:00 0.771913580491666
2018-02-21_00:00:00 0.771913580491666
2018-02-21_00:00:00 0
#4:Brenner_WW1.appOpHoursPerDayTemp\x3a::$fld[3]*1.518518519


Lässt sich das korrgieren?
"When all else fails, read the instructions."

CUL868, RFXTFX433 und CCU3
FS20, S300TH, UNIRoll, Homematic IP, OZW672, diverse HOMEEASY, IT kompatible und China Zeugs

pappn

Habe gerade noch festgestellt, dass die Werte für das Jahresende nur korrekt angezeigt werden, wenn ich sie auf xxxx-12-31_23:59:58 setze. Stehen sie auf 23:59:59 weden sie nicht angezeigt...
"When all else fails, read the instructions."

CUL868, RFXTFX433 und CCU3
FS20, S300TH, UNIRoll, Homematic IP, OZW672, diverse HOMEEASY, IT kompatible und China Zeugs

rudolfkoenig

ZitatEs scheint so zu sein, dass für die Tagesübersichten die Einträge für den nächsten Tag mit 00:00:00 noch mitgenommen werden.
Ja, damit die Berechnung der Grenzen einfacher ist.
Ich habe das geaendert, damit jeweils korrekte bis-Werte angegeben werden (23:59:59 statt naechster Tag 00:00:01), musste aber dafuer alle Berechnungen anpassen. Ich habe zwar getestet, bin trotzdem unsicher, ob alles passt.

ZitatHabe gerade noch festgestellt, dass die Werte für das Jahresende nur korrekt angezeigt werden, wenn ich sie auf xxxx-12-31_23:59:58 setze. Stehen sie auf 23:59:59 weden sie nicht angezeigt...
Das kann ich nicht nachvollziehen.

pappn

Zitat von: rudolfkoenig am 25 Februar 2018, 21:58:26
Ja, damit die Berechnung der Grenzen einfacher ist.
Ich habe das geaendert, damit jeweils korrekte bis-Werte angegeben werden (23:59:59 statt naechster Tag 00:00:01), musste aber dafuer alle Berechnungen anpassen. Ich habe zwar getestet, bin trotzdem unsicher, ob alles passt.
Das kann ich nicht nachvollziehen.
Also bei mir sieht das sehr gut aus.

Gesendet von meinem SM-T580 mit Tapatalk

"When all else fails, read the instructions."

CUL868, RFXTFX433 und CCU3
FS20, S300TH, UNIRoll, Homematic IP, OZW672, diverse HOMEEASY, IT kompatible und China Zeugs

JoeALLb

Hallo zusammen.

(Vermutlich) Durch die hier gemachten Änderungen (soweit ich es überblicke) stimmen aktuell die Datumsgrenzen in DbLog nicht mehr, wo
Abfragen aktuell nur noch bis exklusive 23:59:59 gemacht werden. Der DbLog-Tag als Plot endet also um 23:59:58.


Zitat von: rudolfkoenig am 21 Februar 2018, 20:09:21
Von wann genau ist das letzte Element der Reihe?
Der aktuelle Kode nimmt alles von Jan01 00:00:00 bis Dec31 23:59:59, jeweils inklusive.
Die alte Variante hat bis Jan01 00:00:01 des Folgejahres inklusive genommen, was mAn falsch ist.


Das Ende eines Plots sollte nicht 23:59:59 sein.
auch 00:00:01 des Foldetags (inklusive) aus der Vorversion ist nicht korrekt, da die erste Sekunde natürlich schon zum Folgetag gehört.
00:00:00 gehört jedoch nocht zum alten tag, da alles was zwischen 23:59:59 und 00:00:00 passiert, noch zum alten tag gehört.
Die letzte millisekunde gehört ebenfalls noch zumalten Tag! erst 00:00:00:001 gehört theoretisch zum neuen Tag!

00:00:00 ist aber auch der perfekte Startpunkt (un dEndpunkt) bei Plots für den neuen Tag!
Zusätzlich hat dies den Charme, dass man nur einen Logeintrag pro Tag für unveränderte Werte benötigt, da der Plot immer von
"26.6.2018 00:00:00" bis "27.6.2018 00:00:00" als Linie eingezeichnet wird.

sG Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

rudolfkoenig

Zitat00:00:00 gehört jedoch nocht zum alten tag, da alles was zwischen 23:59:59 und 00:00:00 passiert, noch zum alten tag gehört.
Das stimmt, allerdings betrifft das nur Systeme, die mit mehr als Sekundengenauigkeit die Daten speichern, FileLog also nicht.

Ich gebe Dir Recht, dass die Methode "von inklusive, bis exklusive" die richtige Loesung ist, allerdings waere eine Umstellung in SVG aufwendig. Ich schlage die meiner Ansicht nach relativ unaufwendige Anpassung in DbLog vor: von und bis jeweils inklusive, und alle Zeitstempel auf Sekunde abgerundet.