Readings, values und Units

[betateilchen]

schon klar, dass das ins Frontend gehört. Aber das Backend muss den Wert entsprechend normalisieren.

[martinp876]

1) ja, wir sollten erst die Anforderungen (Semantik) klaeren - stimme ich zu (hatte es anders formuliert
2) das du 3 Tage verreist bist macht m.E. nichts. Eine solche festlegung ist weittragend und sollte mindestens eine Woche sacken. Die Diskussion sollte weiter gehen. Implementieren sollte man bis dahin nichts.
3) betateilchens Vorschlag ist nicht komplett - wenn ich mich entsinne hatte PAH auch noch eine formel hinterlegen wollen....

So zum Inhalt und meiner Sichtweise:
der Vorschlag ein Reading zu einem kompletten Element zu machen, mit Typ, Unit, ist nicht schlecht. Was bedeute dies für das handling:
a) Sehr viele Readings sind nicht Werte sonder text und liternals - man koennte einen entsprechenden Typ festlegen
b) Welche Icons und Darstellungen hier abgeleitet werden sollen ist mir nicht klar. Koennte wir das konkretisieren? Wenn ein schalter 100% anzeigt soll was eingeblendet werden? Ist es den eine Lampe oder eine Waschmaschine? Brauchen wir also noch einen UserTyp? Was wird bei 10% angezeigt - on oder off? Das Register OnLevel hat eine identische Einheit wir später das Licht. Soll hier immer eine Lampe brennen?
Wie viele Readings gibt es, bei denen man ein Icon oder Symbol hinter legen will/soll/muss? Sollte man wirklich alle Readings nach diesen (wie ich Vermute) Ausnahmen auslegen - oder macht man es bei diesen anders? STATE ist eh kein wirkliches Reading!!
=> Ich höre was ihr sagt - bin nicht sicher das wir vom gleichen Sprechen.
c) Readings sind für mich eine wichtige Gruppe Daten. Es ist der einzige Raum in dem ich device Einstellungen unterbringen kann - zumindest halbwegs sinnvoll. Es muss weiterhin möglich sein, hier Readings schnell und einfach einzutragen, zu aendern und zu löschen.
d) Es gibt Readings (heating) bei denen der unterste wert 'off', der oberste 'on' heisst und zwischenwerte sind temperaturen. Muss dies in einen generellen Ansatz passen oder bauen wir es so komplex das hier kein Platz mehr bleibt? (mir ist klar, was  der Informatiker sagen wird... aber was sagt der User?)
e) Readings ist ein prima element in dem der User daten bunkern kann - muss so bleiben!
f) Readings triggern notifies (manchmal, Rudi )wird dies nur den value betreffen? Darf sich die Einheit aendern? km nach mile.... whatever
g) es wurde angemeckert, dass ein ReadingNum zu viel Performance kosten wird. Der Komplette Ansatz wird m.E. teurer - all inclusive. Wenn jedes Display erst den Wert berechnen muss.

Folgende dinge muss das Konzept befriedigend beantworten können
- performance
- speicherbedarf
- einfacher Umgang - setzen-schreiben
- Erweiterbarkeit
- kompatibilitaet zum status quo

Gruss Martin

[Dr. Boris Neubert]

Ich habe noch eine Anregung: wir sollten die hier zwischenzeitlich gewonnenen Ergebnisse und Ideensammlungen dokumentieren, damit wir diese in diesem schnell wachsenden Thread nicht verlieren. Damals(R) hatten wir das so gemacht, daß wir die Seite "DevelopmentGuidelines" im Wiki laufend angepaßt haben.

Abgestimmt hatten wir damals(R) nach heftigen Diskursen, sobald keine neuen Argumente mehr kamen. Wobei wir auch die Formulierung des Abstimmungsgegenstand peinlich genau diskutiert hatten.

Ich würde auch fleißig dokumentieren. Sofern ich noch nachkomme. Würde mich selbstverständlich über alle freuen, die mitmachen.

Viele Grüße
Boris

[betateilchen]

Jetzt wird die ganze Diskussion m.E. schon so sehr institutionalisiert, dass es vermutlich wieder im Sande verlaufen wird muss.

[Dr. Boris Neubert]

Wie wichtig ist es denn für Dich, nach Deinem Urlaub noch zu wissen, was wir schon erreicht haben, und wo die Knackpunkte liegen?

Viele Grüße
Boris

[betateilchen]

