Readings, values und Units

[ntruchsess]

neben ReadingVal und ReadingTimestamp eine ReadingUnit als dritten Teil eines Reading.

Den Vorschlag unterstütze ich uneingeschränkt. Hätte auch den Charme dass man das 100% abwärtskompatibel gestalten könnte.

- Norbert

[Dr. Boris Neubert]

Hallo,

bin immer noch uneingeschränkt dagegen, siehe bitte http://forum.fhem.de/index.php/topic,6993.0.html.

Wesentliche Gründe: extra Hash-Lookup und Einheitendarstellungen sind eine benutzrtindividuelle Sache, die ins Frontend gehört und im Backend nichts verloren hat.

Grüße
Boris

[martinp876]

noch man zurueck zu meinem Vorschlag:
Frage 1) will man Einheiten im Frontend haben oder nicht? Diese Frage ist als erste zu klaeren und es ist keine technische. Meine Meinung steht fest. Dennoch habe ich mich natuerlich dem Beschluss gebeugt und alle aus CUL_HM entfernt. Registereinstellungen habe ich ausgenommen, die stehen nur in Readings, weil es keine adequate Gruppe hierfuer in FHEM gibt.

So man sich pro Units entscheidet kommt Frage 2: Wie realisiert man es. Es ist absolut ok in ReadingsVal einen Wert mit einheit zu schreiben - man braucht kein separates Datenfeld. Wie schon jetzt mit ReadingsVal und ReadingsTimestamp sollte man auf Readings nur mit Methoden zugreifen - und da kann man eine bauen, die nur einen Wert zurueckliefert. Das Aufspalten ist kinderleicht, da ein solches Reading immer <wert><unit> aussieht. Es ist komplett egal ob ein space dazwischen ist oder welche Unit das ist, Grad oder sonst etwas. Rudis Vorschlag mir "+0" halte ich fuer unschoen, wenn wohl auch machbar. Ein Reading (wie z.B. in state genutzt) das mehrere Werte beinhaltet ist eigentlich 'text' und wird hier nicht betrachtet.
Der Aufwand ist minimal.

Aus meiner Sicht wuerden dann ein paar andere Fragen bleiben:
ReadingsUnit  koennte man mit den gleichen geringen Aufwand realisieren - Unit ist alles was hinter einer fuehrenden Zahl steht, leading Space entfernen. Keine fuehrende Zahl, auch keine Unit.

Und die Sonderfaellen in denen Grenzwerte als ON/OFF  angegeben werden. (so bei Heizungen in HM). Das Datenfeld aendert hier sein Format. Die oben beschriebenen Methoden wuerden es komplett automatisch korrekt handeln.

=>  wie ich (zum 2. Mal) sehe ist man sich hier nicht einig. Wenn Frage 1 noch offen ist (oder wieder geoeffnet wird) bitte erst klaeren. Frage 2 (Realisierung) kann vielfaelltig geloest werden, von einfach und pragmatisch bis komplex. In jedem Fall sehe ich in der Realisierung keinerlei Probleme - sogar einfach jetzt (ohne Aenderung der vorhandenen Datensaetze).

Gruss Martin

[ntruchsess]

bin immer noch uneingeschränkt dagegen, siehe bitte http://forum.fhem.de/index.php/topic,6993.0.html.
Wesentliche Gründe: extra Hash-Lookup und Einheitendarstellungen sind eine benutzrtindividuelle Sache, die ins Frontend gehört und im Backend nichts verloren hat.

Hab mir die Diskussion von damals grade mal reingezogen. Da geht es fast ausschließlich über Zeitdarstellung, das Thema Einheiten wird da eigentlich nur am Rande diskutiert. Einigkeit herrschte damals im Wesentlichen darüber, dass die Einheit nicht in den value' des Readings gehört.

