[vz-users] Performance, Datenbereinigung, Gesamtzähler als virtueller Channel

[Heiko Baumann]

Ich muss da nochmal nachfragen:

welchen Kanal-Typ muss ich wählen, wenn ich als value bereits einen 
absoluten Wert in der data-Tabelle habe?
Ich habs mal mit dem normalen power und eletric meter probiert, aber 
beides stimmt nicht.
Als Verbrauch brauch ich dann ja auch nicht das Integral unter der 
Kurve, sondern letztlich nur die Differenz zwischen End- und Startwert.
Beim Typ "Radioaktivität" wird zumindest genau der Wert in der Tabelle 
angezeigt, die Einheit müSv stimmt halt nicht so ganz :(

Gibts da schon was fertiges oder muss ich das umbiegen?

Danke.. Heiko



Am 09.10.2013 09:44, schrieb Heiko Baumann:
> Hi!
>
> @ Andreas: muss ich mal ausprobieren, wie ich deine Files aus dem Git 
> bekomm - hab das noch nie gemacht.
>
> Ich hab für mich einfach mal etwas probiert und eine StoredProcedure 
> geschrieben, die basierend auf Bernds mysql-Event innerhalb eines 
> bestimmten Intervalls x den Verbrauch y zum bestehenden Wert z des 
> Gesamtzählers addiert.
> Per Event wird diese SP dann stündlich angestoßen.
>
> Sieht grundsätzlich schon mal gut aus, hab aber wohl noch ein 
> Rechenproblem:
> - mein S0-Zähler(Typ "Power") hat die Auflösung 1000
> - den Stromverbrauch ermittle ich dann über sum(value)/1000
>
> Diesen Wert will ich dann also zum vorherigen Stand addieren und als 
> Gesatmzählerstand als value in die data-Tabelle schreiben und später 
> im Frontend anzeigen. Welchen channeltyp muss ich dafür 
> wählen(Strommesser, Stromsensor, Stromzähler)? Die automatische 
> Achsskalierung ist dann noch so ein weiteres Problem, z.B hat mein 
> Zähler 9750kWh - damit sind dann alle Einzelzähler im Watt-Bereich 
> nutzlos. Wobei, die Gesamtzähler landen dann in einer Gruppe, die man 
> ein- und ausblenden kann. Ok, kein Problem.
>
> LG Heiko
>
>
> Am 08.10.2013 18:51, schrieb Andreas Goetz:
>> Hallo Zusammen,
>>
>> ich habe mal eine _allererste_ Näherung einer Aggregationsfunktion 
>> zusammengedübelt, siehe hier:
>>
>> https://github.com/andig/volkszaehler.org/commit/b9440a5c058f79bdbb9bf84697d074e614c9f610
>>
>> Der Commit sollte selbsterklärend sein; für eine endgültige Lösung 
>> fehlt aber noch einiges Beiwerk. Wichtig wären Tester die auch etwas 
>> anderes als nur Impulszähler im Einsatz haben...
>>
>> vg
>> Andreas
>>
>>
>>
>> 2013/10/8 Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>>
>>
>>     Hallo Bernd,
>>
>>     bei mir ist das Thema im Rahmen von VZmon auch wieder aktuell.
>>     Ich überlege derzeit, wie man eine Aggregationslösung auf
>>     Datenbankende für VZ möglichst minimal-invasiv integrieren kann.
>>
>>     Dabei geht es mir vor allem darum, aggregierte Sichten
>>     (Monatserzeugung je Tag, Jahreserzeugung pro Monat) zu
>>     generieren. Auf meinem Raspi sind jetzt ca. 300k Datensätze im
>>     5min-Abstand, da wird es schon sehr eng.
>>
>>     Lösungsansatz:
>>     - Tagesaggregate per Stored Proc erzeugen
>>     - Tagesaggrefate in der Middleware nutzen wenn aggregierte
>>     Abfragen (Group by...) auftreten
>>
>>     Problem:
>>     - Behandlung der aktuellem Zeitscheibe (z.B. Tag)
>>     - Behandlung der Randbedingungen from...to, insbesondere wenn
>>     diese nicht auf den Tagesgrenzen liegen
>>
>>     Wenn's hier clevere Ideen gibt kommen wir zusammen sicher zu
>>     einer schicken Lösung.
>>
>>     vg
>>     Andreas
>>
>>
>>
>>
>>     2013/10/7 Bernd Gewehr <Bernd at gewehr.net <mailto:Bernd at gewehr.net>>
>>
>>         -----Ursprüngliche Nachricht----- From: Heiko Baumann
>>         Sent: Sunday, October 06, 2013 7:47 PM
>>
>>         To: volkszaehler-users at lists.volkszaehler.org
>>         <mailto:volkszaehler-users at lists.volkszaehler.org>
>>         Subject: Re: [vz-users] Performance, Datenbereinigung,
>>         Gesamtzähler als virtueller Channel
>>
>>
>>             Meinst Du das hier?
>>             http://www.mail-archive.com/volkszaehler-users@lists.volkszaehler.org/msg00490.html
>>
>>
>>         Hallo Bernd, genau das meinte ich - glaub ich :)
>>         Vielen Dank!
>>
>>         Müsste soweit auch funktionieren, nur stellen sich zwei Fragen:
>>         1) zumindest mein Raspi raucht ab und zu mal ab und steht
>>         dann für eine
>>         gewisse Zeit. Wie korrigierst du solche Fälle?
>>         2) Du ratterst mit der Query ja durch den kompletten
>>         Datenbestand, das
>>         dauert und erzeugt viel Last. Wie sind deine Erfahrungen damit?
>>         Evtl. Alternative: man berechnet nur täglich, was tatsächlich
>>         dazu
>>         gekommen ist und addiert den Wert zum Vortages-Stand.
>>
>>         Ich werd mal bisserl probieren... auf jeden Fall Danke!
>>
>>         Also bei mir ist das jetzt sehr lange erfolgreich im Einsatz.
>>         Die Abfragezeiten sind im Bereich einige 100 ms und scheinen
>>         den sonstigen Betrieb nciht zu stören.
>>
>>         Ich nutze jede Nacht das vzcompress2 Script, das hält die
>>         alten Daten im Zaum...
>>
>>         Ich habe zwar inzwischen einige Probleme mit einer defekten
>>         MySql-Tabelle, schiebe dies aber nicht auf die stored
>>         procedure. Analyse läuft.
>>
>>         Alles in Allem hätte ich aber gern im Frontend einen kleinen
>>         Kasten oben links oder rechts, in dem die Zählernummern und
>>         Zählerstände meiner Zähler aggregiert angezeigt werden, ohne
>>         solche Fummelei zu betreiben... Ich kann's nur leider nicht
>>         entwickeln.
>>
>>         Gruß, Bernd
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20131010/be4bb69d/attachment.html>