[vz-dev] wish list: Lücke für elektrische Leistung

Tue Apr 17 10:52:02 CEST 2018

Hallo Zusammen!

ich habe mir das ein wenig genauer angeschaut und ein paar Erkenntnisse gesammelt.

>>> On 11. Apr 2018, at 21:27, Frank Richter <frank.richter83 at gmail.com> wrote:
>>> 
>>> Hi Andreas,
>>> 
>>> ich finde das gap-Feature ein bisschen problematisch, weil es die Konsistenz zwischen Graph und berechneten Werten kaputt macht: Wenn ein Teilbereich des Charts nicht angezeigt wird, aber trotzdem in die Verbrauchsberechnung einfließt, widerspricht das der Interpretation der Energie als Integral der Leistungskurve.

Verstanden.

>>> Für viele, gleichverteilte Messwerte mag das keinen wesentlichen Unterschied machen, ist im Grunde aber falsch. States bietet sich ja dafür an, einen Zustand nicht zyklisch, sondern nur bei Veränderung zu loggen (Schalter/Ventil). In diesem Fall darf man wohl weder viele noch gleichverteilte Datensätze voraussetzen.

So isses m.E. VZ eigentlich eine undokumentierte Grundannahme die heißt “viele Meßwerte je Zeitraum, i.W. gleichverteilt”. Beide Annahmen werden hier verletzt, es handelt sich in gewisser Weise also um ein Randszenario.

Dann betrifft das Problem ausschließlich SensorInterpreter/ Leistungsmessung. 

Da wurde früher einfach ein Durchschnitt der Einzelwerte gebildet und bei tuples oder Verbrauch als Berechnungsgrundlage herangezogen. Das ist physikalisch falsch.
Vor längerer Zeit hatte ich deshalb mal “gewichteten” Durchschnitt eingebaut und genau der verursacht jetzt das Problem bei großen “Lücken” wenn der Folgewert nicht Null ist.

Sowohl bei ImpulseInterpreter (S0) als auch AccumulatorInterpreter (Zählerstand) ist die Energiemenge bekannt, es gibt also auch nichts zu rechnen.

>>> 
>>> Eigentlich wäre es IMHO die Aufgabe des Loggers, nach der Phase mit P != 0 noch mindestens einmal P = 0 zu schicken, dann bräuchte es gar keine gap-Funktion und die Verbrauchsberechnung klappt nach althergebrachtem Schema.

> Das klingt für mich als wolltest du erfundene Werte loggen, das halte
> ich wiederum für einen Gang in die falsche Richtung. Wir sollten den
> Logger, by default, ausschließlich gemessene Werte aufnehmen lassen,
> die Interpretation liegt beim Nutzer.
> 
> Mit freundlichen Grüßen Daniel

Wie schon mehrfach diskutiert funktioniert das auch einfach nicht oder allenfalls für Ausnahmen. Wenn nämlich tuples zum Einsatz kommt oder Aggregation dann “verschwindet” die begrenzende Null einfach weil der Datensatz mit anderen vermatscht wird.

Davon abgesehen kann ja auch eine Meßeinrichtung mal ausfallen.

>>> Für Kanäle mit Verbrauch ist die Problematik offensichtlich, aber auch bei Sensor-Kanälen wird das gewichtete Mittel falsch berechnet, wenn man mit gap arbeitet: der erste Datensatz nach der Lücke geht viel zu stark in den Mittelwert ein.

Genau. 

>>> Bei states ist es im Prinzip das gleiche: angezeigt wird die states-Darstellung, die berechneten Werte folgen aber der Berechnung für steps (außer bei virtuellen Kanälen).

Yep, das ist aber nochmal ein anderes Problem das auch unabhängig von Gaps besteht. Erstmal off-topic.

>>> Ich kann nicht abschätzen, wieviele das wirklich brauchen und ob es sich lohnt, da viel Hirnschmalz und Arbeit zu investieren. Grundsätzlich würde ich aber für eine zwischen Frontend und Middleware konsistente und logisch nachvollziehbare Implementierung plädieren.

Ich schau mir das gerade an. Es scheint- da nur SensorInterpreter betroffen- nicht ganz so komplex. Es *muss* aber sowohl für Middleware als auch Aggregation eingebaut werden. 
Letzteres hat den Nachteil dass- so man “gap” ändert (in Config oder Kanaleigenschaften), so ist die Aggregation falsch. Aber wer ändert da überhaupt was da der Parameter ja standardmäßig ausgeblendet ist...

>>> Aber selbst wenn die MW gap berücksichtigen kann, löst das nicht dein Barchart-Problem: bei einem Zählerstand-Kanal wirst du immer den kumulierten Verbrauch beim ersten neuen Datenpunkt haben.

