<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hallo Tilman,</p>
    <br>
    <div class="moz-cite-prefix">Am 20.04.21 um 01:17 schrieb Tilman
      Glötzner:<br>
    </div>
    <blockquote type="cite"
      cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      ad c) <br>
      <p>Ich habe den Kopf um 180 Grad gedreht -- danach gab es keine
        Einträge mehr im Logfile. Nachdem ich ihn wieder in die alter
        Orientierung  versetzt habe, sprudelt es im Logfile wieder.
        Meisten mit 4 Einträgen pro Minute --  seltener kommt auch mal
        10 Minuten nichts. Ich habe ein 2 Sample der Logfiles angehängt.
        In vzlogger.log wird mindestens einen neuer Datensatz in der
        Minute gelesen. vzlogger1.log ist ein Beispiel, bei dem zwischen
        2 Obisdatensätzen circa 7 Minuten vergehen. Mir fällt nichts
        besonders auf, z.B. Fehlermeldungen. Wenn die Zeit zwischen 2
        Obis-Datensätzen lang wird, füllen folgenden, sich wiederholende
        Logmeldungen  den Zeitraum:</p>
      <p>[Apr 19 22:27:33][mtr0] Got 0 new readings from meter:<br>
        [Apr 19 22:27:33][chn0] ==> number of tuples: 0<br>
        [Apr 19 22:27:33][chn0] JSON request body is null. Nothing to
        send now.<br>
      </p>
    </blockquote>
    <p>Hab's mir angeschaut, kann aber auch keinen Hinweis auf die
      Ursache finden. Vielleicht findet ja ein Experte aus der NG noch
      was.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
      <p> </p>
      <p>ad d) <br>
      </p>
      <p>>Derartige Diskussionen hatten wir hier schon reichlich.</p>
      <p>Das glaube ich sofort :-) Und inhaltlich bin ich fast bei Dir.
        <br>
      </p>
      <p>Wie Du schreibst, hat es man in der Regel mit Zeit- und
        wertkontinuiertlichen Vorgängen zu tun, die die man durch
        Abtastung zu einem Zeitpunkt diskretisiert, so dass man im
        Prinzip keine Aussage über die Zwischwerte zwischen zwei
        Abtastpunkten treffen kann. Man kann  aber eine Annahme treffen,
        und einen Zwischenwert durch Interpolieren erzeugen(z.B. durch
        eine Linearisierung). Um bei dem Temperaturbeispiel zu bleiben:
        Bei zwei hintereinander abgestasteten Temperaturwerten 25 und 27
        Grad wird die Temperatur zu einem Zwischenzeitpunkt wohl  26
        Grad gewesen sein.<br>
      </p>
    </blockquote>
    <p>Schön: Ich sehe, die Grundlagen sind Dir vertraut, da macht die
      Diskussion Spaß! :-)</p>
    <p>Ja, die Zwischentemperatur 26° MUSS sogar irgendwann vorhanden
      gewesen sein, denn Temperatur kann nicht springen. Es KANN aber
      auch sein, dass sie zwischen den beiden Messpunkten irgendwo weit
      außerhalb dieses Fensters war. Daher liegt es am Designer des
      Messaufbaus, Abtastrate und Messgenauigkeit sinnvoll an die
      gestellte Aufgabe anzupassen. Dann ist das einfache Verfahren der
      Linearisierung "gut genug" und kann auch vom Volkszähler
      ausgeführt werden -- in der Grafik, wenn man die entsprechende
      Darstellung (Stil: Linien) auswählt. <br>
    </p>
    <p>Für Leistung nutzen die meisten Leute eher "Stil: Stufen", denn
      so passt es zum Messprinzip des Arbeitszählers: Wir teilen ein
      Delta W durch Delta t und damit war die <b>mittlere</b> Leistung
      in diesem Zeitraum P -- mehr wissen wir nicht, aber diese mittlere
      Leistung <b>ist korrekt</b> <b>in den Grenzen </b>(Messgenauigkeit
      und Diskretisierung), wie W und t erfasst wurden. Wohlgemerkt:
      Dies gilt für die Grafik. Bei den Auswertungen unter der Grafik
      (min, max, Mittelwert, Verbrauch, ...) macht das Frontend keine
      "Kopfstände" für irgendwelche potentiellen Dinge zwischen zwei
      Messpunkten. Der Verbrauch z.B. stimmt nicht 100% mit der Summe /
      dem Integral über den angezeigten Zeitraum überein, weil "links
      und rechts" immer der nächste Datenpunkt <b>außerhalb</b> des
      angezeigten Zeitraums verwendet wird, keine Interpolation o.ä. auf
      exakt den Zeitraum, der über der Grafik steht. Das ist eine
      bekannte Eigenschaft der Software.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
      <p> </p>
      <p>Bei dem Energiezähler scheint mir die Situation in sofern
        anders zu sein, als dass der Vorgang als solcher zwar ebenfalls
        zeit- und wertkontinuerlich ist ( auch wenn er sich nicht
        direkt, sondern durch Integration ergibt, nämlich einer Summe
        von Leistungen über die Zeit). Allerdings erfolgt seine
        Änderung, anders als im Temperaturbeispiel nicht gleichmäßig,
        sondern nur, wenn eine  Einheit  verbraucht oder erzeugt wurde,
        d.h. die gemessene Größe ist wertediskret.  Beim klassischen
        Zähler mit Scheibe und 96 U/kwh  ist die Einheit krumme
        10.416666 wh gross (wenn der rote Strich nach einer Umdrehung
        wieder am Fenster vorbei kommt) -- bei meinem supersmarten
        Zähler ist sie 1kwh. Die Lineariserung (und das Rückrechnen der
        Energie auf die Leistung) funktioniert hier nur bei höherem
        Verbräuchen mit entsprechend vielen Werten pro Zeiteinheit gut.<br>
      </p>
    </blockquote>
    <p>Ich sehe keinen grundlegenden Unterschied zwischen Deinen
      Beispielen: Alle registrierten Änderungen erfolgen wert- und/oder
      zeitdiskret. Die Temperatur kann auch nur mit endlicher Auflösung
      gemessen werden, und bei den Arbeitszählern ist die Auflösung
      0,0001 kWh (häufigste Einstellung bei elektronischen Zählern nach
      PIN-Freigabe), 1/96 kWh bei Deinem Ferraris-Beispiel, oder eben 1
      kWh bei Deinem MT681 ohne PIN. <br>
    </p>
    <p>Das "Rückrechnen" von Energie resp. Arbeit auf Leistung
      entspricht mathematisch der 1. Ableitung: P = dW/dt. In der
      diskreten Mathematik führt das nur dann zu "richtigen" oder
      wenigstens brauchbaren Ergebnissen, wenn Abtastfrequenz und
      -genauigkeit (Werte-Diskretisierung) zusammenpassen -- und das
      passt bei Dir eben genau nicht: Du machst zwar viele dt, aber nur
      selten gibt es ein dW. Damit ist P meistens 0 und gelegentlich
      riesengroß. Das ist ein Phänomen, das diese Software
      (Middleware/Frontend) nicht heilen kann. <br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
      <p> </p>
      <p>Vor dem Hintegrund scheint mir die Einstellung "hourly" und
        "Tag" oder "Woche" ebenfalls eine geeignete, genauso wie der
        Verzicht auf die Darstellung der Energie als Leistungen über
        Zeit, d.h. als Abbildung über die Breite des Balkens.
        Gleichzeitig finde ich aber, dass man diesem Rechnung tragen
        sollte und die Y-Achse des Koordinatensystem mit dem bezeichnet,
        was man tatsächlich misst: Die Energie in der Einheit wh oder
        kwh (die Einheit ist zumindest in der Datelstellung meines
        Loggers kw). Und das kann die Software nach meinem Dafürhalten
        schon lösen :-) Einige der Smartzähler scheinen zusätzlich die
        aktuelle Leistung zur Verfügung stellen zu können, so dass ich
        vermute, dass man hier eine Fallunterscheidung für die Art des
        Zählers benötigt.<br>
      </p>
    </blockquote>
    <p>Auch wenn ich die Balkendarstellung nicht 100% kenne: Vergiss die
      Breite des Balkens! Die einzige Aussage ist seine Höhe, und zwar
      als Mittelwert der angezeigten Größe (hier: Leistung!!!!) im
      gewählten Zeitraum. Nochmal: Volkszähler kann mit vielen
      verschiedenen physikalischen Größen umgehen, auch Temperatur oder
      Luftfeuchtigkeit oder Ventilstellung EIN/AUS. Verbrauchszähler
      (Gas, Wasser, Elektrizität), die Zählerstände liefern, werden für
      die Anzeige sofort auf Leistung resp. Verbrauchsrate (l/h, m³/h)
      umgerechnet, weil eine monoton steigende Linie des Zählerstandes
      langweilig ist und wir dann doch nur die Steigung der Linie (1.
      Ableitung!!) abschätzen würden. Das führt dann bei der erneuten
      Rückrechnung (Integration) auf den Verbrauch im angezeigten
      Zeitraum zu kleinen Ungenauigkeiten, s.o. <br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
      <p> </p>
      <p>>- Sinnvolle Anpassung der Auflösungen (Zeit und Größe),
        entweder durch Freischalten einer höheren Auflösung der
        Zählerstände >mittels PIN oder durch Reduktion der Abtastrate
        z.B. auf 1/h (sollte mit aggtime gehen)</p>
      <p>Die Pin habe ich am Samstag beim Stromversorger angefragt. Mal
        sehen, was da kommt. Und aggtime habe ich nun auf 3600 gesetzt.</p>
    </blockquote>
    <p>Gefallen Dir die im Frontend anzeigten Ergebnisse nun besser?</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
      <p>Vielen Dank und viele Grüße nach Augsburg</p>
      <p><br>
      </p>
      <p>Tilman</p>
    </blockquote>
    <p>Gerne doch :-)</p>
    <p>Rupert<br>
    </p>
    <br>
  </body>
</html>