Readings, values und Units

[betateilchen]

Ich nehme mit
1) die Entscheidung ist gefallen

ich kann bisher nicht erkennen, dass hier irgendeine Entscheidung gefallen ist / getroffen wurde.

4) Sonderfälle
Ein Dimmer (nicht nur der) hat die Werte 0% bis 100% - wobei 0 und 100 mit On und Off ersetzt werden.

Was aber nicht immer richtig ist, weil bei FS20 z.B. DIM100% und ON zwei verschiedene Zustände sind.

nachdem hier die große Lösung gewählt wurde

wo ist "hier" und wo wurde gewählt?

[papa]

1) die Entscheidung ist gefallen readings von einem wert mit Zeitstempel zu einem Objekt aufzublasen. Next: Definition der Attribute des Objekts:

Warum nicht die Daten von den Metadaten (Typinformationen) trennen ? Damit muss für jedes Readingnur der Typ (und der Kommentar) am Device vermerkt werden. Der Standard Typ wäre 'String', wenn keiner definiert ist. Alles andere kommt in eine Typdefinition. Das Reading selbst ist nur der Wert. Eine Type-API stellt Funktionen zur Formatierung und Umwandlung basierent auf den Typdefinitionen bereit. Man könnte auch Vererbung mit vorsehen, dann könnte man "einfach" kleine Änderungen am Verhalten durch Ableiten vom Basistyp mit entsprechender Anpassung erreichen.

2) Implementierung
ich gehe davon aus, dass das Niveau beibehalten wird. Sprich es wird Methoden für den Zugriff geben, zum Definieren, Ändern, Lesen und Löschen der Objekte und dessen Attribute. Incl Beschreibung der Syntax und Semantic.

API für Formatierung, Umwandlung usw. muss sein

3)Darstellung
Da das Frontend nun alle Infos für die Darstellung hat, wird es dies auch selbständig handhaben. Die Zentrale liefert nur die Methoden zum Zugriff auf die Werte.
Der Kommentar sollte beim fahren mit der Maus über das Datenfeld angezeigt werden(können)

Dann könnt der Nutzer auch festlegen, wie eine Temperatur angezeigt wird (z.B. °C oder F)

4) Sonderfälle
Wie wird beispielsweise mit Level umgegangen? Ein Dimmer (nicht nur der) hat die Werte 0% bis 100% - wobei 0 und 100 mit On und Off ersetzt werden. Die Darstellung im Frontend  mit Einheiten muss berücksichtigen, dass das Datum seinen Inhalt von "float/percent/%/0,5-99,5 " nach "literal/text///" ändert. Ggf. sollte das Ersetzen von 0/100 nach On/Off  auch in den Attributen festgelegt werden.

Das Reading sollte immer nur den Basiswert beinhalten - also 0-100. Ein Transfer in andere logische Zustände könnte mit einem Mapping am Type definiert werden. Eine entsprechende Zugrifffunktion kann dann für die Umwandlung sorgen. Somit ist auch immer klar, dass nur umgewandelt wird, wenn auch diese Funktion benutzt wird.

5)Evolution
- Aktuelle Readings, oder Readings die nicht entsprechend definiert wurden werden als Text verarbeitet
- Das Handling von Notify und eventMap muss klar definiert werden.

Sehe ich auch so, wobei durch die Trennung eine wesentlich schnellere Einführung möglich ist. Wenn der Typ Temperatur erst mal definiert ist, kann das sehr schnell in den entsprechenden Devices eingepflegt werden.

6) Zukunft
nachdem hier die große Lösung gewählt wurde - soll gleich eine Möglichkeit der Einheitenumrechnung implementiert werden, die der User wählen kann?

Jeder Typ kann Umwandlungen für Einheiten bereitstellen.

Ich würde aus meiner Erfahrung heraus eine Trennung von Daten und Metadaten empfehlen. Somit kommt man auf eine MVC Architektur http://de.wikipedia.org/wiki/Model_View_Controller. Das hat sich bisher immer bewährt.

[betateilchen]

