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

Andreas Goetz cpuidle at gmail.com
Tue Dec 22 11:39:16 CET 2015


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/6a1bff12/attachment-0001.html>


More information about the volkszaehler-users mailing list