Wenn ich nachlese, was in den DevelopmentGuidelines und in alten Newsgroup-Diskussionen schon alles lange dokumentiert steht, an das sich trotzdem nicht gehalten wird, frage mich mich, welchen Sinn Du Dir von der dazu nötigen Arbeit versprichst? Da lese ich nach meinem Urlaub lieber hier 10 Seiten nach, muss dafür aber nur an einer Stelle lesen, habe die "Originalinforamtion" und muss nicht nachschauen, was von der ganzen Dokumentation letztendlich gefiltert im Wiki angekommen sein mag und was nicht.

[martinp876]

Ich denke die Zeit muss sein - ein Ergebniss muss dann trotzdem her. Wenn es eine saubere Dokumentation gibt muss man die Entwickler auch da hin stossen. Dafuer muss das Verfahren aber Luft zum Atmen lassen.

ich trage einmal zusammen wie ich Readings sehe - primaer HM sicht, klar.
in Readings werden daten unterscheidlicher Typen verwaltet.
A) Messwerte
temp,hum,...
B) Zustaende
an/aus/5%/moving...
C) Infos, entity data
seriennummen/devicetypen
D) ereignisse
button pressed, motion
E) FHEM-externe Konfigurationsdaten
register und peers fuer HM
F) user readings
on the fly angelegt vom User zur Konvertierung und fuer Zwischenergebnisse

Was ist in den Gruppen zu beachten
A) Messwerte
- haben fast immer eine Unit
- kommen haeufig/regelmaessig
B) Zustaende
- koennen eine Unit haben, sind auch gerne liternals
- wechseln mit unter von "5%" nach "on" - also einmal Unit, einmal nicht
C) Infos, entity data
habe ich keine mit infos, koennte welche geben. Koennte auch die Anzahl der Channels eines Device (nichT FHEM sondern HM device) enthalten u.ae.
Wichtige daten, mit unter schwer zu beschaffen.
D) Ereignisse
haben eher keine Units. Evtl Zaehler u.ae.
E) FHEM-externe Konfigurationsdaten
einige mit Units

Somit schliesse ich, dass Units nur ein einem geringen Teil der Readings ueberhaupt auftauchen. Auch kann man nur mit einem Bruchteil der Daten wirklich rechnen. Aus meiner Sicht sind die masse Literals und sonstige Infos.

Was zeichnet Readings aus:
- loesen trigger aus
- werden ueber reboot gerettet (meist...)
- koennen schnell und ohne Vereinbarung angelegt werden
- haben einen Zeitstempel

Was ist wuenschenswert
a) einfach zum rechnen nutzen zu koennen
- Methode zum extrahieren einer Zahl, so vorhanden
b) gut und einfach lesbar
- Einheiten
- Kurzbeschreibung, optionen einblenden
c) automatischen ableiten von icons und Darstellungen
kann ich nichts dazu sagen - evtl kann Boris es erklaeren
d) beibehalten der aktuellen Funktionalitaet
- keine definition vor der Nutzung notwendig
- Rettungsversuch ueber reboot hinweg

Wenn wir also den grossen Aufwasch machen sollten auch kommentate/beschreibungen moeglich sein. Bei den Registern, aber auch bei Messwerten koennten man eine Kurzbeschreibung einblenden, wenn man ueber das Reading faehrt.

Gruss Martin

[betateilchen]

das Abstimmungsergebnis ist irgendwie überzeugend 

Und wo wir schon beim Thema "Darstellung von Readings" sind, hätte ich gleich noch eine Anmerkung/den Wunsch, eine Vorgabe zu schaffen, wie mit Dezimalwerten umzugehen ist.

Derzeit stehe ich regelmäßig (allerdings immer nur bei Homematic-Readings) vor dem Problem, dass ein Reading "3.4" zwar mit einer Nachkommastelle geliefert wird, bei "3" aber das .0 dahinter fehlt. Hier wünsche ich mir eine Vereinheitlichung der Darstellung, gerade in der Weiterverwendung solcher Readings in grafischen Anwendungen (z.B. Ausrichten von Readings untereinander anhand des Dezimalpunktes) ohne jedes Reading vor seiner Verwendbarkeit erst regexen und dann mit sprintf umschreiben zu müssen.

[martinp876]

Die Diskussion ist ins stocken geraten - oder vergessen worden?

wenn der von der Mehrheit gewünschte große Auftrieb eingebaut werden soll gehe ich davon aus, dass die Zentrale sich um die Formatierung kümmert, also ggf. Gleitkommazahl darstellt, Einheiten anzeigt,.... . Ansonsten macht es keinen Sinn für mich, erst alle Attribute festzulegen und dann doch alles im Modul zu machen.
Dann ist es einheitlich und sogar RSS feeds können bedient werden.

