<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hallo Rupert<br>
</p>
<div class="moz-cite-prefix">On 21.04.21 20:28, Rupert Schöttler
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b4217679-be8f-288f-fc64-19a12ce8b97d@gmx.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>ad d) <br>
</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>
</blockquote>
<p>Der grundsätzliche Unterschied besteht darin, dass die Funktion,
die die vom Zähler gemessene Energie beschreibt, zwar
zeitkontinuerlich aber wertediskret ist, d.h. die Funktion kann
schon vor der Digitalisierung nur bestimmte Werte annehmen -- in
meinem Fall nur Vielfache von 1 kwh. Der Prozess ist nicht
wertekontinuerlich/stetig. Damit sind die Annahmen für die
Berechnung der Ableitung nicht mehr gegeben (lim (f(x+dt) -
f(x)/dt) mit dt gegen 0 und f(x) ist eine stetige Funktion --
diese gelten in abgewandelter Form auch für die digitale Domaine,
die zeit- und wertediskret ist). <br>
</p>
Man hat Sprungstellen, bei denen die Ableitung, also die Leistung
P, gegen unendlich geht. Und eigentlich ist das auch das, was mit
den Einschränkungen eines Rechners (der numerische Werte nur
annähren bzw. unendlich nicht ohne weiteres darstellen kann) bei der
Anzeige "current" und hoher Abtastrate beobachtet. Also zunächst ein
grundsätzlich Verhalten, ganz unabhängig von einer Digitalisierung.<br>
<blockquote type="cite"
cite="mid:b4217679-be8f-288f-fc64-19a12ce8b97d@gmx.de">
<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.</p>
</blockquote>
<p>Die Breite der Balken sind schon vergessen :-) <br>
</p>
<p>Hier ist ein Punkt, an dem sich die Geister scheiden. Die
gemessene physikalische Größe ist die Energie (nicht die Leistung)
-- und das ist zumindest für mich die Größe, die mich bei einem
Energiezähler interessiert. Habe ich Verwendung für die Leistung?
Als Betreiber einer PV-Anlage, sicherlich -- allerdings nicht als
abgeleiteter Durchschnittswert über z.B. eine Stunde, sondern als
Momentanwert/Meßwert mit vergleichsweise hoher Abtastrate, da sie
sich recht dynamisch je nach Sonneneinstrahlung ändern kann.
Vielleicht ist der Smart-Zähler mit der Pin smart genug, sie
auszugeben. Cool wäre es, wenn ich zusätzlich die vom
Wechselrichter gemessene Leistung direkt in vzlogger einspeisen
und anzeigen könnte.<br>
</p>
<p>Interessiert mich der absolute Wert der eingespeisten oder
bezogenen Energie? Nachrichtlich ganz nett, aber letzlich bin an
der Energie innerhalb einer Zeiteinheit interessiert, d.h. kwh
während einer Stunde, Tag, Woche, Monate oder auch Jahr als
Abrechnungszeitraum. Damit sehe ich, wie wirtschaftlich die
PV-Anlage ist. Oder auch, ob sich die Anschaffung einer
zusätzliche Batterie lohnen würde.<br>
</p>
<p>Mit der Balkendarstellung bin ich deswegen abgesehen von der
Einheit auf der y-Achse auch ganz zufrieden -- auch weil sie
keinen kontinuiertlichen Werteverlauf suggeriert. <br>
</p>
<blockquote type="cite"
cite="mid:b4217679-be8f-288f-fc64-19a12ce8b97d@gmx.de">
<p>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>
</blockquote>
<p>Bei der Bandbreite von Möglichkeiten gibt es in meiner
Überzeugung keine einzelne Darstellung oder auch
Verarbeitungsweise, die allen (physikalischen) Größen oder
Use-Cases gerecht wird, d.h. hier könnten konfigurierbare
Fallunterscheidungen helfen. Bei der Temperatur ist sicherlich der
Verlauf des Absolutwerts über die Zeit interessant -- in
Ausnahmefällen vielleicht auch mal die erste Ableitung. Bei Strom,
Gas, Wasser sind nach meinem Dafürhalten vor allem die Summen
innerhalb einer Zeiteinheit (z.B, m³ an einem Tag, in einer
Stunde,etc. ) und ggf. auch die momentanten Flussraten
interessant -- allerdings nur, wenn sie einen physikalischen Bezug
bzw. einen Bezug zum realen Verhalten haben. Oder im
Umkehrschluss, wenn die Auflösung hoch genug ist, kann man nach
meiner Meinung daraus auch Flussraten ableiten. Ansonten wird der
Fehler zu gross, und man muss sich fragen, welche Aussagekraft die
Größe noch hat. <br>
</p>
<p>Die Impulszähler messen an sich alle Mengen (nicht Flussraten)
und zwar wertediskret -- deswegen würde ich diese zunächst mal so
anzeigen. Wenn man (zusätzlich) Flussraten als errechnete Größe
anzeigen möchte, könnte man mit einem Parameter "minimaler Fluss"
arbeiten, aus dem man die maximale Zeit bis zum nächsten Puls
errechnet. Falls diese überschritten wird, nimmt man eine
Flussrate von 0 an. (Ich habe gerade einen Wasserzähler vor meinem
geistigen Auge). Es mag auch Anlagen geben, die die Flussrate
direkt messen können (Dopplershift und Ultraschall -- sicherlich
nichts für das Eigenheim). Falls man solche Fälle unterstützen
wollte, müsste man in die SW eine Fallunterscheidung/Option je
nach Sensortype implementieren, die der Benutzer entsprechend
konfigurieren würde.<br>
</p>
<p>Zurück zu meinem Use-Case: Wir beziehen momentan bei schönen
Wetter 1 kwh bzw. maximal 2kwh pro Tag, die über den Tag verteilt
benötigt werden. Der Rest kommt von der PV-Anlage. Die 1kwh ist
das Resultat sowohl von Laständerungen und als auch Änderungen
bei der Versorgungleistung, bei denen der Wechselrichter nicht
schnell genug nachregelt. Wenn man z.B. den Herd mit 3 kw
einschaltet, kann es passieren, dass der Wechselrichter nicht
schnell genug mehr Energie zur Verfügung stellt. Dann kommt diese
aus dem Netz. Eine Darstellung der (gemittelten) Leistung von
1000 Watt in einer Stunde oder z.B. 41.6 W über einem Tag sind in
dem Zusammenhang irreführend bzw. keine gut Annährung an das
reale Verhalten. Die Berechnung einer (gemittleren) Leistung würde
ich in disen Fall deswegen abschalten, wenn es eine Möglichkeit
gäbe, dieses zu konfigurieren.</p>
<p><br>
</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>
<blockquote type="cite"
cite="mid:b4217679-be8f-288f-fc64-19a12ce8b97d@gmx.de">
<blockquote type="cite"
cite="mid:c70009a9-65b0-f100-9bfc-14fc2576bd97@gloetzner.net">
<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>
</blockquote>
<p>Ja, die Stufendarstellung ist gut -- mit der Einschränkung der
Einheit der Y-Achse -- da würde ich gerne kwh statt kw als die
gemessene physikalische Größe konfigurieren können :-)</p>
<p><br>
</p>
<p>Viele Grüße und Vielen Dank für Deine ausführliche Email.</p>
<p>Tilman<br>
</p>
<br>
</body>
</html>