[vz-users] S0-Zähler als aggregierter Leistungswert speichern

[Andreas Goetz]

Moin Jens,

2015-12-23 7:58 GMT+01:00 Jens <panterglas at web.de>:

> Hallo Andreas,
>
> Danke für die Information und Deine Hilfe. Da ich 5 S0-Zähler habe muss
> ich irgendwie die Daten ausdünnen, sonst wird mir die DB zu groß (Raspi
> wird langsam, Sicherung dauert ewig, etc.).
>

Langsam glaube ich tatsächlich nicht, denn dafür gibts ja genau die
Aggregation- aber Backup ist natürlich ein valider Punkt. Und wozu Daten
speichern die man nicht benötigt...


> Ich werde einfach komplett vom *s0vz_new* auf den *vzlogger* umstellen.
> Dort kann man bereits vor dem Schreiben in die DB die Impulse in der
> gewünschten Auflösung zusammenfassen (z.B.  "aggtime": 60).
>

Genau.


> Dann ist die Auflösung immer gleich und *aggregate.php *hat nicht mit
> unterschiedlichen Auflösungen zu kämpfen.
>

Und auch vzcompress brauchst Du nur noch wenn Du noch weniger Auflösung als
vom vzlogger erfasst haben willst.


> Das Problem mit der Kombination von *vzcompress2.php* und *aggregate.php*
> ist, dass *aggregate.php* im cronjob nur die Differenzdaten einbezieht.
> Durch *vzkompress2.php* ändern sich aber auch die Originaldaten. Denke,
> da kommt die Unstimmigkeit bei der Anzeige her.
>

Komplett daneben ;) Ich dachte ich hätte es ausreichend erklärt:

> Also nicht gleiche Zeiteinteilung sondern gleiche Menge Daten!
> Und jetzt sind bei Dir die Daten zwischen den Wochen um den 9.12.
unterschiedlich verteilt- Woche vorher 32tsd, Woche hinterher 86tsd (vmtl.
wg vzcompress). Daher sieht also- wenn Du genau auf der Grenze Bist- der
erste Teil komisch aus.

Löscht man nach der Ausdünnung durch *vzcompress2.php* die
aggregierten (*aggregate.php
> clear*) und legt sie neu an, passt es wieder.
>

Glaube ich nicht (...) jedenfalls wenn Du jeweils auf Minuten aggregierst.
Es ist nämlich völlig egal ob ich Minutenauflösung aus der aggregate oder
der data Tabelle hole. Richtig ist aber: wenn vzcompress läuft muss man
sich bewusst sein dass ncoh Daten in aggregate stehen. Ggf. müssen diese
(falls höher aufgelöst als gewünscht) gelöscht werden. Ist bei Dir aber so
wie beschrieben nicht der Fall.

Wenn ichs immer noch nicht richtig erkläre schick mir einfach Deine Tel#
per PM ;)


> Wenn *vzlogger* jetzt noch die kW-Peaks nicht für die S0-Zähler schreibt,
> wär alles gut. Du schriebst, dass es was mit dem Entprellen zu tun haben
> könnte und dass es dafür einen Parameter gibt. Welchen denn, bzw. wo kann
> ich das nachlesen?
>

