Readings, values und Units

[martinp876]

Hi,

Es kommen immer wieder Diskussionen ueber Einheiten in Readings hoch - FHEM hat m.W. keine Richtline um es zu vereinheitlichen.
m.M. (nicht unumstritten )sind Einheiten im Webfrontend sinnvoll und werden auch ein quasi allen mir bekannten Frontends angeboten. Auf der anderen Seiten steht die Forderung mit den Werten rechnen zu koennen und User muessen sich die Einheiten muehsam stripen, mehr oder weniger ungeschickt, je nach Erfahrung.
Da liegt eigentlich auch schon die Loesung: Im Frontend koennen (sollten m.M.) Einheiten vorhanden sein. Zum rechnen sollte man die Zahl erhalten. Den Wert sollte der User eh ueber eine Methode auslesen (aktuell ReadingsVal) -also einfach eine Methode anbieten, die den Wert eines Readings ausgibt. "Val" ist leider schon verbraucht (haette besser "Data" genannt werden sollen). Dann evtl "Num":
ReadingsTimestamp => Zeitstempel des Readings
ReadingsVal => nicht der Wert, aber die Datan des Readings
ReadingsNum => die Datan des Readings als Zahl

ein s /^([+-]?\d*\.?\d*).*/$1/
sollte die zahl aus einem Reading extrahieren - Rudi kanns bestimmt besser.

Offene Punkte:
Rueckgabewert, wenn ein Reading existiert, es aber keine Zahl ist - mein Vorschlag: der default Wert.

Unschoen: Einige Readings haben neben dem Wert auch Literals. So ist bei Rollo/dimmer der Endwert immer On/Off, dazwischen sind es Werte. Der User sollte den wert hier aus einem Anderen Reading nehmen - der Kernal kann hier nicht unterstuetzen.

Bei der Gelegenheit koennte man eine guidline fuer Development herausgeben, wie Einheiten dargestellt werden. Mein Vorschlag ist, mit space vom value (num... ) getrennt, damit der User es einfach splitten kann.

Gruss Martin

[rudolfkoenig]

Sowas geht leicht mit ReadingsVal(...)+0, aber wir koennen das auch als Funktion materialisieren.
Mir wuerde es aber besser gefallen es nur zu dokumentieren, und damit zum Perl-Wissen-Verbreitung beitragen.

[justme1968]

es gibt im wiki etwas über readings und einheiten. unter anderem ist dort festgelegt das readings ohne einheiten geschrieben werden sollen. da die diskussion vor meiner zeit war kann ich nicht sagen wie 'rechtskräftig' sie ist. genau so wie die dort beschriebenen interfaces ist es leidernicht wirklich umgesetzt. hier sollte das wiki angepasst werden so das erkennbar ist ob dort ein historischer zustand oder das gewünschte ziel beschrieben ist.

ich finde es aber sehr gut das wert und einheit nicht vermischt werden. das man im frontend zur anzeige aber einheiten haben sollte kann man davon unabhängig lösen.

ob man einheiten mitführen muss wenn man sich an die interfaces hält ist fraglich. wenn man es tut sollte man es getrennt vom wert tun. also z.b. den Readings...Update funktionen ein extra parameter unit verpassen und dann in $defs{myFHT}{readings}{measuredTemp}{unit} mitführen.

es gab vor einiger zeit auch einen patch der in die richtung ging und verworfen wurde.

vielleicht wäre eine zentrale zuordnung von reading name zu lesbaren einheiten praktisch die dann im frontend automatisch angezeigt werden könnten.

gruss
  andre

[Dr. Boris Neubert]

Hallo Martin,

siehe bitte http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Readings_2 und http://www.fhemwiki.de/wiki/DevelopmentInterfaces.

Wir hatten damals eine sehr tiefe Diskussion geführt, um zu diesen Ergebnis zu kommen. Die Diskussion mit allen pro- und contra-Argumenten ist in der fhem-developers-Mailingliste nachzulesen. Es gab auch die formelle Abstimmung E11 dazu.

Aus der Erinnerung die Kernaussagen:
- Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).
- Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.
- Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.
- Stattdessen meldet das Device, daß es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").
- Ein GUI weiß dadurch, was es anzuzeigen hat.

Leider wurden die Interfaces nie realisiert. Wir haben es noch nicht mal zu einer grundsätzlichen Vereinheitlichung der Readings-Bezeichnungen geschafft.

Viele Grüße
Boris

[betateilchen]

Leider wurden die Interfaces nie realisiert.

Schade eigentlich.

[martinp876]

@Rudi,
ok - wenn es mehr eine perl-trainingsstunde werden soll, ist dein Ansatz sicher ok.
Ich dachte aber mich zu erinnern, dass zumindest eine perlvariante Probleme hatte

@Boris
wenn das die Entscheidung ist, werde ich alle Einheiten entfernen. Die Diskussion ist schon gelaufen... sicher hat hauptsaechlich die Fraktion erfahrenen User und scriptschreiben abgestimmt - die wollen keine Einheiten. Ich stimme nicht zu, da jedes popelige Thermometer es schafft, eine Einheit in das Display zu platzieren, was die Lesbarkeit m.M. deutlich erhoeht. Ich denke, die wissen schon warum (ich lese es jedenfalls besser und schneller - viel schneller)
Eine web-darstellung muss doch eher lesbar als scriptfaehig sein.

