[vz-users] Auflösung der Diagramme im Frontend variiert

[Frank Richter]

Hallo Andreas,

ich schreib mal hier weiter: Ich habe wie vorgeschlagen die Tabelle
aggregate geleert und ohne Minutenwerte neu aufgebaut. Die Aggregation
lief in unter einer Minute durch, da mein Datenbestand ja noch nicht
so groß ist. Leider hat sich dadurch am beschriebenen Problem nichts
geändert. Überschneidungen bei der Aggregation können wir wohl
ausschließen, denn außer dem full-Durchlauf ist da noch nichts
passiert.
Was ich noch nicht verstehe: Warum ist die aggregate-Tabelle überhaupt
beteiligt, wenn ich z.B. den Zoom auf 1h einstelle? Genug Daten für
eine vernünftige Darstellung sind da doch eh nicht drin, nicht einmal
mit Minutenwerten.

Viele Grüße
Frank

Am 9. Juli 2015 um 18:28 schrieb Andreas Goetz <cpuidle at gmail.com>:
> Hi,
>
> 2015-07-09 17:14 GMT+02:00 Frank Richter <frank.richter83 at gmail.com>:
>>
>> Hi Andreas,
>>
>> du bist verdammt schnell...
>
>
> Danke ;)
>
>>
>>
>> Am 9. Juli 2015 um 16:40 schrieb Andreas Goetz <cpuidle at gmail.com>:
>> > Hi Frank,
>> >
>> > 2015-07-09 16:29 GMT+02:00 Frank Richter <frank.richter83 at gmail.com>:
>> >>
>> >> Hallo,
>> >>
>> >> mir ist gestern erstmals aufgefallen, dass mein VZ im Frontend beim
>> >> Zeichnen der Diagramme sehr unterschiedliche Auflösungen (Anzahl
>> >> Datenpunkte) wählt, obwohl die Rahmenbedingen wie Zoomstufe und
>> >> Datenbasis in der DB überall gleich sein müssten.
>> >
>> >
>> > Die Option heisst speedup in options.js.
>>
>> Steht bei mir auf 2. Kannst du kurz erklären, was die Option macht?
>
>
> Je höher der Wert desto "blockiger" die Anzeige weil weniger Daten
> verarbeitet werden- desto schneller aber auch.
>
>>
>> Aber vermutlich sollte sie für ein konstantes Anzeigeintervall doch
>> immer das gleiche machen, und nicht je nach Tageszeit unterschiedlich,
>> oder?
>
>
> Yep.
>
>>
>> >
>> >>
>> >> Konkretes Beispiel (siehe auch Screenshots): Meine 3 Zählerkanäle
>> >> werden von vzlogger mit 15s-Aggregation gemessen. Ich wähle im
>> >> Frontend Zoomstufe "Stunde". Zur aktuellen Zeit "Jetzt" sieht alles
>> >> gut aus, die Messintervalle von 15s lassen sich im Diagramm
>> >> nachvollziehen. Dann wandere ich mit << wiederholt rückwärts, bis zur
>> >> ersten Stunde des aktuellen Tages bleibt alles wie erwartet. Doch in
>> >> dem Moment, wo der Beginn des dargestellten Zeitraums in den Vortag
>> >> fällt, vergröbert sich die Darstellung massiv, das Intervall zwischen
>> >> zwei Punkten beträgt dann plötzlich über 2 Minuten, entsprechend grob
>> >> sieht der Chart aus. Auch mit weiterem Zoomen lassen sich nicht mehr
>> >
>> >
>> > Mhm. Komisch. Kannst Du mal schauen welche MW-URL da jeweils aufgerufen
>> > wird? Ändert die sich?
>>
>> Außer from= und to= ändert sich da nichts, ansonsten immer tuples=626
>> und die Liste der UUIDs.
>
>
> Mhm. Kein "group" Parameter? Dann sollte das in der Tat _immer_ gleich
> aussehen.
>
>> >
>> >> Punkte zum Vorschein bringen. Springt man weiter stundenweise zurück,
>> >> wird das Intervall mit jeder Stunde ein bisschen kürzer: Beim Zeitraum
>> >> 12-13 Uhr scheint das Intervall recht genau eine Minute zu sein. Noch
>> >> weiter vorne wird's noch besser, von 0:01-1:01 Uhr sind es zumindest
>> >> annähernd wieder die korrekten 15s. 0:00-1:00 Uhr klappt allerdings
>> >> nicht mehr, dann gibt es wieder grobe Treppen. Das ganze Spiel lässt
>> >> sich beliebig wiederholen: Früh am Tag = feine Auflösung, spät am Tag
>> >> = grobe Auflösung.
>> >> Auch andere Zoomstufen sind davon betroffen. Ein 12h-Ansicht der
>> >> ersten Tageshälfte (allerdings ohne 0:00 Uhr) sieht viel feiner aus
>> >> als eine der zweiten Tageshälfte.
>> >> Die unterschiedliche Detaillierung der Charts lässt sich auch mit den
>> >> Entwicklertools nachvollziehen: Je später am Tag, desto kleiner sind
>> >> die übertragenen Datenpakete (Zahlen dazu stehen im Dateinamen der
>> >> Screenshots).
>> >
>> >
>> > Wie loggst Du- immer im gleichen Zeitintervall?
>>
>> Die 3 eHZ-Zählerstände mit vzlogger und aggtime = 15s, natürlich 24/7.
>>
>> ...
>>
>> >> Eben habe ich entdeckt, dass sich der ganze Spuk beenden lässt, wenn
>> >> ich in der Konfiguration aggregate deaktiviere, aber das kann ja
>> >> eigentlich auch nicht die Lösung sein. Könnte es sein, dass aggregate
>> >> nicht mit den Kanälen klar kommt, die zeitweise (=nachts) keine Daten
>> >> liefern? Ich kann aber auch nicht sicher sagen, dass mit den 3
>> >
>> >
>> > Nein. Wie/wann aggregierst Du?
>>
>> Ich habe die cron-einträge aus dem Wiki übernommen, wobei die
>> Minuten-Werte wohl standardmäßig nicht verwendet werden (hast vor ein
>> paar Wochen mal geschrieben, und ich hab da bisher nichts geändert):
>>
>> * * * * *  php /var/www/volkszaehler.org/misc/tools/aggregate.php run
>> -m delta -l minute >/dev/null
>
>
> Also jede Minute- ok.
>
>>
>> 1 * * * *  php /var/www/volkszaehler.org/misc/tools/aggregate.php run
>> -m delta -l hour >/dev/null
>
>
> Also jede Stunde- ok.
>
>>
>> * 1 * * *  php /var/www/volkszaehler.org/misc/tools/aggregate.php run
>> -m delta -l day >/dev/null
>
>
> Also jeden Tag- ok.
>
>>
>> >> Zählerkanälen zuvor alles in Ordnung war, die sind ja von dem
>> >> Darstellungsproblem auch betroffen, obwohl sie kontinuierlich geloggt
>> >> werden. Bin gerade etwas ratlos...
>>
>
> Ich auch. Kann ich vllt. mal auf per Browser drauf schauen (pm)?
>
>>
>> >
>> > Kann es sein dass Du nachts aggregierst per cron und auf Daten schaust
>> > die
>> > vor und nach 0 Uhr liegen?
>>
>> s.o. - nachts, aber für eine Stundenansicht z.B. zwischen 22 und 23
>> Uhr darf doch das kein Problem sein, oder? Aber auch da habe ich
>> Treppen mit Schriitweite von 2 Minuten.
>>
>> >> Ich habe noch je 2 Screenshots von den 12h-Ansichten der Zähler und
>> >> von den 24h-Ansichten der Wechselrichter-Daten. Die haben wegen dem
>> >> Größen-Limit nicht mehr in die Mail gepasst. Wenn gewünscht, schicke
>> >> ich die gern noch hinterher.
>> >>
>> >> Viele Grüße
>> >> Frank
>> >
>> >
>> > Viele Grüße,
>> > Andreas
>> >
>>
>> Viele Grüße
>> Frank
>
>