Das mit den Interfaces finde ich prinzipiell auch gut, leider hapert es ja mit dem Umsetzungsgrad. Tut ja irgendwie auch niemand nachverfolgen. Grundsätzlich würden Interface und zusätzlicher 'unit' eintrag im readings-hash sich ja auch nicht ausschließen. Effizienter als einen Zahlenwert aus dem value wieder herauszuparsen ist ein zusätzlicher Hash-lookup allemal.

[rudolfkoenig]

Meine Meinung:
- Ich habe kein Problem mit Einheiten, und verstehe das eigentliche Problem nicht.
- Wenn ein Modulautor es mit Einheit schoener findet, dann schreibt er es mit Leerzeichen hinter dem Zahl im Reading/Event, sonst laesst er es, und schreibt es in die Doku, so es unklar sein sollte. In 49% der Faelle ist es klar, was das fuer eine Einheit ist, und in weiteren 50% gibt es keine Einheiten.
- mit ReadingsVal(...)+0 kann man so ein Konstrukt zum Zahl konvertieren, das +0 braucht man gar nicht, man rechnet einfach. Damit die Diskussion hier beendet wird, kann ich gerne ReadingsNum und ReadingsUnit in fhem.pl einbauen, wozu man letzteres verwenden soll, ist mir noch ein Raetsel.
- Falls jemand interfaces will: die in der Wiki dokumentierten Namen fuer Readings/Events verwenden, und alle Readings/Events Dokumentieren. Module wie average und dewpoint funktionieren aber auch prima ohne Interfaces, und FHEMWEB (auch wenn nicht perfekt) braucht keine.
- Der Trend fuer Frontend geht dazu, dass der Benutzer bestimmt, wie man ein Geraet bedient, und nicht der Frontend- oder Backend-Autor.

[justme1968]

wenn man dir Einheiten in den readings erlaubt muss man auch das problem der aktualisierung von slider und menüs und co lösen. das macht zur zeit sogar probleme wenn die nachkommt stelle fehlt wenn sie null ist. das wird mit einheiten und leerzeichen nicht besser.

gerade die benutzer haben probleme mit den einheiten wenn sie mal da sind und und mal nicht. und sie stören sich an warnungen im log wenn man mit den readings rechnet und es nicht nur einfache zahlen sind.

gerade die anwender würden davon profitieren wenn man es im backend vereinheitlicht und dann hilfestellung gibt. das ist sogar noch viel wichtiger als die entscheidung mit oder ohne einheiten. es sollte nur einheitlich sein und überall gleich funktionieren. es hilft nicht wenn der anwender sich das frontend zwar gestalten kann wie er will das bei jedem device aber anders machen muss.

[martinp876]

da stimme ich zu. User HABEN Probleme und FHEM sollte (m.E.) immer klare Interfaces liefern. Ziel ist doch auch 'simple User' zu unterstuetzen.
Nicht gut finde ich, wenn jeder Einheiten unterschiedlich behandelt. Es wird nicht gelingen, alles zu vereinheitlichen - klar. Und zwingen kann man auch keinen. Aber man kann zu mindest eine Richtlinie herausgeben, an die man sich halten kann. Ich wuerde es machen (ok ich kenne nicht alle und suche nur selten... aber wenn ich eine finde halte ich mich daran).
Aktuell hat Boris mich auf eine verwiesen, die besagt: KEINE Einheiten. Ich bin dagegen ... aber die Richtlinie sticht.

Frage 1 ist fuer mich immer noch beantwortet mit: keine Units in Readings.

p.s. an ReadingsUnit haengt mein Herz sicher nicht - es ist nur die konsequente Kompletierung des Funktionssatzen, mehr nicht. Ein User koennte es nutzen um in eine Tabelle oder Datenbank zu schreiben - mir egal. Koennte er das auch selbst? klar, kann er alles. Er kann auch ReadingsVal selbst schreiben - warum also gibt es dies? Weil es nun einmal sauberer ist.

[Dr. Boris Neubert]