Der API Ansatz ist doch eigentlich das, was in der 2010er Diskussion bereits als mögliches Ergebnis rauskam.

[Dr. Boris Neubert]

Hallo,

ich stimme Papas Ausführungen voll zu. Sie entsprechen so auch meinen Vorstellungen.

Der API Ansatz ist doch eigentlich das, was in der 2010er Diskussion bereits als mögliches Ergebnis rauskam.

Gut, daß wir auch mit überwiegend neuer Besatzung an Entwicklern wieder überwiegend zu denselben Erkenntnissen gelangen, wie damals.

Für mich ist der einzige erkennbare Unterschied bisher, daß nun die Zuordnung zum Interface nicht mehr am Gerätetyp hängt sondern auf Ebene der Readings eine Typ-Zuweisung erfolgt.

Der zugewiesene Typ und alle damit zusammenhängenden Vereinbarungen stehen in einer Dokumentation.

Das Frontend entscheidet, was es damit macht.

Wir hatten damals auch Mehrfachvererbung: Ist-Temperatur ist Temperatur, Soll-Temperatur ist Temperatur, Dimmer ist Schalter und Einsteller 0%-100%, Ventil ist Einsteller, etc.

Sind wir auf dem richtigen Weg?

Viele Grüße
Boris

[martinp876]

Was aber nicht immer richtig ist, weil bei FS20 z.B. DIM100% und ON zwei verschiedene Zustände sind.

eben.
Die Anmerkung ist, dass sich das Reading von einem Prozentwert zu einem Literal ändern KANN, nicht muss.  Ich habe auch nicht gesagt, wie zu verfahren ist, sondern gefragt, wie verfahren werden soll.
Man könnte
- strikt bei Prozenten bleiben
- einen Datentyp einführen, der 0% nach off mapt usw...

ich kann bisher nicht erkennen, dass hier irgendeine Entscheidung gefallen ist / getroffen wurde.

Ich dachte die Abstimmung ist eine Entscheidung - nicht?

Wir hatten damals auch Mehrfachvererbung: Ist-Temperatur ist Temperatur, Soll-Temperatur ist Temperatur, Dimmer ist Schalter und Einsteller 0%-100%, Ventil ist Einsteller, etc.
Sind wir auf dem richtigen Weg?

nun - so würde ich es nicht machen - oder ich verstehe nicht, was du meinst. Ich sehe eine Mehrfachnutzung - eine Vererbung ist es doch wohl nicht - oder sollen dann alles eigenen Typen werden - temperatur -sub datentypen nach model und Nutzung geklont?

Ein Datentyp ist Temperatur - mit Unit, Kommentar, Darstellung (float, eine Kommastelle)... Den kann man für Soll und ist temp nutzen. Und etliche weitere Temperatuen, Differenzen,... die es so gibt. warum soll es einen Sub-Typ 'solltemp' geben?
Ein Datentyp 'level' wäre hilfreich, mit range 0-100%. Das wird - zumindest in HM häufig genutzt. Das kann dann von Ventil, dimmer, Blind genutzt werden. Auch hier muss kein separater Datentyp für Modelle gebaut werden.

Kommentare sollten am Reading hängen, nicht an Typ. Sonst kann man nur pauschale Kommantare schreiben... Keine Wertebereiche, keine wirklichen Hinweise.

Gruss
Martin

[Dr. Boris Neubert]

Ein Datentyp ist Temperatur - mit Unit, Kommentar, Darstellung (float, eine Kommastelle)... Den kann man für Soll und ist temp nutzen. Und etliche weitere Temperatuen, Differenzen,... die es so gibt. warum soll es einen Sub-Typ 'solltemp' geben?

Beispiel für Vererbung und wo sie sinnvoll sein könnte:

Fließkommawert -> Temperatur -> Soll-Temperatur

Alles, was eine Fließkommazahl ist, kann mit einer vom Benutzer bestimmten Stellenanzahl für die Anzeige dargestellt werden.
Alles, was eine Temperatur ist, kann in °C, °F, K dargestellt werden.
Alles, was eine Soll-Temperatur ist, wird vom XYZ-Frontend als ein Drehknopf mit Eingabefeld dargestellt und läßt die Eingabe einer Fließkommazahl zu.

