[vz-users] Peaks im Frontend - ACE3000

[Andreas Goetz]

PS.: https://github.com/volkszaehler/vzlogger/issues/98

2015-01-02 15:53 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:

> Ich nochmal...
>
> 2015-01-02 15:09 GMT+01:00 Martin Heinze <martin-heinze at gmx.net>:
>
>> ...
>>
>> Gerade bei Zählerständen ist es nicht wirklich notwendig zu jeder
>> Auslesung einen Wert in der DB zu speichern
>
>
> Sehe ich auch so, ist allerdings vom Anwendungfall abhängig.
>
> Es sollte relativ einfach sein einen Konfigparameter in der Art von
> "ignoreDuplicateReadings" oder "minReadingDelta" (flexible) zu bauen den
> der vzlogger mit dem vorhergegenden Absolut(!)wert vergleicht und nur
> schreibt wenn größer. Damit kann man sich Roundtrips in die Middleware/DB
> ersparen.
>
> Ich denke mbehr1 hätte das in ca 15min fertig ;)
>
> Viele Grüße,
> Andreas
>
>
> -----Original Message-----
> From: Stefan <stefan at stinkes.de>
> Sender: "volkszaehler-users" <
> volkszaehler-users-bounces at demo.volkszaehler.org>Date: Fri, 02 Jan 2015
> 10:55:25
> To: volkszaehler.org - users<volkszaehler-users at demo.volkszaehler.org>
> Reply-To: "volkszaehler.org - users" <
> volkszaehler-users at demo.volkszaehler.org>
> Subject: [vz-users] Peaks im Frontend - ACE3000
>
> Hallo,
>
> ich würde gerne das Thema nochmals aufgreifen...
>
> Der vzlogger läuft und übergibt die Zählstände  korrekt an die Datenbank.
>
>         id absteigend
> <
> https://dbadmin.hosteurope.de/phpmyadmin/sql.php?db=db1007889-vz&table=data&sql_query=SELECT+%2A+FROM+%60data%60+ORDER+BY+%60data%60.%60id%60++ASC&token=d9f0d2afcdc326804f0232364bab377d&phpMyAdmin=ac08f8499e44fc509b4ce698108598344c43c745
> >
>         channel_id
> <
> https://dbadmin.hosteurope.de/phpmyadmin/sql.php?db=db1007889-vz&table=data&sql_query=SELECT+%2A+FROM+%60data%60+ORDER+BY+%60data%60.%60channel_id%60+ASC&token=d9f0d2afcdc326804f0232364bab377d&phpMyAdmin=ac08f8499e44fc509b4ce698108598344c43c745
> >
>         timestamp
> <
> https://dbadmin.hosteurope.de/phpmyadmin/sql.php?db=db1007889-vz&table=data&sql_query=SELECT+%2A+FROM+%60data%60+ORDER+BY+%60data%60.%60timestamp%60+ASC&token=d9f0d2afcdc326804f0232364bab377d&phpMyAdmin=ac08f8499e44fc509b4ce698108598344c43c745
> >
>         value
> <
> https://dbadmin.hosteurope.de/phpmyadmin/sql.php?db=db1007889-vz&table=data&sql_query=SELECT+%2A+FROM+%60data%60+ORDER+BY+%60data%60.%60value%60+ASC&token=d9f0d2afcdc326804f0232364bab377d&phpMyAdmin=ac08f8499e44fc509b4ce698108598344c43c745
> >
>
>
>
>
>         2450    1       1420191247191   13954.6
>
>
>
>         2449    1       1420191239762   13954.6
>
>
>
>         2448    1       1420191221278   13954.6
>
>
>
>         2447    1       1420191204351   13954.6
>
>
>
>         2446    1       1420191187170   13954.6
>
>
>
>         2445    1       1420191177159   13954.6
>
>
>
>         2444    1       1420191160738   13954.6
>
>
>
>         2443    1       1420191144217   13954.6
>
>
>
>         2442    1       1420191127033   13954.6
>
>
>
>         2441    1       1420191119031   13954.6
>
>
>
>         2440    1       1420191102393   13954.6
>
>
>
>         2439    1       1420191085537   13954.6
>
>
>
>         2438    1       1420191066967   13954.6
>
>
> Im Frontend werden die Verbräuche als Peaks angezeigt und zwischen den
> Zählständen Nullen "eingefügt".
>
>
>
> Die Statistik des Kanals kommt grob hin (Durchschnitt und Verbrauch)
> aber Min und Max. sind nicht korrekt.
>
> Wie seht ihr das?
>
> Grüße
>
> Stefan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150102/7ee99813/attachment-0001.html>