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