DAL-Neue Anzeige+Rundung

[THellweg]

Hallo zusammen,

sicherlich haben sich schon mehrere von euch über die etwas seltsam erscheinenden Temperaturwerte gewundert, die nun nach dem Update im Device-Activity-Logging (DAL) angezeigt werden.

In den herumgesandten Releasenotes stand folgendes:
Das Loggen der Geräteaktivitäten wurde geändert. Die Genauigkeit der Anzeige wurde von 0,1 Grad bei der IST Temperatur auf 0,5 Grad angepasst. Bei der Luftfeuchtigkeit ändert sich die Genauigkeit von 0,1 Prozent auf 1 Prozent. Dadurch wird die Anzeige der Werte zur besseren Übersichtlichkeit reduziert.

Wer nun aber erwartet hat, dass die Temperaturen nun entweder mit vollen Gradzahlen oder mit "komma fünf" angezeigt werden, der wird sich über die jetzt tatsächlich angezeigten Werte bestimmt wundern.

Das Ganze ist nämlich etwas komplexer und daher auf den ersten Blick auch nicht gerade leicht zu durchschauen. Ich versuche trotzdem mal eine Erklärung:

- Von den Sensoren werden weiterhin die Istwerte, mit der bekannten Feinabstufung von 0,1°, an den SHC übermittelt.
- Der SHC rundet dann diesen Ist-Wert arithmetisch auf 0,5° Genauigkeit ab oder auf (z.B. 21,2°>21,0°, 21,3°>21,5°, 21,8°>22°, usw.).
- Angezeigt wird letztendlich aber nicht der gerundete Wert, sondern der tatsächlich gemessene!
- Wenn der nächstfolgende Wert, nach dessen Rundung, nicht um mindestens 0,5° abweicht, wird dieser nicht zur Anzeige gebracht.
- Erst wenn einer der nachfolgenden Werte, nach der Rundung, um mindestens 0,5° vom vorher angezeigten abweicht, wird dieser angezeigt.

Das klingt komplizerter als es eigentlich ist.
Mit einem Beispiel ist es sicher leichter zu verstehen:
10:10Uhr Gemessen 20,1°=Gerundet 20,0° > Anzeige 20,1°
10:15Uhr Gemessen 20,2°=Gerundet 20,0° > Verworfen, keine Anzeige
10:20Uhr Gemessen 20,3°=Gerundet 20,5° > Anzeige 20,3°
11:00Uhr Gemessen 20,5°=Gerundet 20,5° > Verworfen, keine Anzeige
11:15Uhr Gemessen 20,2°=Gerundet 20,0° > Anzeige 20,2°
11:25Uhr Gemessen 20,3°=Gerundet 20,5° > Anzeige 20,3°

Im DAL Logfile stehen dann nur diese Einträge:
10:10Uhr 20,1°
10:20Uhr 20,3°
11:15Uhr 20,2°
11:25Uhr 20,3°

Ich denke man kann das nun mit diesem Beispiel ganz gut nachvollziehen.

Bei den Messwerten für die Luftfeuchtigkeit und die Helligkeit verhält es sich ein wenig anders, denn hier wird der gerundete Wert angezeigt.

Auch dafür ein kleines Beispiel:
10:10Uhr Gemessen 48,5%=Gerundet 49% > Anzeige 49%
10:15Uhr Gemessen 49,0%=Gerundet 49% > Verworfen, keine Anzeige
10:20Uhr Gemessen 49,3%=Gerundet 49% > Verworfen, keine Anzeige
11:00Uhr Gemessen 49,5%=Gerundet 50% > Anzeige 50%
11:15Uhr Gemessen 49,8%=Gerundet 50% > Verworfen, keine Anzeige
11:25Uhr Gemessen 50,2%=Gerundet 50% > Verworfen, keine Anzeige
115Uhr Gemessen 50,6%=Gerundet 51% > Anzeige 51%

Und die Ausgabe im DAL ist dann diese:
10:10Uhr 49%
11:00Uhr 50%
115Uhr 51%

Ich hoffe damit einige der aufkommenden Fragen vorab beantwortet zu haben.

Viele Grüße,
Thomas

[tv_junkie]

Das ist ja mal vollkommen bes*****. Wenn ich die Werte in Excel ziehe und als Diagramm abbilde, ist die Zeitachse in unterschiedliche Einheiten eingeordnet. Damit ist - ohne Nacharbeit - die Aussagekraft der Temp.kurve gleich null.

Was soll denn die Rundung dann bringen? Weniger Messwerte zum Speichern?

[Gelöschter Benutzer]

Das ist ja mal vollkommen bes*****. Wenn ich die Werte in Excel ziehe und als Diagramm abbilde, ist die Zeitachse in unterschiedliche Einheiten eingeordnet. Damit ist - ohne Nacharbeit - die Aussagekraft der Temp.kurve gleich null.

Was soll denn die Rundung dann bringen? Weniger Messwerte zum Speichern?

Was haben denn die gerundeten Werte mit der Zeitachse zu tun??

[THellweg]

Hallo TV_Junkie,

Was soll denn die Rundung dann bringen? Weniger Messwerte zum Speichern?

Hauptsächlich sollen wohl der Speicher des SHC (der die Daten zwischenspeichert und portionsweise ins Backend überträgt), als auch die Backend-Datenbank damit entlastet werden.

Ich fand die Idee, jeden Wert zu runden und dann einen Vergleich mit dem vorher gerundeten Wert zu machen, am Anfang auch sehr seltsam, umständlich und irgendwie nicht einleuchtend. Inzwischen finde ich diese Lösung recht smart, vor allem die Tatsache, dass nach dem Vergleich der tatsächliche Wert angezeigt wird und nicht das Ergebnis der Rundung. So wird nichts verfälscht, kleine Ausreisser aus dem Trend werden geglättet und nebenbei werden viele, für eine brauchbare Trendanalyse eigentlich unnötige, Logeinträge vermieden.

Ein Problem im Zusammenhang mit der Zeitachse kann ich auch nicht erkennen. Erklär mal was Du genau meinst!

Viele Grüße,
Thomas

[Gelöschter Benutzer]

Vermutlich meint er die Tatsache, dass die Zeitwerte in der csv-Datei nicht sortiert sind.
Das muss man zu Fuß erledigen.
Irgendjemand hat da übersehen, dass es in SQL eine "Order by"-Clause gibt.

[THellweg]

Hallo großer Meister!

Vermutlich meint er die Tatsache, dass die Zeitwerte in der csv-Datei nicht sortiert sind.
Das muss man zu Fuß erledigen.
Irgendjemand hat da übersehen, dass es in SQL eine "Order by"-Clause gibt.

Waren die nicht vorher auch schon so hübsch durchgemischt, oder irre ich?

Viele Grüße,
Thomas

[Gelöschter Benutzer]

Ja, die waren schon immer wie Kraut und Rüben.
Außerdem haben sich irgendwann einmal die Zustandsbezeichner für die Fenster/Türsensoren geändert.
Die entsprechende Umsetzungsmethode in meinem Tool sieht inzwischen nicht mehr schön aus.