<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hallo Zusammen!<br class=""></div><div class=""><br class=""></div><div class="">ich habe mir das ein wenig genauer angeschaut und ein paar Erkenntnisse gesammelt.</div><div class=""><br class=""></div><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div class="">On 11. Apr 2018, at 21:27, Frank Richter <<a href="mailto:frank.richter83@gmail.com" class="">frank.richter83@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div dir="auto" class="">Hi Andreas,<div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div></div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div>Verstanden.<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">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.</blockquote></blockquote></blockquote></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Dann betrifft das Problem ausschließlich SensorInterpreter/ Leistungsmessung. </div><div class=""><br class=""></div><div class="">Da wurde früher einfach ein Durchschnitt der Einzelwerte gebildet und bei tuples oder Verbrauch als Berechnungsgrundlage herangezogen. Das ist physikalisch falsch.</div><div class="">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.</div><div class=""><br class=""></div><div class="">Sowohl bei ImpulseInterpreter (S0) als auch AccumulatorInterpreter (Zählerstand) ist die Energiemenge bekannt, es gibt also auch nichts zu rechnen.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div></div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div><blockquote type="cite" class=""><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Das klingt für mich als wolltest du erfundene Werte loggen, das halte<br class="">ich wiederum für einen Gang in die falsche Richtung. Wir sollten den<br class="">Logger, by default, ausschließlich gemessene Werte aufnehmen lassen,<br class="">die Interpretation liegt beim Nutzer.<br class=""><br class="">Mit freundlichen Grüßen Daniel</blockquote></div></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">Davon abgesehen kann ja auch eine Meßeinrichtung mal ausfallen.</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class="">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.</div></div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div>Genau. </div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class="">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).</div></div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div>Yep, das ist aber nochmal ein anderes Problem das auch unabhängig von Gaps besteht. Erstmal off-topic.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class="">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.</div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div>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. </div><div class="">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...</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class="">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. </div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class="">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… </div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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???</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class="">Viele Grüße</div><div dir="auto" class="">Frank</div></div></div></div></blockquote></div></blockquote></blockquote><div class=""><br class=""></div><div class="">Hier nochmal ein Chart mit und ohne Korrektur für SensorInterpreter:</div><div class=""><br class=""></div><div class="">richtig:</div><div class=""><img apple-inline="yes" id="D0DB70C5-DA6B-4946-B5EC-550444BD5567" width="320" height="200" src="cid:21D48235-807F-4539-B3F0-845DB92261D7" class=""></div><div class=""><br class=""></div><div class="">falsch:</div><div class=""><img apple-inline="yes" id="C536BAE7-4AF4-4F59-8CB6-062AECDD7D81" width="320" height="200" src="cid:28A200D7-7068-45F3-AE58-5211DADCA235" class=""></div><div class=""><br class=""></div>Viele Grüße, </div><div class="">Andreas</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class=""><div dir="auto" class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">Andreas Goetz <<a href="mailto:cpuidle@gmail.com" rel="noreferrer noreferrer" target="_blank" class="">cpuidle@gmail.com</a>> schrieb am Mi., 11. Apr. 2018 17:18:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Hallo Frank,<div class=""><br class=""></div><div class="">ich greife Deine Anmerkung nochmal auf.</div><div class=""><br class=""></div><div class="">Tatsächlich haben wir da auch ein visuelles Problem sobald z.B. im next Branch die Barcharts verwendet werden:</div><div class=""><br class=""></div><div class=""><img id="m_-6293201703519510735m_6646325728987894745m_82550389394294131875700A14-2B9E-4E26-9355-098F92E700D8" width="320" height="200" class=""></div><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><div class="">a) Anzeigeeigenschaften (“gap”) auch für die Berechnungen heranzuziehen oder</div><div class="">b) noch weitere Konfigurationsparameter einzubauen die weiter Komplexität bringen</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Was machen wir also (master + next):</div><div class=""><br class=""></div><div class="">- gar nix</div><div class="">- 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)?</div><div class="">- bessere Ideen?</div><div class=""><br class=""></div><div class="">Viele Grüße, </div><div class="">Andreas</div><div class=""><br class=""></div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 4. Apr 2018, at 10:46, Frank Richter <<a href="mailto:frank.richter83@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank" class="">frank.richter83@gmail.com</a>> wrote:</div><br class="m_-6293201703519510735m_6646325728987894745m_825503893942941318Apple-interchange-newline"><div class=""><div dir="auto" class="">Moin Andreas,<div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Viele Grüße</div><div dir="auto" class="">Frank</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">Andreas Goetz <<a href="mailto:cpuidle@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank" class="">cpuidle@gmail.com</a>> schrieb am Mi., 4. Apr. 2018 07:57:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">2018-04-03 23:58 GMT+02:00 Frank Richter <span dir="ltr" class=""><<a href="mailto:frank.richter83@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">frank.richter83@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="">Hi zusammen,<div dir="auto" class=""><br class=""></div><div dir="auto" class="">müsste man dann nicht konsequenterweise die Lücken auch aus der Verbrauchsberechnung rauslassen (betrifft Leistungswerte)?</div></div></blockquote><div class=""><br class=""></div>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.<br class=""></div><div class="gmail_quote"><br class=""></div><div class="">Schwieriger Fall.Implementierung wäre nochmal zusätzliche Komplexität für die MW. Ich würde sagen "jaein". <br class=""></div><div class="gmail_quote"><div class=""><br class=""></div><div class="">Lohnt es sich wirklich da Aufwand und Komplexität in diese "Randfälle" zu investieren?</div><div class=""><br class=""></div><div class="">vg</div><div class="">Andreas<br class=""></div><div class=""></div>
<div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Grüße</div><span class="m_-6293201703519510735m_6646325728987894745m_825503893942941318m_7439041754923081351HOEnZb"><font color="#888888" class=""><div dir="auto" class="">Frank</div></font></span></div><div class="m_-6293201703519510735m_6646325728987894745m_825503893942941318m_7439041754923081351HOEnZb"><div class="m_-6293201703519510735m_6646325728987894745m_825503893942941318m_7439041754923081351h5"><br class=""><div class="gmail_quote"><div dir="ltr" class="">Andreas Goetz <<a href="mailto:cpuidle@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">cpuidle@gmail.com</a>> schrieb am Di., 3. Apr. 2018 19:23:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Hi Lars,<div class=""><br class=""></div><div class="">schau mal hier: <a href="https://github.com/volkszaehler/volkszaehler.org/pull/691" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">https://github.com/volkszaehler/volkszaehler.org/pull/691</a></div><div class=""><br class=""></div><div class="">Magst Du den vielleicht testen?</div><div class=""><br class=""></div><div class="">Viele Grüße, Andreas</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 31. Mar 2018, at 18:12, Lars Täuber <<a href="mailto:lars.taeuber@web.de" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">lars.taeuber@web.de</a>> wrote:</div><br class="m_-6293201703519510735m_6646325728987894745m_825503893942941318m_7439041754923081351m_-9146828473286968332m_583025425831135223Apple-interchange-newline"><div class=""><div class="">Hab Dank für den Hinweis.<br class=""><br class="">Grüße<br class="">Lars<br class=""><br class="">On Sat, 31 Mar 2018 14:51:58 +0200<br class="">Andreas Goetz <<a href="mailto:cpuidle@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">cpuidle@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Hi Lars,<br class=""><br class="">Jetz hab ichs auch verstanden. Schau mal hier: <a href="https://github.com/volkszaehler/volkszaehler.org/blob/master/htdocs/js/options.js#L58Das" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">https://github.com/volkszaehler/volkszaehler.org/blob/master/htdocs/js/options.js#L58Das</a> diente der Entschlackung der Oberfläche. <br class=""><br class="">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...<br class=""><br class="">Viele Grüße, Andreas <br class=""><br class=""><blockquote type="cite" class="">Am 31.03.2018 um 13:36 schrieb Lars Täuber <<a href="mailto:lars.taeuber@web.de" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">lars.taeuber@web.de</a>>:<br class=""><br class="">Hallo Andreas,<br class=""><br class="">offenbar bekomme ich das nicht über die Weboberfläche hin.<br class="">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.<br class=""><br class="">Frohe Ostern<br class="">Lars<br class=""><br class="">On Sat, 31 Mar 2018 04:08:50 +0200<br class="">Andreas Goetz <<a href="mailto:cpuidle@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">cpuidle@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Geht für Leistung genau so. Falls nein- was ist das Peoblem?<br class=""><br class="">Viele Grüße, Andreas <br class=""><br class=""><blockquote type="cite" class="">Am 30.03.2018 um 22:05 schrieb Lars Täuber <<a href="mailto:lars.taeuber@web.de" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">lars.taeuber@web.de</a>>:<br class=""><br class="">Hallo zusammen,<br class=""><br class="">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?<br class=""><br class="">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.<br class=""><br class="">Wäre es möglich VZ dahingehend zu erweitern?<br class=""><br class="">Dank und Gruß<br class="">Lars <br class=""></blockquote></blockquote><br class=""><br class="">-- <br class="">Schöne Grüße<br class="">Lars Täuber<br class=""><Temperaturen.jpg> <br class=""></blockquote></blockquote><br class=""><br class="">-- <br class="">Schöne Grüße<br class="">Lars Täuber<br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div>
</div></div></blockquote></div><br class=""></div></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div></div>
<span id="cid:%3C%3E"><Screen Shot 2018-04-11 at 17.09.01.png></span></div></blockquote></div><br class=""></blockquote></blockquote></div></div></body></html>