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

Tue Apr 17 23:44:29 CEST 2018

Hallo Andreas,

ich denke es ist eine Designentscheidung: wollen wir konfigurierbare
Interpreter-Logik (in diese Richtung gehen Features wie gap und auch
states), um das Verhalten des Interpreters an die Erfordernisse
unterschiedlich strukturierter Logdaten anzupassen, oder wollen wir klar
definierte, einfach nachvollziehbare Interpreter-Logik, und fordern daher,
dass die Logdaten bestimmte Vorgaben einhalten müssen, um plausible
Ergebnisse zu liefern?

Viele Grüße
Frank

Am 17. April 2018 um 10:52 schrieb Andreas Goetz <cpuidle at gmail.com>:

> 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> 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>
>> 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> schrieb am Mi., 4. Apr. 2018 07:57:
>>
>>> 2018-04-03 23:58 GMT+02:00 Frank Richter <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> schrieb am Di., 3. Apr. 2018 19:23:
>>>>
>>>>> Hi Lars,
>>>>>
>>>>> schau mal hier: 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> 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> wrote:
>>>>>
>>>>> Hi Lars,
>>>>>
>>>>> Jetz hab ichs auch verstanden. Schau mal hier: 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>:
>>>>>
>>>>> 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> 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>:
>>>>>
>>>>> 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/71152f59/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/71152f59/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/71152f59/attachment-0003.png>