Fließkommawert -> Strecke -> Füllhöhe

Das XYZ-Frontend kennt zwar Füllhöhe nicht, aber Strecke, und kann daher immerhin die Anzeige in Form einer Fließkommazahl mit einer Längenangabe darstellen. In einer künftigen Version wird dann ein Pegelstand gemalt.


Wir lernen daraus außerdem, daß Einstellungen für die Darstellung pro Ausgabe (Instanz) des Geräts und Reading und nicht nur pro Typ oder pro Geräteklasse (Modul) und Reading gespeichert werden müssen, da selbst unterschiedliche Instanzen derselben Geräteklasse unterschiedlich verwendet werden können. Ein mächtiges Frontend könnte die Darstellung sogar auf diesen unterschiedlichen Ebenen einstellbar machen (Konfigurationswasserfall).

Wird die Idee klar?

Viele Grüße
Boris

[betateilchen]

Ich dachte die Abstimmung ist eine Entscheidung - nicht?

Nö.

[martinp876]

Nö.

hm - na dann - warten wir ab.

Alles, was eine Soll-Temperatur ist, wird vom XYZ-Frontend als ein Drehknopf mit Eingabefeld dargestellt und läßt die Eingabe einer Fließkommazahl zu.

Das eine abgeleitete Klasse ist, weiss ich schon. Daher ja meine Anmerkung - offensichtlich doch ernst gemeint.
Wenn das so weit runter geht ist das sehr fein granular. Da, befürchte ich, wird es große Mengen von Datentypen geben müssen.
Wenn du dir ein Stellrad zur Solltemp vorstellst... soll es dann nur eine Grafik sein oder ein "slider" ähnliches Produkt? Dann braucht es noch die Min/Max Werte. Und die Schrittweite. Soll das alles in den Typ rein? Oder dann doch in das Reading als Zusatzvariable?

Ein mächtiges Frontend könnte die Darstellung sogar auf diesen unterschiedlichen Ebenen einstellbar machen (Konfigurationswasserfall).

na hoffentlich reicht die Performance der mini-plattformen noch, diesen Wasserfall zu füttern. Man kann schon tolle Sachen machen.

Bedenke, dass Geräteklassen nicht standardisiert sind
Gruss Martin

[papa]

Wenn du dir ein Stellrad zur Solltemp vorstellst... soll es dann nur eine Grafik sein oder ein "slider" ähnliches Produkt? Dann braucht es noch die Min/Max Werte. Und die Schrittweite. Soll das alles in den Typ rein? Oder dann doch in das Reading als Zusatzvariable?

Wenn die Trennung konsequent durchgezogen werden soll, ist hierfür ein extra Typ zu definieren, der nur diese Werte anpasst und den Rest erbt.

Bezüglich der Verebung würde ich auf jeden Fall auf Mehrfachvererbung verzichten - sprich es gibt genau einen Basistyp. Der kann aber natürlich auch schon abgeleitet sein.

na hoffentlich reicht die Performance der mini-plattformen noch, diesen Wasserfall zu füttern. Man kann schon tolle Sachen machen.

Also der tolle Knopf wird doch eher per Javascript implementiert sein. Dann muss der Klient die Rechenleistung zur Verfügung stellen. Der FHEM-Server braucht nur die Typen als JSON-Objekte liefern können.

[martinp876]

Wenn die Trennung konsequent durchgezogen werden soll, ist hierfür ein extra Typ zu definieren, der nur diese Werte anpasst und den Rest erbt.

klar - deswegen habe ich es erwähnt. Die Frage war: Soll es so durchgezogen werden? Soll es so viele Typen geben?

Wo sollen die Typen definiert werden? Wenn es sie 'nur' Zentral definiert werden muss jeder neue Typ 'beantragt' werden - und das schon, wenn man einen neuen Wertebereich hat.
Man könnte(müsste) die Definition der Typen daher dem Modul überlassen.
Einheitlicher wird es bei einer Zentrale Lösung, schon klar... soll FHEM so zentral verwaltet werden?