Das stimmt natürlich. In dem Falle habe ich verloren. Insofern hast Du Recht dass das Thema “Lücke” doch spannendender ist als ich dachte.

>>> Hypothetisch runterrechnen oder auf den gap-Zeitraum verteilen macht ja auch wenig Sinn. Den ersten Balken nach der Lücke ganz unterdrücken würde es optisch schöner machen, dann fehlt aber im Chart wieder was im Vergleich zur Verbrauchssumme. Schwierig… 

Ich tendiere dazu das Problem bei Zählerständen zu ignorieren. Würde heißen “Lücke” gilt nur für SensorInterpreter + Impulse. Bei Zählerständen ist die Annahme einer durchschnittlichen Leistung ja absolut gerechtfertigt da das durch den Verbrauch belegt ist. Ggf. könnte man aber bei Zählerständen den einzelnen Verbrauchsbalken noch unterdrücken solange man akzeptiert dass die Summe der Einzelverbräuche dann nicht dem Periodenverbrauch entspricht.

Ist aber in jedem Fall ein Thema von “next” da die Verbrauchsdiagramme ja nicht gemerged sind :) Bei SensorInterpreter sieht das anders aus da da auch schon die Verbrauchsberechnung falsch ist, siehe Beispiel unten.

Irgendwie werde ich aber auch das dumpfe Gefühl nicht los dass wir irgendwas völlig falsch machen. Es kann doch eigentlich der Spaltung des Atoms entsprechen ein paar einfache Kurven zu zeichnen???

>>> Viele Grüße
>>> Frank

Hier nochmal ein Chart mit und ohne Korrektur für SensorInterpreter:

richtig:

falsch:

Viele Grüße, 
Andreas

