Readings, values und Units

[betateilchen]

Die Umfrage gabs schon, als Du danach gefragt hattest.

Wenn Du Units willst, die nicht in {READINGS}{VAL} stehen sollen, würde ich Variante 1 empfehlen.  Dann sind sie nicht in {VAL} und auch nicht "nicht vorhanden"

[martinp876]

um noch einmal quer zu schiessen:
Bisheriges handling: Readings werden (nicht wie attribute)  nicht definiert sondern einfach angelegt. AUCH USER KOENNEN READINGS ERZEUGEN!

Demnach ist eine Unit bei der Reading Instanz - egal wie (Loesung 1 oder 2)

bisher werden readings erzeugt indem man diese einzeln oder im Block einfach anlegt. Muss dann bei jeder Aenderung des Readings die Unit mitgegeben werden, oder nur min einmal? Bei Loesung 2 natuerlich jedes mal... bei einem separaten Datenfeld muss das Vorgehen definiert werden.

Eine Loesung die auf eine Definitionspflicht von Readings hinauslaeuft ist definitiv ein sehr tiefer Einschnitt. In HM kann ich das nicht leisten, da die Reading Namen dynamisch wachsen. Ein no-go.
Anders gesagt: Readings in seiner Einfachheit und flachen Konstruktion hat vor und nachteile. Wenn jemand vor hat, die Felxibilitaet zu bescheniden gibt es grosse Probleme! Da muss dann deutlich mehr investiert werden!

Mein resumee aktuell: Unit muss dem Reading zugeordnet sein  (geht mir Loesung 1 und 2)

Wenn ihr weitere Sachen ableiten wollt (thermometer,...) ueberlegt doch gleich, ein Datenfeld {type} dran zu haengen. So 'teuer' ist es nicht. Also erst einmal die korrekte Frage auf den Tisch:
- welche Anforderungen ausser Value und Unit hat ein Reading noch? Welche Info soll abgeleitet werden koennen? Grafiken, slider, interfaces zu Modulen... - was sind die Anforderungen?
"heimlich" einen parser einbauen, der versucht aus dem Namen oder und der Einheit infos abzuleiten ist immer gewagt, meist problematisch und sicher fehleranfaellig.

Und Rudis Methoden zum separieren von "number" und "unit" ist m.E. kein Performancekiller. ein separates datenfeld bedarf einiger aenderungen.
von temporaerer dopple-datenhaltung halte ich garnichts - schlechtes upgrade konzept. das geht sicher besser!

[Dr. Boris Neubert]

Wenn Du Units willst, die nicht in {READINGS}{VAL} stehen sollen, würde ich Variante 1 empfehlen.  Dann sind sie nicht in {VAL} und auch nicht "nicht vorhanden"

Ich will keine Einheiten in {READINGS}{VAL}. Ich will dafür aber kein {READINGS}{UNIT} sondern erst einen Diskurs darüber, a) was wir eigentlich wollen (Semantik!) und b) wie das dann abgebildet wird. Wir vermischen hier Anforderung und Lösung. Damit habe ich schlechte Erfahrungen gemacht.

Bin ich ein Spalter, wenn ich noch eine Umfrage einstelle? 

Viele Grüße
Boris

[Dr. Boris Neubert]

Demnach ist eine Unit bei der Reading Instanz - egal wie (Loesung 1 oder 2)

Also die gesamte Semantik (Danke für den Begriff, Norbert!) hängt an der Instanz (das ist eine Feststellung, die wir gemeinsam getroffen haben).

Mein resumee aktuell: Unit muss dem Reading zugeordnet sein  (geht mir Loesung 1 und 2)

Also zu jedem Reading muß sich jederzeit zweifelsfrei die Semantik bestimmen lassen (das ist eine Anforderung, keine Aussage zu ihrer Realisierung).

Wenn ihr weitere Sachen ableiten wollt (thermometer,...) ueberlegt doch gleich, ein Datenfeld {type} dran zu haengen. So 'teuer' ist es nicht. Also erst einmal die korrekte Frage auf den Tisch:
- welche Anforderungen ausser Value und Unit hat ein Reading noch? Welche Info soll abgeleitet werden koennen? Grafiken, slider, interfaces zu Modulen... - was sind die Anforderungen?

Bisher habe ich folgende Anforderungen gesehen, was die Semantik leisten soll:

• Es soll die physikalische Größe erkennbar sein, die im Reading repräsentiert ist (z.B. Druck, Temperatur, Schaltzustand, Strecke, Ventilöffnung)
• Es soll daraus eine vom Anwender abhängige Einheit für die Darstellung in einem Frontend ableitbar sein.
• Es soll daraus eine sinnvolle Vorgabe ableitbar sein, welches Bedienelement ein Frontend standardmäßig anzeigt (wie jetzt FHEMWEB z.B. die Lampe bei on/off).

"heimlich" einen parser einbauen, der versucht aus dem Namen oder und der Einheit infos abzuleiten ist immer gewagt, meist problematisch und sicher fehleranfaellig.
Und Rudis Methoden zum separieren von "number" und "unit" ist m.E. kein Performancekiller.

Ich halte es nicht für sinnvoll, Zahl und Einheit in ein Feld zu schreiben, wenn für praktisch alle Verwendungen des Feldes Zahl von Einheit wieder getrennt werden muß. Ich kann dann noch nicht einmal in einem Frontend z.B. bei einer Wetterstattion die Zahlen für Druck, Temperatur und Luftfeuchte rechtsbündig untereinander ausrichten.

von temporaerer dopple-datenhaltung halte ich garnichts - schlechtes upgrade konzept. das geht sicher besser!

Zumindest habe ich mit meinem Vorschlag erreicht, daß dieser Punkt auch besprochen wird. Ich plädiere dafür, erst die Anforderungen zu definieren, dann die Lösung zu suchen unter besonderer Beachtung des Migrationsbedarfs.

Grüße
Boris

[betateilchen]

Wir vermischen hier Anforderung und Lösung.

Dieses Vorgehen ist doch hier im Forum quasi Standard. Das ist ja das oftmals extrem Frustrierende.

[betateilchen]

Muss dann bei jeder Aenderung des Readings die Unit mitgegeben werden, oder nur min einmal?

Wenn es wirklich ein {READING}{UNIT} geben sollte, ändert sich das doch nicht mehr dadurch, dass {READINGS}{VAL} dieses readings sich ändert. Ob es von der Programmierung her vielleicht einfacher ist, den Wert trotzdem jedesmal mitzugeben, ist eine andere Frage.

[ntruchsess]

Bisher habe ich folgende Anforderungen gesehen, was die Semantik leisten soll:

• Es soll die physikalische Größe erkennbar sein, die im Reading repräsentiert ist (z.B. Druck, Temperatur, Schaltzustand, Strecke, Ventilöffnung)
• Es soll daraus eine vom Anwender abhängige Einheit für die Darstellung in einem Frontend ableitbar sein.
• Es soll daraus eine sinnvolle Vorgabe ableitbar sein, welches Bedienelement ein Frontend standardmäßig anzeigt (wie jetzt FHEMWEB z.B. die Lampe bei on/off).

Schaltzustand und Ventilöffnung würde ich nicht als 'physikalische Größe' ansehen. Das sind logische (boolsche) Werte oder Zahlen zwischen 0 und 1 (0%-100%) ohne Einheit (man kann natürlich darüber philosophieren, ob man '%' als Einheit oder Abkürzung für 1/100 ansieht). Wenn vom User sonst nix anderes definiert ist, entscheidet das Frontend ob da z.B. die on/off-Lampe, bzw. der Slider kommt.

Ansonsten bin ich d'accord.

[betateilchen]

- welche Anforderungen ausser Value und Unit hat ein Reading noch?

beispielsweise:

Code Auswählen Erweitern


{READINGS}{TIME}
{READINGS}{VAL}
{READINGS}{TYPE}
{READINGS}{UNIT}


Verbunden mit Ableitungsregeln:

Aus TYPE kann die UNIT bestimmt werden kann (und wird bestimmt) sofern in UNIT nichts anderes angegeben ist.
Ist UNIT angegeben, wird TYPE ignoriert.
Ist weder TYPE noch UNIT angegeben, wird das Reading ohne jegliche Einheit dargestellt.

[ntruchsess]

beispielsweise:
Verbunden mit Ableitungsregeln:

Aus TYPE kann die UNIT bestimmt werden kann (und wird bestimmt) sofern in UNIT nichts anderes angegeben ist.
Ist UNIT angegeben, wird TYPE ignoriert.
Ist weder TYPE noch UNIT angegeben, wird das Reading ohne jegliche Einheit dargestellt.