Readings enthalten grundsaetzlich genau einen Wert und diesen ohne Einheit.

ist hoffentlich keine strikte Vorgabe. Oder liegt es an meiner lesart.... STATE kombiniert sehr oft mehrere Werte.

Einheit ergibt sich aus Festlegung gemaess "FHEM-Standard", z.B. immer SI-Einheiten, Temperaturen in Celsius, etc.

fahrenheit haben wir sicher nicht (oder?). Druck ist auch klar, Bar wird nicht mehr verwendet. level ist bei HM in Prozent....

Werde mit dem Loeschen der Einheiten beginnen, schweren Herzens ... die Hackermehrheit hat entschieden - gegen Lesbarkeit, pro scripting

Gruss, Danke Martin

[betateilchen]

fahrenheit haben wir sicher nicht (oder?)

aber Kelvin...

[martinp876]

korrekt... aber nur als literal (wenn ich keinen vergessen habe). Und auch nur bei den Registern. Die werden zwar als Reading ausgegeben, hier werde ich aber Einheiten belassen. Schliesslich gibt es
min, mA, deg, %, mV, alles nicht SI basis sondern abgeleitet.
Und die Zeiten eines VT100 sind (bei mir) vorbei, als man noch jedes Bit sparem musste...und hex editiert hat.
CUL_HM bietet
get regVal
an, das ist ein
get reg
ohne Einheit. Ist eh wenig direkte kontext Beschreibung vorhanden

[betateilchen]

Kelvin gibt es nicht nur bei Homematic.

[justme1968]

auch wenn ich der meinung bin das die einheiten nicht in die readings selber gehören bin ich durchaus der meinung das es wichtig ist sie im frontend anzuzeigen.

diese diskussion sollte also nicht auf ein entweder oder raus laufen sondern darauf das beides richtig und möglich ist.

also keine einheiten in den readings bzw. bei ReadingsVal aber so automatisch wie möglich in der anzeige im frontend.

fhem sollte hier durchaus hilfestellung geben. z.b. in form der interfaces, durch eine zuordnung zwischen reading name und einheit und vorbild im anzeigen der richtigen einheiten in fhemweb.

[betateilchen]

fhem sollte hier durchaus hilfestellung geben. z.b. in form der interfaces, durch eine zuordnung zwischen reading name und einheit und vorbild im anzeigen der richtigen einheiten in fhemweb.

Oder zumindest neben ReadingVal und ReadingTimestamp eine ReadingUnit als dritten Teil eines Reading.
Das dürfte meines Erachtens kurzfristig einfacher umsetzbar (und für viele Entwickler einfacher verständlich) sein als die Sache mit den interfaces.

[Markus Bloch]

Hallo zusammen,

grundsätzlich muss ich betateilchen und justme bei dieser Thematik recht geben. Es muss generell möglich sein im Frontend Einheiten darstellen zu können, die aber zur Weiterverarbeitung in eigenen Funktionen oder notify's und dergleichen keine Behinderung darstellen darf.

Gruß
Markus

[betateilchen]

ich habe inzwischen eine Unzahl von Funktionen in meiner 99_myUtils, nur weil selbst bei Angabe von Einheiten diese auch noch unterschiedlich gehandhabt werden, mal mit Leerzeichen zwischen Wert und Einheit, mal ohne. Mal °, mal °C ...

Wenn ich daraus einen RSS zur Statusanzeige generieren will, ist inzwischen der Großteil der Arbeit das Ausfiltern der Einheiten, um sie anschließend wieder formatrichtig und einheitlich anfügen zu können. Es wäre in der Tat eine große Erleichterung, dort irgendeine Art von Vereinheitlichung zu erreichen.

[Dr. Boris Neubert]

Wenn ich daraus einen RSS zur Statusanzeige generieren will, ist inzwischen der Großteil der Arbeit das Ausfiltern der Einheiten, um sie anschließend wieder formatrichtig und einheitlich anfügen zu können. Es wäre in der Tat eine große Erleichterung, dort irgendeine Art von Vereinheitlichung zu erreichen.

Oh ja, da stand ich vor ein paar Jahren auch, als ich begonnen hatte, DbLog zu schreiben. Die Masse des Codes bestand aus dem Auseinanderfrickeln von Zahlenwert und Einheit. Und deswegen hatte ich damals die Diskussion losgetreten, die zu der Idee mit den Interfaces führte.

Aber ist das denn wirklich so aufwendig? Zumindestens für die Module mit statischen Readings (also nicht OWDevice, ECMDDevice - sind aber meine und ich weiß, wie ich das löse) gibt es ja auch nicht soviele verschiedene Größen. Es müßte damit angefangen werden, diese im Wiki zu sammeln. Dort hatte ich damals einen Vorschlag für eine Hierarchie von Interfaces abgelegt. Und es gibt auch noch Fragmente in fhem.pl.

Viele Grüße
Boris

[betateilchen]

DbLog zu schreiben. Die Masse des Codes bestand aus dem Auseinanderfrickeln von Zahlenwert und Einheit.

das ist in DbLog auch heute noch so, und mit jedem neuen Device und neuen Messwerten wird es mehr