13_KS300.pm: units removed from readings

[Oskar]

                                                     

Ihr wollt schon gerne aneinander vorbei reden.  Oder verstehe ich das nicht?

Ihr seid doch auch alle der Meinung, das die Einheiten im aktuellen Logeintrag (Zeile) nichts zu suchen haben, oder?
Die einzige Frage ist doch, wo die zum Zahlenwert gehörigen Metadaten (Einheit und der ganze Kram) gespeichert wird bzw. ob überhaupt.

Wenn Ihr so weitermacht, kommt das hier wohl eher nicht voran.  Im übrigen sind die Metadaten eben nicht implizit vorhanden.  Zumindest nicht im Logfile.  Da steht nur, dass ein vom Nutzer beliebig benannter Sensor irgendwelche Daten angeliefert hat.  Manchmal mit Beschreibung, manchmal mit so komischen Abkürzungen wie T, H, D oder so.

Grüße
   Oskar

Ihr seid doch auch der Meinung, das Suggestivfragen doof sind?

Am 15.04.2012 um 12:09 schrieb Kai 'wusel' Siering:

> 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

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

[Guest]

Originally posted by: <email address deleted>

Nein, so billig kommst Du mir nicht davon.

Der Kontext muss sich natürlich aus dem Namen ergeben. Wenn Das
Wohnzimmerthermometer t1 und das Kühlschrankthermometer t2 heißen, besteht
das Problem natürlich. Darum soll die Definition des Gerätes enthalten

1.Typ der Messgröße (z.B. temperature). Diese folgt manchmal aus dem
Sensormodell (z.B. messen Thermometer eigentlich nur Temperaturen), an
anderer Stelle sollte sie explizit angegeben werden (z.B. wenn man mit
einem AD-Wandler + Sensor die relative Feuchte misst)
2.Name (mit Kontextbezug, also von mir aus "Kühlschrank_T")
3.Einheit (z.B. Kelvin)

Erst durch diese Angaben im Hash kann das Frontend vollständig vom Backend
getrennt werden - und alle für eine Darstellung notwendigen Angaben an
einer Stelle erhalten.

@oskar: Natürlich gehören die Einheiten in jede Logdatei. Aber nur einmal -
es ist überflüssig, sie in jeder Zeile zu haben.

LG

pah

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

[Guest]

Originally posted by: <email address deleted>

Dein lustiger AD-Wandler braucht ein Modul; dort wird definiert, was für ein Wert da gemessen wird (Temperatur, Feuchte, Zählerstand, ...).

Hernach ist für FHEM und Frontends klar, wie der Wert zu interpretieren ist. Der Name hat nur für den Nutzer eine Funktion, für FHEM als auch die Frontends ist es ein beliebiger Wert. (Wer gerne durch Logfiles waten will, tut wahrscheinlich gut daran, sich an ein Schema zu halten. Aber das ist nicht das Thema.)