>>> 
>>> 
>>> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> schrieb am Mi., 11. Apr. 2018 17:18:
>>> Hallo Frank,
>>> 
>>> ich greife Deine Anmerkung nochmal auf.
>>> 
>>> Tatsächlich haben wir da auch ein visuelles Problem sobald z.B. im next Branch die Barcharts verwendet werden:
>>> 
>>> 
>>> 
>>> Da ist im Januar der Tagesverbrauch plötzlich unsinnig hoch weil der erste Wert nach der Lücke über einen Monat angenommen wird. Auf der anderen Seite widerstrebt es mir
>>> 
>>> a) Anzeigeeigenschaften (“gap”) auch für die Berechnungen heranzuziehen oder
>>> b) noch weitere Konfigurationsparameter einzubauen die weiter Komplexität bringen
>>> 
>>> Andererseits sind die virtuellen Kanäle ohnehin schon darauf getrimmt sich für die Berechnung anhand Anzeigeeigenschaften (nämlich “Steps” vs “States”) zu orientieren da sie sonst schlicht falsch rechnen.
>>> 
>>> Was machen wir also (master + next):
>>> 
>>> - gar nix
>>> - in der Middleware für Verbrauchsberechnung entity.gap berücksichtigen (und zusätzlich den gap Parameter aus options.js nochmal in der vz.conf.php spiegeln)?
>>> - bessere Ideen?
>>> 
>>> Viele Grüße, 
>>> Andreas
>>> 
>>> 
>>>> On 4. Apr 2018, at 10:46, Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>> wrote:
>>>> 
>>>> Moin Andreas,
>>>> 
>>>> hab verstanden, dass das die Komplexität stark erhöhen würde. Im Moment habe ich selbst keinen Bedarf für das Feature, warten wir mal ab ob Lars das reicht, was der PR liefert.
>>>> Worst case wäre, wenn ein Gerät als letzten Wert eine Leistung ungleich 0 liefert und dann über einen längeren Zeitraum keinen Wert mehr, weil es dann inaktiv ist. Das macht die Verbrauchsberechnung ziemlich unbrauchbar.
>>>> 
>>>> Viele Grüße
>>>> Frank
>>>> 
>>>> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> schrieb am Mi., 4. Apr. 2018 07:57:
>>>> 2018-04-03 23:58 GMT+02:00 Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>>:
>>>> Hi zusammen,
>>>> 
>>>> müsste man dann nicht konsequenterweise die Lücken auch aus der Verbrauchsberechnung rauslassen (betrifft Leistungswerte)?
>>>> 
>>>> Im Moment arbeiten die Interpreter auf Basis der Daten, "gaps" ist allerdings ein Feature der Darstellung. "Darstellung" beeinflusst nicht was die Middleware zurück gibt. Noch schlimmer: Darstellung kann sich jedezeit ändern, mindestens aber in der Aggregationstabelle abgelegte Werte nicht. Tatsächlich sind virtuelle Kanäle da ebenfalls eine Ausnahme, auch müsste die Darstellung von steps vs. states die Verbrauchsberechnung ebenfalls beeinflussen. Tut sie unter der Annahme "viele Meßwerte im betrachteten Zeitraum" aber nicht.
>>>> 
>>>> Schwieriger Fall.Implementierung wäre nochmal zusätzliche Komplexität für die MW. Ich würde sagen "jaein". 
>>>> 
>>>> Lohnt es sich wirklich da Aufwand und Komplexität in diese "Randfälle" zu investieren?
>>>> 
>>>> vg
>>>> Andreas
>>>> 
>>>> 
>>>> Grüße
>>>> Frank
>>>> 
>>>> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> schrieb am Di., 3. Apr. 2018 19:23:
>>>> Hi Lars,
>>>> 
>>>> schau mal hier: https://github.com/volkszaehler/volkszaehler.org/pull/691 <https://github.com/volkszaehler/volkszaehler.org/pull/691>
>>>> 
>>>> Magst Du den vielleicht testen?
>>>> 
>>>> Viele Grüße, Andreas
>>>> 
>>>> 
>>>>> On 31. Mar 2018, at 18:12, Lars Täuber <lars.taeuber at web.de <mailto:lars.taeuber at web.de>> wrote:
>>>>> 
>>>>> Hab Dank für den Hinweis.
>>>>> 
>>>>> Grüße
>>>>> Lars
>>>>> 
>>>>> On Sat, 31 Mar 2018 14:51:58 +0200
>>>>> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> wrote:
>>>>> 
>>>>>> Hi Lars,
>>>>>> 
>>>>>> Jetz hab ichs auch verstanden. Schau mal hier: https://github.com/volkszaehler/volkszaehler.org/blob/master/htdocs/js/options.js#L58Das <https://github.com/volkszaehler/volkszaehler.org/blob/master/htdocs/js/options.js#L58Das> diente der Entschlackung der Oberfläche. 
>>>>>> 
>>>>>> Im next gibts noch einen globalen gap Parameter der einfach auf alle Kanäle wirkt. Wenn ich >1h keine Messwerte habe ich immer was faul...
>>>>>> 
>>>>>> Viele Grüße, Andreas 
>>>>>> 
>>>>>>> Am 31.03.2018 um 13:36 schrieb Lars Täuber <lars.taeuber at web.de <mailto:lars.taeuber at web.de>>:
>>>>>>> 
>>>>>>> Hallo Andreas,
>>>>>>> 
>>>>>>> offenbar bekomme ich das nicht über die Weboberfläche hin.
>>>>>>> Wie konnte ich das für die Temperatur der Sole (Sole Tout: Lücke=3) einstellen? Für die WW Temperatur gibt es dieses Feld nicht, genauso wenig wie bei der elektrischen Leistung.
>>>>>>> 
>>>>>>> Frohe Ostern
>>>>>>> Lars
>>>>>>> 
>>>>>>> On Sat, 31 Mar 2018 04:08:50 +0200
>>>>>>> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> wrote:
>>>>>>> 
>>>>>>>> Geht für Leistung genau so. Falls nein- was ist das Peoblem?
>>>>>>>> 
>>>>>>>> Viele Grüße, Andreas 
>>>>>>>> 
>>>>>>>>> Am 30.03.2018 um 22:05 schrieb Lars Täuber <lars.taeuber at web.de <mailto:lars.taeuber at web.de>>:
>>>>>>>>> 
>>>>>>>>> Hallo zusammen,
>>>>>>>>> 
>>>>>>>>> für Temperaturwerte gibt es die Möglichkeit, Lücken für die Kurven zu aktivieren. Warum gibt es das nicht auch für Leistung? Ist das Absicht?
>>>>>>>>> 
>>>>>>>>> Ich hätte das gerne auch für elektrische Leistung, weil ich Geräte habe, deren Leitung ich nur "messen" kann, wenn sie aktiv sind. Da ich die Leistung vom Gerät selber geloggt bekomme.
>>>>>>>>> 
>>>>>>>>> Wäre es möglich VZ dahingehend zu erweitern?
>>>>>>>>> 
>>>>>>>>> Dank und Gruß
>>>>>>>>> Lars    
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Schöne Grüße
>>>>>>> Lars Täuber
>>>>>>> <Temperaturen.jpg>  
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Schöne Grüße
>>>>> Lars Täuber
>>>> 
>>>> 
>>> 
>>> <Screen Shot 2018-04-11 at 17.09.01.png>
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20180417/bea29615/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-04-17 at 10.27.27.png
Type: image/png
Size: 78493 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20180417/bea29615/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-04-17 at 10.27.04.png
Type: image/png
Size: 78552 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20180417/bea29615/attachment-0003.png>