Der eine Teil ist die Darstellung - wie ich hier höre soll für jeden Typ eine "Display-spec"  bereitgestellt werden.
Zusätzlich sind die Methoden zum Reading-lesen bereitzustellen - damit auch dort der Dezimalpunkt korrekt geliefert wird. Aus dem ReadingVal ist er ja gerade verschwunden - das wird nicht 'vorformatiert'.

Gruss Martin

[martinp876]

was mir in der Diskussion auch aufgefallen ist: dass von Stellrädern geredet wurde. So ich dies korrekt interpretieren geht es um Eingaben von Parametern in irgend einer Form. Bisher haben wir von Readings, deren Darstellung und Auswertung geredet. Aktuell das Liefern der notwendigen Infos, damit die Funktionen die Daten zur Darstellung aufbereiten können.

Die Daten-eingabe ist eine komplett andere Baustelle und der nächste Level. Das zu realisieren Bedarf der Festlegung einer Methode (set-funktion/kommado oder ähnlich) und mehr. Auch die Verlinkung von Readings untereinander oder zu Eingabeparametern muss geklärt werden. Einfach Namensgleichheit? So ist es wohl jetzt (leider ohne Doku).

In HM nutze ich seit geraumer Zeit eine Typdefinition erfolgreich - zur Darstellung, Formatierung, mir Units/Literals/Selectlisten, min/max werten,....Eingabe-check,... . Auch device-spezifikation ist durch eine weitere typeSpec realisiert. Alles natürlich customized für die HM Bedürfnisse.
Kann auch von Usern erweitert werden (propriatär) wenn diese eigenen FW schreiben und nutzen.
Im Prinzip wohl das, das hier besprochen wurde.
Das ganze ist sauber, da die HM devices einer Nomenklatur folgen und ich darauf aufpasse, dass die Regeln eingehalten werden. Bei der Freigabe für User in allgemeiner Form hätte ich Bauchschmerzen - aber mit den Usern, die HM-type-FW schreiben komme ich hervorragend  und erfolgreich zurecht.
Das ist ein wichtiger Unterschied zu dieser Diskussion.

Gruss Martin

[Dr. Boris Neubert]

Die Daten-eingabe ist eine komplett andere Baustelle und der nächste Level. Das zu realisieren Bedarf der Festlegung einer Methode (set-funktion/kommado oder ähnlich) und mehr. Auch die Verlinkung von Readings untereinander oder zu Eingabeparametern muss geklärt werden. Einfach Namensgleichheit? So ist es wohl jetzt (leider ohne Doku).

Du hast recht. Ich habe set mit einem Reading verwechselt, das geSETzt wird. Diese Aufgabe würde ich auch erstmal zurückstellen...

Viele Grüße
Boris

[papa]

Wo sollen die Typen definiert werden? Wenn es sie 'nur' Zentral definiert werden muss jeder neue Typ 'beantragt' werden - und das schon, wenn man einen neuen Wertebereich hat.
Man könnte(müsste) die Definition der Typen daher dem Modul überlassen.
Einheitlicher wird es bei einer Zentrale Lösung, schon klar... soll FHEM so zentral verwaltet werden?
artin

Ich würde hier einen Mischweg vorschlagen. Es werden erstmal eine Reihe von Basistypen (String,Int,Float,Temperature,Distance, .... ) zentral definiert. Module können eigene Typen anmelden. Diese Typen werden dann immer um den Modulnamen als Namespace erweitert (z.B. OWTHERM:Temperature). Damit sollten Kollisionen weitgehend ausgeschlossen sein und die Module haben die nötige Flexibilität.

[martinp876]

Das Prinzip ist soweit klar. Die Realisierung sollte nicht kompliziert werden - macht einer von euch einen Vorschlag mit
- Attributen
- Methoden (oder Wege) zur Definition
- Methoden zur 'Ausgabe' /Abfrage