Einheiten haben in einem maschinengelesenen Log nichts verloren; und schon gar nicht nur an exponierter Stelle, grade das verkomplizierte die Verarbeitung massiv. (Wer loggt, tut das nicht auf 32 MB USB-Sticks; insofern sind die paar Bytes/Zeile für die Einheit eh' zu vernachlässigen, der Mehraufwand für "erste-Zeile-Sonderbehandlungen" in Relation nicht zu rechtfertigen.) FHEM kann über den Devicenamen alle notwendigen Informationen ermitteln. Wer ein Ewiges Wetterlog starten will, loggt eben separat via notify und angehängter Einheit und schreibt sich einen eigenen Plotter für sein Logfileformat.

Streit um des Kaisers Bart, eines toten Kaisers (Thema ist schon durch) obendrein. Daß die Planungen für FHEM5 von der Realität (FHEM5 ist schon da, aber nicht wie geplant) überholt wurden, ist nur bedingt hilfreich.

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

[Guest]

Originally posted by: <email address deleted>

Jan-Hinrich Fessel wrote:
> Ihr wollt schon gerne aneinander vorbei reden.  Oder verstehe ich das nicht?

Ich denke nicht, daß Herr Prof. Dr. und meinereiner aneinander vorbei reden; er mag unnötig komplizierte Logfiles, ich welche, die einfach weiterzuverarbeiten sind. Aus meiner Sicht ein ziemlicher Gegensatz

> Ihr seid doch auch alle der Meinung, das die Einheiten im aktuellen Logeintrag (Zeile) nichts zu suchen haben, oder?

Ich bin der Meinung, daß sie im Logfile gar nichts verloren haben. Er ist dieser Meinung: »Natürlich gehören die Einheiten in jede Logdatei. Aber nur einmal [...].«

> Wenn Ihr so weitermacht, kommt das hier wohl eher nicht voran.

Die Diskussion mit "pah" ist eine akademische; Zitat Boris:

| 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.

Aber mit der Realität ist das ja so eine Sache

> Im übrigen sind die Metadaten eben nicht implizit vorhanden.  Zumindest nicht im Logfile.  Da steht nur, dass ein vom Nutzer beliebig benannter Sensor irgendwelche Daten angeliefert hat.  Manchmal mit Beschreibung, manchmal mit so komischen Abkürzungen wie T, H, D oder so.

Yepp; und die Gretchenfrage ist wohl eigentlich die, wem das Logfile dienen soll; derzeit wird dies meinem Verständnis nach von FHEM intern benutzt, um z. B. die Graphen zu malen. Ergo hat da drinzustehen, was FHEM hierzu braucht. Technisch braucht FHEM die Einheiten nicht, denn die könnte es intern nachschlagen.
Im Endeffekt allerdings ging es IIRC mal darum, von dem "mnchmal mit Beschreibung, manchmal mit so komischen Abkürzungen" wegzukommen, es also auch den Frondends einfacher zu machen.

FHEM hindert jedenfalls meines Wissens niemanden, ein beliebig formatiertes Logfile für eigene Bedürfnisse zu schreiben -- die (Unix-)Shell ist da ziemlich mächtig ...

Ciao,
-kai

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

[Guest]

Originally posted by: <email address deleted>

Na, da ist dein Wissen aber nicht auf dem aktuellen Stand der Informatik -
vielleicht kommst Du mal zu mir in die Vorlesung

Natürlich gehören Einheiten in ein maschinenlesbares Log - schau Dir
vielleicht mal an, warum wir im Semantic Web versuchen, alles mit Metadaten
zu versehen

Es ist außerdem großer Unsinn, für verschiedene Messwerte mit der gleichen
Hardware unterschiedliche Module zu bauen. Ein Modul, das den A/D abfragt,
darf eben nicht hartcodiert die gemessenen Größen und Einheiten drin haben

LG

pah

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

[rudolfkoenig]

                                                   

>    - Stand der Kunst in der Informatik ist, Daten mit so vielen Metadaten
>    zu versehen, dass ihre BEDEUTUNG klar ist. Wer darauf verzichtet, setzt
>    sich der Gefahr aus, dass er in 5 Jahren nicht mehr weiß, um was es
sich
>    handelt.

Mein Senf dazu, da das Problem durch totschweigen sich nicht erledigt,
sondern
sich eher ausbreitet.

Management Summary:
Ich bin dagegen _alle_ zum Auswerten _benoetigten_ Metadaten in den Log zu
schreiben, und automatisch geht das mAn schon gar nicht.

Details:
Wenn irgendwer (z.Bsp. ich in 5 Jahren, oder jemand der meine logs gefunden
hat) nicht genau weiss, was in einem Log gespeichert sind, dann werden
automatisch generierte Metadaten auch nicht helfen.
Das es sich um Temperatur in Celsius handelt wird man wahrscheinlich am
ehesten
rauskriegen, was und wie ich gemessen habe (z.Bsp. Sensor an dem Keller-
Innenwand, direkt ueber dem Heizrohr), werden mir die automatisch
generierten
Metadaten nicht verraten.  Und ohne diese Information ist mAn eine
Auswertung
bedeutungslos.

Umgekehrt finde ich es auch unwahrscheinlich, dass man noch weiss, wo genau
welcher Sensor war, aber nicht mehr, dass es in Celsius oder in Fahrenheit
gemessen hat. Wer vergesslich ist, kann selber Notizen anfertigen, das muss
aber nicht automatisch ins logfile geschrieben werden.

Wohlgmerkt ich bin nicht dagegen, dass der Benutzer genau weiss in welcher
Einheit gemessen wird, das muss aber nicht unbedingt ins Logfile.

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

[Guest]

Originally posted by: <email address deleted>

Salve,

On 04/17/2012 10:07 PM, Prof. Dr. Peter A. Henning wrote:

> Na, da ist dein Wissen aber nicht auf dem aktuellen Stand der Informatik

Starker Tobak. Mit der Verdrehung von Aussagen allerdings kommst Du auch nicht weiter. Ich schrieb ...

| FHEM hindert jedenfalls meines Wissens niemanden, ein beliebig formatiertes Logfile für eigene Bedürfnisse zu schreiben -- die (Unix-)Shell ist da ziemlich mächtig ...

... und dieses Wissen hat nichts mit informatorischen Theorien zu tun. Wer lesen kann, ist klar im Vorteil. Korrektes Zitieren ist in akademischen Zirkeln ja leider keine Tugend mehr.

> - vielleicht kommst Du mal zu mir in die Vorlesung

Da ich befürchten muß, daß Du auch dort meilenweit am Thema vorbei redest, verzichte ich dankend.

> Natürlich gehören Einheiten in ein maschinenlesbares Log

Nope. Einheiten haben im hier diskutierten maschinengelesenen Log nichts verloren, denn FHEM kann über den Devicenamen alle notwendigen Informationen ermitteln, diese Information ist also redundant. Die Präsentation der Werte ist nicht gebunden an die Rohdaten.

> schau Dir vielleicht mal an, warum wir im Semantic Web versuchen, alles mit Metadaten zu versehen

Auch hier wiederhole ich mich: nicht alles, was hinkt, ist ein Vergleich. Das Semantische Web ist etwas vollkommen anderes als ein Logfile einer (konkreten) FHEM-Installation bzw., genauer, das Logfile eines Sensors einer solchen. Die »Metadaten«, die Du so krampfhaft in den Logs unterbringen willst -- was übrigens nicht wirklich was mit Metadaten zu tun hat; Metadaten wären es, wenn Du fordertest, zum jeweiligen Logfile eine Beschreibungsdatei zu erzeugen -- sind schon da, denn per Definition weiß FHEM ja, daß Temperaturen in Grad Celsius gespeichert werden (Kelvin wäre möglich, aber unpraktisch und im Haupteinsatzgebiet von FHEM, der Hausautomatisierung, auch nicht gebräuchlich). Bei der Nutzung außerhalb von FHEM, z. B. im Semantischen Web, mußt Du diese Information mittransportieren.

> Es ist außerdem großer Unsinn, für verschiedene Messwerte mit der gleichen Hardware unterschiedliche Module zu bauen.

Im Prinzip schon, und auch wieder nicht. In einem gesteuerten Projektteam sollte es nicht so sein; das ist aber nicht der aktuelle Ansatz bei FHEM. Und das ist gut so, imho.

MfG,
-kai

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