Ich rate nur, aber schau mal nach debounce_delay (
https://github.com/mbehr1/vzlogger/commit/17b497d5c2dcf54a1f11a80d97a4f30b33d0a83d)-
sollte auch im online config Editor zu finden sein (
http://volkszaehler.github.io/vzlogger/).


>
> Vielen Dank und vorweihnachtliche Grüße
> –Jens
>
>
> Viele Grüße,
Andreas


>
> Am 22.12.2015 um 18:21 schrieb Andreas Goetz <cpuidle at gmail.com>:
>
> Hallo Jens,
>
> danke für Deine DB. Ich habs gefunden- ist alles ok, sieht nur komisch
> aus. Das Frontend fordert sowas an:
>
>
> http://localhost:8888/vz/htdocs/middleware.php/data.json?from=1449594571755&to=1450199371755&
> *tuples=348&*uuid[]=231b9390-0f56-11e5-9cbe-354f27e140c4
>
> Bei Dir sind das:
>
> "rows":32273
>
> Also ne ganze Menge, davon werden aber nur 348 verwendet. Also zählt die
> MW durch- immer 32273/348 Datensätze in einen zusammenfassen und
> wegschicken. Also nicht gleiche Zeiteinteilung sondern gleiche Menge Daten!
>
> Und jetzt sind bei Dir die Daten zwischen den Wochen um den 9.12.
> unterschiedlich verteilt- Woche vorher 32tsd, Woche hinterher 86tsd (vmtl.
> wg vzcompress). Daher sieht also- wenn Du genau auf der Grenze Bist- der
> erste Teil komisch aus.
>
> Daher mein Tipp:
> - vzcompress nicht mehr verwenden da dank Aggregation nicht notwendig
> - falls doch dann über alle Zeitscheiben gleich, den Rest kann die
> Aggregation richten
>
> Viele Grüße,
> Andreas
>
>
>
> 2015-12-22 12:16 GMT+01:00 Jens <panterglas at web.de>:
>
>> Hallo Andreas,
>>
>> natürlich will ich helfen, wenn ich das kann. Ich habe Deine Mail so
>> verstanden, dass ich den Diskussionspfad nicht weiter verfolgen soll.
>>
>> Ich richte schnell einen dyndns ein, dann kannst du darauf zugreifen.
>> Leider muss ich aber erst wieder Aggregate.php starten, da ich alle
>> erzeugten Tabellen gelöscht habe, das wird sicher eine Weile dauern. Wie
>> kann ich Dir den Link zu meinem Raspi zukommen lassen, ohne dass ich den in
>> der Mailingliste für jeden öffentlich mache :)
>>
>> Danke und viele Grüße
>> -Jens
>>
>>
>> Am 22.12.2015 um 12:03 schrieb Andreas Goetz <cpuidle at gmail.com>:
>>
>> Moin,
>>
>> 2015-12-22 11:56 GMT+01:00 Jens <panterglas at web.de>:
>>
>>> Hallo Andreas,
>>>
>>> Danke für Deine Antwort. Ich bin mittlerweile einen großen Schritt
>>> weiter. Ich habe einfach mal *aggregate.php* mit dem Parameter *clear*
>>> ausgeführt und siehe da, in der Wochen- und Monatsansicht sind die Verläufe
>>> der S0-Zähler nun ähnlich wie bei dem Leistungszähler ausgeprägt (die Daten
>>> waren auch vorher schon 1-minütig vorhanden nur eben seltsam im Frontend
>>> angezeigt). Es wurde auch ganz sicher auf 60 Sekunden komprimiert, siehe
>>> config und man sieht das auch in der Datenbank selbst:
>>>
>>> (7*24*60*60)    => (1*60),      *// Older than 7 Days      Datapoint
>>> per 1 Minute*
>>> (30*24*60*60)   => (1*60),      *// Older than 30 Days     Datapoint
>>> per 5 Minutes*
>>> (6*30*24*60*60) => (1*60),     *// Older than 6 Month     Datapoint per
>>> 15 Minutes*
>>> (365*24*60*60)  => (1*60),     *// Older than 1 Year      Datapoint per
>>> 30 Minutes*
>>>
>>> Wenn man mit die Frontend-Beschleunigung *aggregate.php* eingeschaltet
>>> lässt, werden im Frontend die beschriebenen Verläufe für die S0-Zähler
>>> dargestellt. Zumindest das konnte ich nun herausfinden. Zoomt man weiter
>>> rein, passen die Verläufe besser besser (wie bereits in meiner Ausgangsmal
>>> beschrieben). Löscht man die zusätzlich erzeugten Tabellen, sind die
>>> Anzeigen auch in größeren Zoom-Stufen für die S0-Zähler OK.
>>>
>>
>> Darf ich mir das mal per HTTP anschauen (gerne PM)? Bei Zoom auf Tag wie
>> in Deinem Beispiel sollte der Verlauf bei Minutenaggregation immer noch
>> sehr flüssig aussehen- irgendwo ist da der Wurm drin.
>>
>>
>>>
>>> Nach dem Deaktivieren von *aggregate.php* bin ich mit der Anzeige der
>>> S0-Zähler vollkommen *glücklich* und das Datenaufkommen kann durch
>>> *vzcompress2.php* (sofern s0vz genutzt wird) oder eben gleich durch
>>> eine angepasste Erfassung mit dem *vzlogger* reduziert werden. Es ist
>>> also ein Frontendproblem in größeren Zoomstufen (täglich, wöchentlich,
>>> monatlich) in Verbindung mit der Darstellung der Werte über
>>> *aggregate.php *- zumindest bei mir.
>>>
>>> Ich verabschiede mich dann von diesem Thread und setze gleich mal einen
>>> neuen VZ auf der Basis des aktuellen Images auf, um den Fehler im
>>> „Igitt"-Frontend zu reproduzieren. Aktuell arbeite ich nämlich wieder mit
>>> dem „alten“ System.
>>>
>>
>> Mhm. Das ist schade. Wenn Du helfen willst dann: a) lass mich mal bitte
>> mit eingeschalteter Aggregation draufschauen und b) meld Dich wieder wenn
>> der js Fehler auftritt. Wenn der irgendwie reproduzierbar ist wird es auch
>> asap behoben...
>>
>>
>>> Danke und viele Grüße und frohe Weihnachten an alle
>>> -Jens
>>>
>>
>> Frohe Weihnachten,
>> Andreas
>>
>>
>>>
>>> Am 22.12.2015 um 11:39 schrieb Andreas Goetz <cpuidle at gmail.com>:
>>>
>>> Moin Jens,
>>>
>>> 2015-12-21 20:36 GMT+01:00 Jens <panterglas at web.de>:
>>>
>>>> Hallo Andreas, danke für die Antwort.
>>>>
>>>> Am 21.12.2015 um 18:19 schrieb Andreas Goetz <cpuidle at gmail.com>:
>>>>
>>>> Hallöchen,
>>>>
>>>> 2015-12-21 10:02 GMT+01:00  <Panterglas at web.de>:
>>>>
>>>>> Hallo VZ-Gemeinde,
>>>>>
>>>>> ich betreibe seit 2 Jahren einen VZ mit 5 S0-Zählern und 18
>>>>> Temperatursensoren und nutze dafür Udo’s Erweiterung.
>>>>>
>>>>
>>>> ...
>>>>
>>>>
>>>>> Nun zu meinem Anliegen.
>>>>>
>>>>> Für die S0-Zähler nutze ich *s0vz_new* und *1wirevz*. Mit beiden habe
>>>>> ich sehr gute Erfahrungen gemacht. Wegen der S0-Zähler ist die Datenbank
>>>>> allerdings entsprechend stark gewachsen. Zwecks Ausdünnung der Daten habe
>>>>> ich *vzcompress2.php *versucht. Das Ergebnis gefällt mir für die S0
>>>>> Zähler allerdings gar nicht. Das Verbrauchsprofil wird bereits bei einer
>>>>> 1-minütigen Aggregation nicht mehr sauber dargestellt.
>>>>>
>>>>
>>>> Wenn da so ist wärs evtl. ein Fehler. Bitte issue auf GitHub aufmachen
>>>> mit konkreter Beschreibung. "Nicht mehr sauber" reicht nicht ;)
>>>>
>>>>
>>>> Beispiel ohne Komprimierung (S0-Originaldaten für S00_Gesamt und S00_PV
>>>> sind 1-minütige Leistungswerte direkt vom Wechselrichter)
>>>>
>>>> Siehe Bild: yx23HR.png
>>>> <https://imagizer.imageshack.us/v2/537x407q90/903/yx23HR.png>
>>>>
>>>> Beispiel mit Komprimierung über vzcompress2.php für beide. Die
>>>> Komprimierung ist in vzcompress2.php auf 60 Sekunden eingestellt.
>>>>
>>>> Siehe Bild: W8Yex2.png
>>>> <https://imagizer.imageshack.us/v2/537x417q90/907/W8Yex2.png>
>>>>
>>>> Wie Du siehst, werden die S0-Daten derart modifiziert, dass sich kein
>>>> vernünftiges Bild mehr ergibt.
>>>>
>>>
>>> Was ich vor allem sehe ist dass da nicht auf Minuten aggregiert wird
>>> sondern deutlich mehr. These: Deine vzcompress Konfiguration ist einfach
>>> falsch. mit welchen Einstellungen läuft es denn?
>>>
>>> Das ist mit dem Impuls-Timestamp-Verfahren im Frontend nicht gut
>>>> machbar. Stellt man den Zoom näher, wird’s zwar etwas besser, den
>>>> ursprünglichen Verlauf erkennt man jedoch nicht mehr gut. Aggregiert man
>>>> Leistungsdaten, bleibt die Verlaufsstruktur um einiges besser erhalten. Das
>>>> liegt daran, das vzcompress2.php die Impulse über den eingestellten
>>>> Zeitraum zwischen zwei Datensätzen zählt und den Summenimpuls dann zum
>>>> passenden Timestamp einträgt. Ich lese den Code so: aus 1 Timestamp pro
>>>> Impuls werden dann z.B. 14 Impulse für einen definierten Timestamp; das
>>>> sieht im Frostend eben bescheiden aus. Zumindest kenne ich keine
>>>> Einstellung mit der man das verbessern kann, deshalb meine Frage.
>>>>
>>>>
>>>>
>>>>> Wendet man *vzcompress2.php* auf einen Leistungszähler oder auf die
>>>>> Temperaturen an, sieht das allerdings sehr gut aus. Nun würde ich gerne
>>>>> meine S0-Daten erfassen, aggregieren und als Leistungswert in der Datenbank
>>>>> speichern. Dafür habe ich mir den *vzlogger* in Version 0.5.0 (soll
>>>>> ja *1wirevz* und *s0vz* ersetzen) angeschaut und die S0-Zähler
>>>>> darüber ausgelesen.
>>>>>
>>>>
>>>> Warum willst Du das? Performance? Verwendest Du schon die Aggregation
>>>> der Middleware? Das hat alles nichts mit vzlogger zu tun….
>>>>
>>>>
>>>> Die Aggregation der Middelware nutze ich und ich weiß, dass das alles
>>>> nichts mit dem vzlogger zu tun hat. Ich dachte aber, dass ich die
>>>> Gelegenheit nutze kann, bereits vor dem schreiben in die Datenbank das
>>>> Datenaufkommen zu reduzieren und mich im Übrigen von s0vz und 1wirevz zu
>>>> verabschieden. In der vzlogger.conf sind sind die S0 Zähler wie folgt
>>>> angelegt, die 18 Temperatursensoren funktionieren tadellos.
>>>>
>>>> {
>>>>   "retry": 0,
>>>>   "daemon": true,
>>>>   "verbosity": 15,
>>>>   "log": "/var/log/vzlogger.log",
>>>>   "local": {
>>>>     "enabled": false,
>>>>     "port": 8080,
>>>>     "index": true,
>>>>     "timeout": 0,
>>>>     "buffer": 0
>>>>   },
>>>>   "push": [
>>>>     {
>>>>       "url": "http://127.0.0.1:5582"
>>>>     }
>>>>   ],
>>>>   "meters": [
>>>>     // Sensor 1
>>>>     {
>>>>       "enabled": true,
>>>>       "allowskip": false,
>>>>       "interval": -1,
>>>> *      "aggtime": 60,*
>>>>     *  "aggfixedinterval": true,*
>>>>       "channels": [
>>>>         {
>>>>           "uuid": „meineUUID",
>>>>           "identifier": "Impulse",
>>>>           "api": "volkszaehler",
>>>>           "middleware": "http://127.0.0.1/middleware.php",
>>>> *          "aggmode": "SUM",*
>>>>           "duplicates": 0
>>>>         }
>>>>       ],
>>>>       "protocol": "s0",
>>>>       "gpio": 4,
>>>>       "resolution": 1000,
>>>>       "configureGPIO": true,
>>>>       "debounce_delay": 0
>>>>     },
>>>>      …
>>>> weitere Sensoren
>>>> …
>>>>
>>>> Ich hab es hier auch mit und ohne aggtime (-1, 60, 300),
>>>> aggfixedinterval (true, false) und aggmode (SUM) in verschiedenen
>>>> Einstellungsvarianten versucht. Immer das gleiche Verhalten, die S0-Werte
>>>> werden zwar entsprechend aufsummiert, letztlich sieht es dann aber nicht
>>>> anders aus, als wenn vzcompress2.php drüber gerattert wäre.
>>>>
>>>
>>> Deine konfiguration sieht gut aus. Da das bei allen anderen Anwendern
>>> funktioniert bleibt wieder die These: vzcompress _ist_ drüber gerattert.
>>>
>>> Deshalb wären mit Leistungswerte oder Zählerstände lieber.
>>>>
>>>
>>> Ist unnötig. Alle Mittel sind da- vmtl. falsche konfiguriert. Wie sehen
>>> denn die Timestamps in der Datenbank aus- wirklich Minutenabstand? Bitte
>>> einmal getrennt für vzcompress und vzlogger prüfen, jeweils auf Basis einer
>>> "sauberen" Datenbank mit höchster Auflösung.
>>>
>>>>
>>>> Man kann hier die Impulsdaten sammeln und erst nach einer bestimmten
>>>>> Zeit in die Datenbank schreiben (z.B. alle Impulse über 60 Sekunden
>>>>> aggregieren und einen summierten Impulswert in die DB schreiben),
>>>>> allerdings löst das das Problem mit der dann schönen Anzeige nicht.
>>>>>
>>>>
>>>> Siehe oben- was heißt "unschöne Anzeige"? Natürlich bekommst Du bei
>>>> minütlicher Erfassung keine sekundengenaue Auflösung mehr.
>>>>
>>>> Selbstverständlich hat man - im Gegensatz zur S0-Zählung - bei einer
>>>> 1-minütigen Leistungserfassung eine recht gute Abbildung des Verlaufs
>>>> (Haushalt, Wärmepumpe, etc.). Gleiches gilt für Temperaturen (sieh Bild
>>>> oben).
>>>>
>>>
>>> Nein. Die hat man auch bei S0!
>>>
>>>>
>>>> Darüber hinaus funktioniert der *vzlogger* hinsichtlich der S0-Daten
>>>>> nicht zuverlässig, es werden ab und an Leistungspeaks von mehreren kW in
>>>>> die DB geschrieben, das Frontend macht dann auch Probleme. Ein
>>>>> nachvollziehbares und reproduzierbares Verhalten dafür konnte ich nicht
>>>>> ausmachen.
>>>>>
>>>>
>>>> D.h. es ist ein Problem von vzlogger aber nicht s0vz? Könnte das mit
>>>> Entprellung zu tun haben? Dafür gäbe es einen Parameter.
>>>>
>>>> Die Daten erfasse ich wie oben in der config angegeben. Das klappt
>>>> technisch auch gut. Jetzt wird’s wieder unpräzise :) : nach einiger Zeit
>>>> (1-2 Stunden), treten die kW Sprünge - nicht nachvollziehbar - auf, ohne
>>>> dass irgendetwas angefasst wird. Wenn ich etwas reproduzierbares hab, sag
>>>> ich bescheid. Ich weiß, dass man so schlecht auf die Suche gehen kann.
>>>>
>>>
>>> Leider ja :(
>>>
>>>
>>>>
>>>> Auch muckt das Frontend beim aktuellen Jessie-Image ab und an (siehe
>>>> Bild). Auf meinem alten Rapsi (Image +/- April 2015, es läuft kein vzlogger
>>>> nur 1wirevz und s0vz) gibt es keine Probleme (Cache und Cookies sind
>>>> gelöscht und den Webserver habe ich auch neu gestartet).
>>>>
>>>> Siehe: BibmtI.png
>>>> <https://imagizer.imageshack.us/v2/537x376q90/911/BibmtI.png>
>>>>
>>>
>>> Igitt! Kannst Du das reproduzieren? Dann bitte Issue erstellen- das
>>> würde ich gerne lösen.
>>>
>>>>
>>>>
>>>>> Nun suche ich nach einer Lösung mit der bestehenden Konfiguration
>>>>> meine S0-Daten über einen bestimmten Zeitraum zu aggregieren, diesen Wert
>>>>> dann in kWh umzuwandeln (mit der Auslösung und dem Zeitintervall
>>>>> verrechnen) und als Leistungswert z.B. alle 60 Sekunden in die DB zu
>>>>> schreiben. Das reduziert das Datenaufkommen und man erkennt den
>>>>> Leistungsverlauf in allen Zoomstufe des Frontends besser - und das auch
>>>>> nach dem Komprimieren der Daten mit *vzcompress2.php*. Die Mengen an
>>>>> Impulsdaten will ich nicht weiter speichern, das bläht die DB nur unnötig
>>>>> auf und verlangsamt die Reaktionszeit enorm, wenn man sich die Daten auch
>>>>> anschauen und auswerten will.
>>>>>
>>>>
>>>> Siehe oben. Ist alles nicht notwendig wenn Du die Middleware
>>>> entsprechend konfigurierst.
>>>>
>>>> Es wäre schön, wenn das möglich wäre.
>>>>
>>>
>>> Nochmal: es  ist nicht möglich und nicht nötig. Deine Anforderung lässt
>>> sich via S0 Aggregation wunderbar umsetzen!
>>>
>>> Mir geht es im Wesentlichen um die Größe der Datenbank bei 5 S0-Zählern,
>>>> die Anzeigengeschwindigkeit und vor allem um die bessere „Lesbarkeit“ im
>>>> Frontend über alle Zoomstufe hinweg. Das ist mit komprimierten S0-Signalen
>>>> eben unschön.
>>>>
>>>
>>> Nein, ist es nicht. Verabschiede Dich bitte von dem Diskussionspfad. Die
>>> richtige Frage wäre: warum sieht bei Dir die S0 Aggregation so seltsam aus?
>>> Wenn die beantwortet ist brauchst Du auch Deine Lösungsidee nicht mehr...
>>> Analyseschritte siehe oben.
>>>
>>> Viele Grüße,
>>> Andreas
>>>
>>>
>>>>
>>>>
>>>>> Hat jemand dafür eine Idee, oder geht das bereits in irgendeiner Form.
>>>>>
>>>>
>>>> Ja und ja :)
>>>>
>>>> Viele Grüße,
>>>> Andreas
>>>>
>>>>
>>>>>
>>>>> vorweihnachtliche Grüße
>>>>> Jens
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20151223/975f0ea5/attachment-0001.html>