Aus etlichen Gründen (upgrade,...) gehe ich davon aus, dass
- jedes Reading einen Typ erhält. Default ist string - also wenn der Entwickler keines setzt
- das Setzen des Typs durch eine Methode geschieht - Readings sollten so gut wie nie ohne Methode geändert werden (aktuell geht alles ausser Löschen)
- das Festlegen eines Typs auch mit einer Methode geschieht - somit hat die Zentrale Möglichkeiten der Steuerung und Prüfung

Ein Interessanter Typ ist auch Literal, neben string. Also eine Liste von fixen werten, die ein Reading haben kann. Zur Anzeige ist es ein String - aber man kann es nutzen um
- mögliche Zustände anzuzeigen - quais als help - was könnte den drin stehen....
- später einmal zum Setzen als options-liste.

Bitte nicht vergessen dass einer der Punkte war, eine Methode zur Daten-Formatierung zu erstellen - insbesondere ein Float als "string' mit fix n Nachkommastellen. So in der Art - betateilchen kann sicher am besten beschreiben, was er erwartet.

In jeden Fall sollte eine Methode zur Ausgabe als String und eine zur Ausgabe als Number zu Verfügung stehen. Number damit die User sich darauf verlassen können, dass sie mit dem Wert rechnen können...

Gruss Martin

[Dr. Boris Neubert]

Hallo,

ich stimme allem zu, was Martin um 20:06 schrieb.

Module können eigene Typen anmelden. Diese Typen werden dann immer um den Modulnamen als Namespace erweitert (z.B. OWTHERM:Temperature). Damit sollten Kollisionen weitgehend ausgeschlossen sein und die Module haben die nötige Flexibilität.

Die Typen beruhen ja auf einer Konvention. Nur wenn diese dem Frontend bekannt ist, kann dieses auch angemessen darauf reagieren. Wenn ein Modul also einen eigenen Typ anmeldet, muß es auch alle damit verbundenen Eigenschaften anmelden.

Würde es daher nicht genügen, die Typen in einer zentralen Typdefinitionsdatei (z.B. Plain Text, JSON, oder aufwendiger und für kleine Systeme wegen der erforderlichen Module vielleicht nicht nutzbar, XML) zu hinterlegen, und jeder Entwickler fügt dann Typen an diese Datei an, wenn er neue braucht? Es gibt dann gängige Typen, die wir in einem Abstimmungsprozeß hier im Forum initial ermitteln und bei Bedarf erweitern, und freidefinierte Typen, die in den Namespaces der Module (ist das richtig? Oder lieber die SF-ID des Autors?) leben.

Wie sähen Typdefinitionen aus, in Pseudokode, um Euch eine Vorstellung von meiner Idee zu geben?

Code Auswählen Erweitern


{
Name: string
Format: %s
Encoding: UTF8; # braucht man das, oder ist UTF8 verbindlich?
Description: The plain string type.
}

{
Name: default
Parent: string
Description: The default type if no type is specified for a reading.
}

{
Name: switch # für diese Klasse zeichnet z.B. das XYZ-Frontend ein Glühbirne und das ABC-Frontend einen Schalter
Parent: string
Values: on, off
Description: A type for a binary state.
}

{
Name: float
Format: %f
Description: A floating point value.
}

{
Name: temperatureCustom  # für diese und alle abgeleiteten Klassen zeichnet das XYZ-Frontend ein Thermometer-Widget
Parent: float
Format: %2.3f   # sofern abgeleitete Typen nichts anderes spezifizieren, ist das die Standarddarstellung
Description: The parent type for all temperature types.
}

{
Name: temperatureCelsius
Parent: temperatureCustom
Units:
{ Symbol: °C }  # keine Formel, der Wert wird mit dem Format des Elterntyps formatiert und dann wird Space und Symbol angefügt.
{ Symbol: °F; Formula: $_*1,8+32  }
{ Symbol: K; Formula: $_+273,15 }
Description: A temperature that is measured in centigrades.
}


Wir hätten dann z.B. für FHT80b: $hash->{READINGS}{desired-temperature}{TYPE}= "temperatureCelsius"

Ist das ein gangbarer Weg? Wollen wir uns mal auf eine Beschreibungsform einigen?

Viele Grüße
Boris