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

Andreas Götz cpuidle at gmail.com
Thu Jul 9 18:44:34 CEST 2015


> Am 09.07.2015 um 18:41 schrieb Christian Schnellrieder <schnellrieder.cs at gmail.com>:
> 
> Hallo.
> 
>> * 1 * * *  php /var/www/volkszaehler.org/misc/tools/aggregate.php run
>> -m delta -l day >/dev/null
> 
> >
> >Also jeden Tag- ok
> 
> Ist das nicht ein wenig heftig das jeden Tag das script 60 mal ausgeführt wird?
> 1:00, 1:01, 1:02, 1:03 etc
> 

Autsch, da hast Du recht. Bei. Zweiten Durchlauf- so der erste fertig ist- sollte es aber nix finden. Besser wäre

0 1 * * *

Danke für den Hinweis!

> Grüße
> 
> 
>> 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
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150709/95f224d1/attachment-0001.html>


More information about the volkszaehler-users mailing list