Frage 1) will man Einheiten im Frontend haben oder nicht? Diese Frage ist als erste zu klaeren und es ist keine technische.

Ich will Einheiten im Frontend haben. Ich bin aber kein Frontendentwickler und habe daher keinen Einfluß (außer Überzeugungskraft) darauf, daß standardmäßig im Frontend welche gezeigt werden. Also setze ich mir stateFormat.

Und ich will keine Einheiten im ReadingsVal haben.

Und ich möchte, daß wir es über alle Module einheitlich handhaben.

Rudi hat Recht, wenn er sagt, daß zunehmend die Anwender des Frontends entscheiden, wie die Darstellung aussehen soll (mit/ohne Einheiten, in °C oder °F, farblich abgestuft, als Thermometer-Widget, ...).

Die Frage teilt sich m.E. auf in zwei Komponenten:
- Welche Information stellt das Backend bereit (Diskussionsstand: im ReadingVal keine Einheit; Einheit idealerweise aufgrund Vereinbarung ableitbar)?
- Wie geht das Frontend damit um (Idealvorstellung aus dem Jahr 2010, beispielhaft: das Frontend erkennt das Interface "temperature", weiß dann, das das Gerät ein Reading "temperature" hat, welches in °C angegeben ist, wandelt das abhängig vom Locale des Anwenders z.B. in °F um und zeigt es mit Einheit an, oder auf einem °F-Thermometer-Widget, wenn der Anwender das konfiguriert hat)?


Im Moment sehe ich das Problem, daß sich die Modulautoren der Thematik der unterschiedlichen Darstellungen im Backend nicht bewußt sind. Aber hoffentlich trägt diese Diskussion dazu bei, der Entwicklung eine einheitliche Richtung zu geben.

Viele Grüße
Boris

[Markus Bloch]

Das fehlende Bewusstsein denke ich ist eher der Tatsache geschuldet, dass die aktuelle Richtlinie keine Einheiten vorsieht. Und so kocht dann jeder sein eigenes Süppchen.

Um das ganze zu vereinheitlichen, muss meiner Meinung nach erstmal eine Richtlinie her, die Einheiten vorsieht und wie Module sich hierbei zu verhalten haben, ganz unabhängig davon was sich am Ende daraus entwickelt

Die Tatsache, dass dieses Thema in letzter Zeit immer wieder hochpoppt zeigt mir, dass hier etwas getan werden muss.

Viele Grüße

Markus

[betateilchen]

- Ich habe kein Problem mit Einheiten, und verstehe das eigentliche Problem nicht.
- Wenn ein Modulautor es mit Einheit schoener findet

Frei nach dem Motto: Wenn jeder an sich selber denkt, ist an jeden gedacht...

Dabei geht es doch hier in keinster Weise um die Frage, ob es "schöner" ist oder nicht, sondern ob solche Messwerte in einem inzwischen so komplexen Konstrukt wie fhem mit seinen unzähligen Darstellungs- und Verwendungsmöglichkeiten noch damit zurechtkommt. Und da liegt der Hund begraben.

Für mich gehört in ReadingsVal definitiv keine Einheitenangabe.

Wie z.B. ein floorplan dann in seiner Darstellung den Messwert verarbeitet, um ihn korrekt und mit Einheit darzustellen, ist eine völlig andere Aufgabe, aber nicht die Aufgabe des Modulentwicklers, der die Daten aus irgendeiner Hardware ermittelt. Mir als Modulentwickler ist letztenlich völlig wurscht, wofür die Werte verwendet werden, die mein Modul in die Readings schreibt.

Für die korrekte Darstellung in meinen RSS musste ich mir dafür auch selbst eine Logik bauen, die das bewerkstelligt, und diese Logik hätte sehr viel einfacher ausfallen können, wenn mir ReadingsVal nicht immer diese verdammten Anhängsel mitliefern würde.

