13_KS300.pm: units removed from readings

[Dr. Boris Neubert]

                                             

Hi,

I removed the units in parentheses from the readings in the KS300 module.

Previous version:
         2012-04-01 19:23:18   temperature     10.7 (Celsius)
         2012-04-01 19:23:18   humidity        29 (%)

Current version:
         2012-04-01 19:23:18   temperature     10.7
         2012-04-01 19:23:18   humidity        29

This makes it easier to postprocess the readings. I hope I did not break
anything else. I checked DBLog and PachLog.

Please report any problems here.

Kind regards
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Tobias]

                                                   

In den Readings sollte es einen eigenen Eintrag dafür geben
 Readings
         2012-04-01 19:23:18   temperature            10.7 (Celsius)
         2012-04-01 19:23:18   temperature_unit     Celsius

Gruss

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

die Einheitenfrage hatten wir in fhem-devel ausführlich diskutiert und sind zu der Entscheidung gekommen, die in http://fhemwiki.de/wiki/DevelopmentGuidelines unter Einheitendarstellung dokumentiert ist.

Viele Grüße
Boris



"Prof. Dr. Peter A. Henning" schrieb:

>Ich bin eigentlich dafür, in die umgekehrte Richtung zu gehen und die
>korrekten Einheiten - also °C und % - dabei zu lassen, sogar im
>hash
>einen eigenen Eintrag dafür zu machen.
>
>Es sollte dem Frontend überlassen werden, wie dies dann dargestellt
>wird.
>
>Bei den Log-Datein sehe ich das Argument der einfachen Verarbeitung ja
>ein
>- aber dann sollten Einheiten und Größenangaben bei Start eines neuen
>Log
>in eine/zwei Headerzeilen geschrieben werden und in den nachfolgenden
>Zeilen nicht mehr auftauchen. habe ich so bei meinem Photovoltaikmodul
>realisiert.
>
>Denn merke: Irgendjemand will die Daten  auch noch zehn Jahre später
>auswerten - und ohne Einheiten ist das manchmal nicht so einfach ...
>
>
>LG
>
>pah
>
>--
>To unsubscribe from this group, send email to
>fhem-users+unsubscribe@googlegroups.com

--
Diese Nachricht wurde von meinem WePad mit K-9 Mail gesendet.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Mag ja sein, dass Ihr das verworfen habt - das ist aber mit Sicherheit
nicht sehr sinnvoll. Dafür kann ich eine ganze Latte von Argumenten
präsentieren:

1. Gerade für die Internationalisierung muss es notwendig sein,
Temperaturen auch in Grad Fahrenheit anzuzeigen.
2. Die SI-Einheit der Temperatur ist nicht "Celsius", sondern "Grad
Celsius" oder "Kelvin" (ohne Grad).
3. Wenn man an einen AD-Konverter einen Feuchtesensor anschließt, möchte
man die Werte nicht als Spannung angezeigt bekommen - sondern entsprechend
der Kalibrierung des Sensors eben als Prozent.
4. Auch einen Zähler sollte man nicht einfach als nackte Zahl anzeigen -
sondern in den Attributen des Devices festlegen, was hier eigentlich
gemessen wird.
5  Mit zunehmender Komplexität von FHEM wieß irgendwann niemand mehr, was
die ganzen Zahlen bedeuten
6.... bliebig fortführbar.

Als Beispiel kann man sich das Modul OWAD.pm im contrib/1-Wire ansehen.
Damit kann ich für jeden der vier Kanäle festlegen
- wie er heißt (z.B. Humidity)
- welchen Typ die Messung liefert (z.B. voltage oder temperature)
- welche Einheit die Messung hat (z.B. Volt) und wie diese abgekürzt wird
(z.B. V).
Im hash stehen also außer {VAL} und {TIME} zusätzlich die Einträge {TYPE},
{UNIT} und {UNITABBR}

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Oskar]

                                                     

Am 11.04.2012 um 21:50 schrieb Prof. Dr. Peter A. Henning:
> Im hash stehen also außer {VAL} und {TIME} zusätzlich die Einträge {TYPE}, {UNIT} und {UNITABBR}

UNIT steht ja auch in den Development Guidelines.  Noch TYPE und UNITABBR dazu, und der Programmteil ist abgehakt.

Was eher lustig ist, wäre das Logfile.  Da würde ich mir eine generische Routine wünschen, die immer, wenn ein Logfile neu angelegt wird, die Parametrisierung ins Logfile schreibt. (in den ersten Zeilen, max. jeweils 3 Spalten).  Un natürlich updated, wenn sich die Einheiten ändern...

Grüße
   Oskar

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Da würde ich mir eine generische Routine wünschen, die immer, wenn ein
> Logfile neu angelegt wird, die Parametrisierung ins Logfile schreibt.

Wenn man darueber im klaren ist, wie Events in fhem implementiert sind, dann
kommt man schnell darauf dass sowas einen groesseren Umbau bedeutet.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Oskar]

                                                     

Am 12.04.2012 um 09:32 schrieb Rudolf Koenig:

>> Da würde ich mir eine generische Routine wünschen, die immer, wenn ein
>> Logfile neu angelegt wird, die Parametrisierung ins Logfile schreibt.
>
> Wenn man darueber im klaren ist, wie Events in fhem implementiert sind, dann
> kommt man schnell darauf dass sowas einen groesseren Umbau bedeutet.

Deswegen hab ich es auch noch nicht gemacht, sondern auf die Wunschliste geschrieben...

