[vz-users] S0-Zähler als aggregierter Leistungswert speichern
Andreas Goetz
cpuidle at gmail.com
Tue Dec 22 18:21:49 CET 2015
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/20151222/977993f6/attachment-0001.html>
More information about the volkszaehler-users
mailing list