[Dr. Boris Neubert]

das Abstimmungsergebnis ist irgendwie überzeugend 

Mich überzeugt es nicht, weil die Umfrage nicht sauber definiert war.

Ich kann allenfalls ablesen, daß die Kombination von Wert und Einheit nicht gewünscht wird und die allermeisten gerne die Möglichkeit hätten, die Einheit anzeigen zu lassen.

Viele Grüße
Boris

[Dr. Boris Neubert]

wenn der von der Mehrheit gewünschte große Auftrieb eingebaut werden soll gehe ich davon aus, dass die Zentrale sich um die Formatierung kümmert, also ggf. Gleitkommazahl darstellt, Einheiten anzeigt,.... . Ansonsten macht es keinen Sinn für mich, erst alle Attribute festzulegen und dann doch alles im Modul zu machen.
Dann ist es einheitlich und sogar RSS feeds können bedient werden.

Um die Formatierung sollte sich aus meiner SIcht die Zentrale kümmern. Der Anwender bestimmt, daß Temperaturen mit 3 Nachkommastellen angezeigt werden und dann wird dies so angezeigt, ohne daß sich jedes Modul gesondert um die Formatierung kümmern muß.

Übrigens ein schönes Beispiel dafür, daß Einheit alleine nicht hilft. Semantik war das Zauberwort.

Viele Grüße
Boris

[Dr. Boris Neubert]

Die Diskussion ist ins stocken geraten - oder vergessen worden?

Um die Diskussion voranzubringen:

Der 2010er-Vorschlag mit den Interfaces beruhte darauf, daß sich aus der Meßgröße die Bezeichnung des Readings ergibt und umgekehrt. Dann müssen alle Temperaturen "temperature" heißen.

Eine abgeschwächte Variante wäre, die Meßgröße (und nicht die Einheit) am Reading zu explizieren. Man braucht dann eine Liste nebenher, die alle Meßgrößen auflistet mit Angabe ob numerisch (bei Temperaturen), Auflistung (bei on/off), usw.

Diese Liste wäre, wie hier schon festgestellt wurde, ggf. eine sehr lange, mit ebensovielen Einträgen, wie es Meßgrößen gibt (Wegstrecke, Füllhöhe, Ist-Temperatur, Soll-Temperatur, Differenz-Temperatur, Umdrehungen pro Sekunden, auf/zu, gedimmt auf x%, ...).

Im GUI könnte es dann eine Seite geben, wo der Benutzer zu jeder Meßgröße die Darstellung, die Einheit und ggf. eine Umrechnung (von °C nach °F oder von K nach °C) wählt.

Meinungen?

Viele Grüße
Boris

[betateilchen]

Ich kann allenfalls ablesen, daß die Kombination von Wert und Einheit nicht gewünscht wird und die allermeisten gerne die Möglichkeit hätten, die Einheit anzeigen zu lassen.

Alleine schon diese Grund-Erkenntnis war m.E. die Umfrage wert.

[Dr. Boris Neubert]

Alleine schon diese Grund-Erkenntnis war m.E. die Umfrage wert.

Zustimmung.

Viele Grüße
Boris

[martinp876]

Alleine schon diese Grund-Erkenntnis war m.E. die Umfrage wert.

hm - Einheiten quasi in allen Human-Readable Frontends schon seit Ewigkeiten genutzt werden ist es für mich nicht überraschend - die eigentliche Frage ist/war nur die Implementierung (passend zur Semantik ). Und die ist immer noch nicht klar.

Mich überzeugt es nicht, weil die Umfrage nicht sauber definiert war.

Absolut.
Die Abstimmung war bereits vor der Diskussion erledigt.

Um die Formatierung sollte sich aus meiner Sicht die Zentrale kümmern.

auch Zustimmung. Architektonisch trifft es mein ursprüngliches Ansinnen.

Ich nehme mit
1) die Entscheidung ist gefallen readings von einem wert mit Zeitstempel zu einem Objekt aufzublasen. Next: Definition der Attribute des Objekts:
Ich hätte dann gerne
- Typ (temperatur, Feuchte, text, Entfernung,...)
- Einheit (m,s,h,....)
- Format (integer, float, exponent, literal, ...)
- Kommentar (Beschreibung für den User - im Frontend darzustellen)
- Wertebereich (Min/Max)
- Auflösung (Schritte von 0.5, 3 Nachkommastellen,....)

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.

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)

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.

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.

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?

Gruss Martin