Frohe Pfingsten
   Oskar

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

Am 11.04.2012 21:50, schrieb Prof. Dr. Peter A. Henning:

> Mag ja sein, dass Ihr das verworfen habt - das ist aber mit Sicherheit
> nicht sehr sinnvoll. Dafür kann ich eine ganze Latte von Argumenten
> präsentieren:
es ist unstrittig, daß Klarheit darüber bestehen muß, welche Einheit die
Zahl in der Value-Teil des Readings hat.

Wie diese Klarheit hergestellt wird, war diskussionsfähig. Diese
Diskussion haben wir in fhem-devel ausführlich geführt (siehe
Mailingslisten-Archiv) und dann am 18.06.2010 als E9 zur Entscheidung
gestellt. Das Ergebnis ist im Wiki dokumentiert.

Ich werde diese Diskussion kein zweites Mal führen.

Viele Grüße
Boris


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Dr. Boris Neubert wrote:

> Ich werde diese Diskussion kein zweites Mal führen.

Dito.
-kai

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Nun, wenn das 3 Leute (!) vor 2 Jahren (!) so entschieden haben, muss das
natürlich richtig sein und für alle Ewigkeit Bestand haben...
Erinnert so etwas an das Statement von Bill Gates, dass man mit dem
Internet kein Geschäft machen könne.

Nur mal so interessehalber: Wie viele Sensoren und Aktoren sind seitdem
hinzugekommen ?

LG
pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

"Genersich" ist tatsächlich schwierig.

Braucht man aber auch nicht. In meinem Fall wird sowohl bei der
Fotovoltaikanlage (NT5000.pm) als auch beim umgebauten CUL_EM der erste
Eintrag des Tages als Tabellenheader ausgeschrieben.

LG
pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Nicht alles, was hinkt, ist auch ein Vergleich. Wer zu spät kommt, den bestraft das Leben.

Die Anzahl hinzukekommener Sensoren bestätigt eigentlich eher die Notwendigkeit, eine feste Norm zu haben. IMHO, YMMV.

Prof. Dr. Peter A. Henning wrote:
[...]

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Prof. Dr. Peter A. Henning wrote:
> Mag ja sein, dass Ihr das verworfen habt - das ist aber mit Sicherheit
> nicht sehr sinnvoll.

Leider hat uns -- also denen, die seinerzeit die Weiterentwicklung von FHEM
aktiv weiterführen wollten -- damals kein Weiser aus dem Morgenland den Weg
gewiesen. Vielleicht war's neblig ...

»Mit Sicherheit« ist folgender Punkt allerdings Quatsch:

> 1. Gerade für die Internationalisierung muss es notwendig sein,
> Temperaturen auch in Grad Fahrenheit anzuzeigen.

»Notwendig sein« »muß« es nicht, nie. Es mag eine Voraussetzung sein für
den FHEM-Durchbruch in den USA (»Heutzutage wird [die Fahrenheit-Skala]
nur noch in den USA und in wenigen anderen englischsprachigen Ländern
verwendet.[1]«) -- who cares? Und der Kernpunkt ist ja grade, daß durch
die Definition eines Bezugssystems, in dem bestimmte Daten vorliegen,
die _Anzeige_ in beliebigen lokalen Präferenzen möglich wird -- ohne
fallabhängiges Parsen der Werte (»17 °C«, »17 C«, »17 Grad«, ...).

MfG,
-kai


[1] http://de.wikipedia.org/wiki/Grad_Fahrenheit

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Weiser oder nicht, das lassen wir mal die Nachwelt entscheiden

Der Knackpunkt ist aber, dass die Zukunftsfähigkeit einer Anwendung heute
wesentlich davon bestimmt wird, wie viele Metadaten sie mitliefert.

Eine Zahl 24.3 besagt gar nichts - und weder ein beliebiger menschlicher
Nutzer, noch ein intelligentes Frontend kann erraten dass es sich hierbei
a.) um eine Temperatur und b.) eine Messung in der Einheit °C handelt.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Da die Metadaten implizit vorhanden sind, ist die »Zukunfsfähigkeit« nicht tangiert.

24.3 sagt für sich genommen nichts aus; der Unterschied zu 24.3 °C allerdings ist
marginal, denn eine Temperatur von 24,3 Grad Celsius mag für das Wohnzimmer OK
sein, für den Kühlschrank ist sie es nicht. Der Kontext ist entscheidend, mit den
nackten Zahlen arbeitet niemand, kann niemand sinnvoll arbeiten, egal, ob sie eine
Einheit in ihrer Rohform führen oder nich: "wenn eine Temperatur von FHEM unter
3.1415 °C oder über 52 °C liegt, löse die Selbstzerstörung aus" macht einfach
absolut keinen Sinn -- dies ist aber effektiv Dein Anwendungsfall. Hingegen ist
"wenn 'TKuehlschrank' unter 2.3 oder über 7.5 liegt, sende SMS" ein Szenario, wo
grade das Fehlen der Einheiten in den Rohdaten (die implizit aus der Tatsache, daß
TKuehlschrank ein Wert eines Temperatursensors ist, der in FHEM eben immer °C
liefert, dennoch bekannt sind) die Abbildung in "FHEM-Perl-Code" vereinfacht.

Ergo: Einheiten in den Rohdaten sind a) überflüssig und b) hinderlich -- und die
Darstellung sowieso Sache des UIs, nicht des FHEM-Kerns. QED.
-kai

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com