[vz-users] S0-Zähler als aggregierter Leistungswert speichern
Jens
panterglas at web.de
Wed Dec 23 07:58:31 CET 2015
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.). 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). Dann ist die Auflösung immer gleich und aggregate.php hat nicht mit unterschiedlichen Auflösungen zu kämpfen. 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. Löscht man nach der Ausdünnung durch vzcompress2.php die aggregierten (aggregate.php clear) und legt sie neu an, passt es wieder. 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?
Vielen Dank und vorweihnachtliche Grüße
–Jens
> 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& <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 <mailto: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 <mailto:cpuidle at gmail.com>>:
>>
>> Moin,
>>
>> 2015-12-22 11:56 GMT+01:00 Jens <panterglas at web.de <mailto: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 <mailto:cpuidle at gmail.com>>:
>>>
>>> Moin Jens,
>>>
>>> 2015-12-21 20:36 GMT+01:00 Jens <panterglas at web.de <mailto: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 <mailto:cpuidle at gmail.com>>:
>>>>
>>>> Hallöchen,
>>>>
>>>> 2015-12-21 10:02 GMT+01:00 <Panterglas at web.de <mailto: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 <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 <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/15281d51/attachment-0001.html>
More information about the volkszaehler-users
mailing list