Ich habe die Anforderung(sic!) das das Gerät dem Frontent im reading etwas über die konkrete Art einen Wert zu interpretieren ('was ist das'?) mitteilen kann.
Zusätzlich habe ich die Anforderung, dass die separat übermittelte physikalische Einheit (unit - 'welcher Maßstab wird eigentlich verwendet'?) orthogonal zur Art des readings zu interpretieren ist.

Die physikalische Einheit kann das Frontend verwenden um den Wert nach Userwunsch z.B. von 'm' nach 'yrd' umzurechnen.
Den typ kann das Frontend nutzen um weitere Rückschlüsse auf die zu verwendende Darstellung zu ziehen. (Beispiel ein Tankfühler kann als 'Füllstand' eine Strecke, ein Volumen aber auch einfach einen %-Wert liefern).

- Norbert

[betateilchen]

Ich finde das krampfhafte Festhalten an "physikalischen Einheiten" generell nicht zielführend, weil es viel zu viele Readings gibt, die überhaupt keine physikalische Einheit repräsentieren. Eine physikalische Einheit könnte aber aus {TYPE} abgeleitet werden.

[ntruchsess]

Eine physikalische Einheit könnte aber aus {TYPE} abgeleitet werden.

Wie gehst Du vor, wenn der typ wie in meinem Beistpiel ein Tankgeber und im value die Zahl 102.5 zu finden ist?

[betateilchen]

Dann muss entweder fhem einen definierten TYPE=Tankgeber kennen und daraus EINDEUTIG ableiten können, welche Einheit dazugehört. Oder es darf den TYPE=Tankgeber nicht geben.

Damit sind wir wieder beim Interface-Thema:

Entweder es wird ein in fhem bekannter TYPE verwendet, oder der TYPE muss vom entsprechenden Modul (in diesem Fall das zum Tankgeber gehörende) entsprechend bekanntgemacht werden.

[Dr. Boris Neubert]

Dann muss entweder fhem einen definierten TYPE=Tankgeber kennen und daraus EINDEUTIG ableiten können, welche Einheit dazugehört. Oder es darf den TYPE=Tankgeber nicht geben.

Damit sind wir wieder beim Interface-Thema:

Entweder es wird ein in fhem bekannter TYPE verwendet, oder der TYPE muss vom entsprechenden Modul (in diesem Fall das zum Tankgeber gehörende) entsprechend bekannhttp://forum.fhem.de/Smileys/default/sad.giftgemacht werden.

Langsam dämmert mir wieder, daß als eine wesentliche Erkenntnis aus der 2010er Diskussion herauskam, daß eine in sich abgeschlossene Lösung aus Backend und Frontend nicht existieren kann und die (damals in ähnlicher Weise) gewünschten Ziele nur erreicht werden, wenn eine übergreifende Konvention als die Semantik beschreibende Metainformation existiert. Hat man dies erst akzeptiert, kommt man schnell darauf, daß man die Einheiten gar nicht explizieren muß, sondern diese aus der Konvention abgeleitet werden können.

Ich finde den verflixten Thread nicht, wo das drinsteht.

Und noch verflixter ist, daß ich ab gleich drei Tage verreist bin und allenfalls abends auf einem Tablet kurze Gedankenimpulse absondern kann statt an dieser ungemein spannenden und wichtigen Wiederbelebung des Themas mitzuarbeiten.   

Viele Grüße
Boris

[betateilchen]

Und noch verflixter ist, daß ich ab gleich drei Tage verreist bin

Ich ab Donnerstag. Einen Tag CeBIT, danach von Hannover aus abends direkt an die Nordsee zum Kurzurlaub bis einschließlich Montag

Mir ist übrigens noch was eingefallen - Aufteilung in Mantisse und Exponent.

Eine Strommessung hat als physikalische Einheit Ampere. Der Leistungsmesser von Homematic liefert mA. Und ggf. findet man eine Darstellung 67mA schöner als 0,067A

[justme1968]

das ist etwas das ich im frontend sehe.

zu konfigurieren wie die anzeige 'skaliert' wird.

aber auch das geht erst wenn das frontend die möglichkeit hat zu 'verstehen' was die readings bedeuten.