[martinp876]

ich stimme Markus voll und Boris teilweise zu.

- offensichtlich besteht Handlungsbedarf (m.E. dringend)
- so lange es keine Richtlinie gibt MUSS es einen Wildwuchs geben - geht garnicht anders
- warum man Einheiten nicht in {READINGS}{VAL} setzen kann oder darf ist mir unklar. Alle User ausserhalb des Moduls sollten ausschliessliche Methoden nutzen, und die bereiten es entsprechend auf. Damit diese Methoden funktionieren braucht es ein Minimum and Konventionen.
-->mit {READINGS}{VAL} kann man nie bedenkenlos rechnen, auch nicht mir ReadingsVal. Das kann immer aucn ein text sein... so what

- Einheiten am Namen des Readings festzumachen bedingt eine weitere Betrachtung:
-- leider ist die Standardisierung von Readingsnamen nicht wirklich vorhanden. Diese Namen zu aendern ist ein Problem, da es allen moeglichen Usern ihre notifies um die Ohren hauen wird. Schlimmer noch die Notifies die ein User muehsam erstellt und getestet hast und die kritisch sind aber selten gebraucht werden. Der User wird das nicht-mehr-funktionieren evtl garnicht bemerken.
-- eine Namensvergabe muss eindeutig und klar spezifiziert sein. temperatur ist bei weitem nicht hinreichend. Meine Thermostate benoetigen eine Vielzahl davon. Sinn macht die Vereinheitlichtung nur, wenn auch die Bedeutung uebereinstimmt!!! (Gemessen, gesetzt, konditional gesetzt....)
-- es wird garantiert immer Readings geben, die nicht standardisiert sind und doch eine Einheit haben wollen. dafuer bedarf es auch einer Methode!

Ich sehe nur 3 Optionen (unabhaengig von vergangenen Diskussionen)
1){READINGS}{UNIT}
2){READINGS}{VAL} mit eingebauten Einheiten, space-separated
3) keine Units

Bei der Entscheidung sollten deben Befindlichkeinten und vorleiben einzelner die Realitaeten nicht vergessen werden:
- einfache Umstellung vom status quo - insbesondere fuer User (auch fuer Entwickler - aber die koennen nachsitzen )
- Zukunftssicherheit. Sich auf vorhandene Readings und ein paar Temperaturen zu beschraenken ist nicht hinreichend! Man muss neue Readings mir Einheiten erstellen koennen - egal ob es Inch, Galonen, Lichtjahre, Becquerel oder Lux sind. Der Kernal MUSS die Methoden bereitstellen und die Richlinie fuer Entwickler MUSS eine Regelung bereitstellen.
Frei nach dem Motto, als ich diese Diskussion vor ~1a schon einmal gestartet habe:
"sei ruhig und warte ab, es koennte schwieriger werden - ich wartete ab und es wurde schwieriger"

Mein Votum ist
1):weniger Arbeit fuer mich - gefolgt von 2): auch kein Problem - kann man sofort realisieren (Vorschlag erstes Post im Threat)

[betateilchen]

Ich wäre ganz klar auch für 1){READINGS}{UNIT} das ist am logischsten zu verstehen und uch den weniger programmierungsorientierten Anwendern am besten vermittelbar.

[rudolfkoenig]

Ich bin fuer 2.

[betateilchen]

Wenn Du dazu zwei zusätzliche Funktionen ReadingsValOnly() (liefert Rückgabewert ohne Einheit) und ReadingsUnit() (liefert nur die Einheit) schaffst, ist 2.) durchaus denkbar.

Es ist zwar eine Krücke, aber es würde irgendwie funktionieren. Wie viele andere "Rudi-Lösungen" auch.

[Markus Bloch]

Bin ebenfalls für Variante 1, da es die sauberste Variante gegenüber Variante 2 ist.

Ich bin gerne bereit entsprechenden Aufwand zu leisten.