FHEM Forum

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

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.

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

Hallo Martin,

siehe bitte http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Readings_2 (http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Readings_2) und http://www.fhemwiki.de/wiki/DevelopmentInterfaces (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

Zitat von: Dr. Boris Neubert am 10 März 2014, 10:16:06
Leider wurden die Interfaces nie realisiert.

Schade eigentlich.

@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.

ZitatReadings 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.

ZitatEinheit 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

Zitat von: martinp876 am 10 März 2014, 13:56:57fahrenheit haben wir sicher nicht (oder?)

aber Kelvin...

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

Kelvin gibt es nicht nur bei Homematic.

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.

Zitat von: justme1968 am 10 März 2014, 15:46:15
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.

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

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.

Zitat von: betateilchen am 10 März 2014, 19:12:45
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

Zitat von: Dr. Boris Neubert am 10 März 2014, 19:23:49DbLog 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 :P

Zitat von: betateilchen am 10 März 2014, 15:57:05neben 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

Hallo,

bin immer noch uneingeschränkt dagegen, siehe bitte http://forum.fhem.de/index.php/topic,6993.0.html (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

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

Zitat von: Dr. Boris Neubert am 11 März 2014, 06:23:31
bin immer noch uneingeschränkt dagegen, siehe bitte http://forum.fhem.de/index.php/topic,6993.0.html (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.

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.

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.

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.

Zitat von: martinp876 am 11 März 2014, 07:34:52
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

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

Zitat von: rudolfkoenig am 11 März 2014, 08:39:12
- 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.

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)

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.

Ich bin fuer 2.

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.

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

Ich bin gerne bereit entsprechenden Aufwand zu leisten.

Ich bin auch für 1).

1) ist auf jeden fall am saubersten.

ZitatIch bin gerne bereit entsprechenden Aufwand zu leisten.

Fuer _ALLE_ Module, getestet mit allen unterstuetzten Geraeten und Frontends, automatisches Upgrade aller Altdaten (FileLog,DbLog, notify, usw) + Doku & Wiki-Anpassung? Du haettest sofort meine Zusage, wenn ich nicht wuesste, dass das illusorisch ist.

Ein weiteres Problem von 1), dass Modulautoren sich ploetzlich gezwungen fuehlen fuer Readings wie Betriebsart, Sprache, UhrZeit & co ein UNIT zu vergeben, was zu laecherlichen Darstellungen fuehrt.

Hallo,

bitte KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.

Brauchen wir noch Diskussion dazu? Sollen wir darüber abstimmen?

Nun zu den Einheiten:

Ich habe dazu einen neuen Vorschlag: keine Angabe der Einheit sondern der physikalischen Größe (mit impliziter Definition der Einheit, in welcher das Backend den Wert bereitstellt). Dann haben die Frontends nämlich eine Idee, was dargestellt wird und können ein Thermometer malen, wenn eine Temperatur dargestellt wird, und einen Schieberegler, wenn die Helligkeit geregelt wird.

Vorteil: wir können nicht weiter wild drauflos entwickeln sondern müssen uns vorher (wie bei den Interfaces) Gedanken machen und Regeln vereinbaren.

Abwärtskompatibilität: kann ggf. gelöst werden, indem erstmal Readings unter anderem (standardisierten) Namen gedoppelt werden und dann irgendwann einmal die obsoleten Readings gelöscht werden.

Was haltet Ihr von diesen Vorschlägen?

Viele Grüße
Boris

es ist ja nicht verboten readings ohne einheiten zu haben.

wie wäre es pro instanz ein {UNITS} zu haben das pro reading die zugehörige einheit  ein mal hält?

dann gibt es keinen overhead beim reading anlegen.

Zitat von: Dr. Boris Neubert am 11 März 2014, 13:51:04
Sollen wir darüber abstimmen?

Da Vernunft hier im Forum nach meiner Erfahrung selten siegt, wird die angebotene Abstimmung wohl die beste Lösung sein, um eine mehrheitsfähige Lösung zu begründen.

Zitat von: Dr. Boris Neubert am 11 März 2014, 13:51:04
Was haltet Ihr von diesen Vorschlägen?

Man sollte nicht alles noch komplizierter machen, als nötig. Auch wenn ich Dir aus Entwicklersicht durchaus rechtgebe.

Zitat von: justme1968 am 11 März 2014, 13:54:29
wie wäre es pro instanz ein {UNITS} zu haben das pro reading die zugehörige einheit  ein mal hält?

Dagegen. Die Unit bildet zusammen mit dem Value eine Einheit und stammt immer aus dem Device, nicht aus der Instanz.
Die vorgeschlagene Lösung würde vermutlich mehr Verwirrung stiften denn nützen.

physikalische größe reicht nicht bei allen readings als grundlage um im frontend das passende interface element automatisch zu wählen. eine strecke könnte einem rollladen zugeordnet sein oder einem füllstand.

die idee den readings etwas semantik mit zu geben ist aber sehr gut. das würde in den frontends glaube ich sehr helfen.

wenn es nicht zu jedem einzelnen reading gepackt wird gehört es in die instanz und nicht ins device. das gleiche device kann ein mal eben den rollladen bedienen und ein mal eine lampe dimmen.

Zitat von: rudolfkoenig am 11 März 2014, 13:40:08
Fuer _ALLE_ Module, getestet mit allen unterstuetzten Geraeten und Frontends, automatisches Upgrade aller Altdaten (FileLog,DbLog, notify, usw) + Doku & Wiki-Anpassung? Du haettest sofort meine Zusage, wenn ich nicht wuesste, dass das illusorisch ist.

Alle Module ist durchaus illusorisch. Aber die Module / Geräte, die ich selber nutze und wo der Maintainer keine Zeit/Lust hat, würde ich durchaus übernehmen. HomeMatic würde ich hier ausklammern, da das einfach zu kompliziert ist (nichts für Ungut, Martin).

Allerdings erst, wenn ein klares Zielbild vorliegt.

Zitat von: justme1968 am 11 März 2014, 14:13:06
wenn es nicht zu jedem einzelnen reading gepackt wird gehört es in die instanz und nicht ins device. das gleiche device kann ein mal eben den rollladen bedienen und ein mal eine lampe dimmen.

Meinen Andre und Udo dasselbe? Nämlich das benannte Etwas myLamp, myShutter, 1.wz.hzg? (das ist für mich die Instanz, also eine der möglicherweise vielen Exemplare eines Gerätes).

bn

so verstehe ich es auch. device = fhem modul. instanz = mit define angelegtes exemplar.

ok - für mich ist device das, was mit define angelegt wird. Nicht umsonst heißt es ja auch devspec und nicht instspec ;)

Zitat von: Dr. Boris Neubert am 11 März 2014, 14:22:53Meinen Andre und Udo dasselbe?

Die Unit gehört für mich zu jedem in fhem per define angelegten etwas und dessen readings. Genau wie für mich der Timestamp zum Reading gehört.

Zitat von: justme1968 am 11 März 2014, 14:13:06physikalische größe reicht nicht bei allen readings als grundlage um im frontend das passende interface element automatisch zu wählen. eine strecke könnte einem rollladen zugeordnet sein oder einem füllstand.

Einheit und Semantik sind 2 paar Stiefel. Die Auswahl, was ein Wegstreckengeber mit der Einheit 'm' tatsächlich repräsentieren soll, kann letztendlich nur der Benutzer selber treffen. Das über die Einheit universell abzuwickeln macht nur bei auf einen Anwendungsfall spezialisierten Modulen Sinn und wird im allgemeinen Fall scheitern. Im Frontend eine sinnfällige Default-darstellung basierend auf der Einheit anzubieten geht ja trotzdem.

Und die Einheit gehört ( Variante 1) ) - so wie in der Physik - an das konkrete Reading (und sollte optional sein). An der Stelle kann man durch Vermeidung von Redundanz (indem man die Unit irgendwo höher an die Instanz oder das Modul aufhängt) praktisch nichts gewinnen.

Auf diese Weise könnte man die Einheit bei einem Notify auch unkompliziert mitschicken.

Und ja, ich wäre dafür, dass man im Wiki eine Liste der 'gewünschten' Einheiten hinterlegt ohne neue zu verbieten. Meines Erachtens spricht auch erst mal nix dagegen für eine Größe unterschiedliche Einheiten/Skalen (z.B. °C und K) zuzulassen und das Umrechnen in die gewünschte Ziel-einheit (z.B. °F) dem Frontend zu überlassen. Auf diese Weise ist eine graduelle Migration möglich. (Ich erwarte mir hier eh nicht, dass sich da alle gleich drauf stürzen...)

Es ist gerade eine Umfrage gesprossen...

Was muß ich ankreuzen, wenn ich Einheiten will, aber nicht in $hash->{readings}{VAL}?

BN

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" ;)

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!

Zitat von: betateilchen am 11 März 2014, 15:08:06
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?  :o

Viele Grüße
Boris

Zitat von: martinp876 am 11 März 2014, 15:12:48
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).

Zitat
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).

Zitat
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).

Zitat
"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.

Zitat
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

Zitat von: Dr. Boris Neubert am 11 März 2014, 15:22:16Wir vermischen hier Anforderung und Lösung.

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

Zitat von: martinp876 am 11 März 2014, 15:12:48Muss 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.

Zitat von: Dr. Boris Neubert am 11 März 2014, 15:41:41
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.

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

beispielsweise:


{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.

Zitat von: betateilchen am 11 März 2014, 16:35:43
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

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.

Zitat von: betateilchen am 11 März 2014, 17:20:01Eine 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?

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.

Zitat von: betateilchen am 11 März 2014, 18:34:43
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

Zitat von: Dr. Boris Neubert am 11 März 2014, 19:34:49Und 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

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.

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

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

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

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

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

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.

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

das Abstimmungsergebnis ist irgendwie überzeugend  :P

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.

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.

Zitat von: betateilchen am 20 März 2014, 11:48:39
das Abstimmungsergebnis ist irgendwie überzeugend  :P

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

Zitat von: martinp876 am 20 März 2014, 20:09:15
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

Zitat von: martinp876 am 20 März 2014, 20:09:15
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

Zitat von: Dr. Boris Neubert am 20 März 2014, 20:34:00Ich 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.

Zitat von: betateilchen am 20 März 2014, 21:08:11
Alleine schon diese Grund-Erkenntnis war m.E. die Umfrage wert.

Zustimmung.

Viele Grüße
Boris

ZitatAlleine 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.

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

Absolut.
Die Abstimmung war bereits vor der Diskussion erledigt.

ZitatUm 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

Zitat von: martinp876 am 21 März 2014, 07:57:59
Ich nehme mit
1) die Entscheidung ist gefallen

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

Zitat von: martinp876 am 21 März 2014, 07:57:59
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.

Zitat von: martinp876 am 21 März 2014, 07:57:59
nachdem hier die große Lösung gewählt wurde

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

Zitat von: martinp876 am 21 März 2014, 07:57:59
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.

Zitat von: martinp876 am 21 März 2014, 07:57:59
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

Zitat von: martinp876 am 21 März 2014, 07:57:59
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)

Zitat von: martinp876 am 21 März 2014, 07:57:59
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.

Zitat von: martinp876 am 21 März 2014, 07:57:59
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.

Zitat von: martinp876 am 21 März 2014, 07:57:59
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 (http://de.wikipedia.org/wiki/Model_View_Controller). Das hat sich bisher immer bewährt.

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

Hallo,

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

Zitat von: betateilchen am 21 März 2014, 09:35:55
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

ZitatWas 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...

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

Ich dachte die Abstimmung ist eine Entscheidung - nicht?

ZitatWir 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

Zitat von: martinp876 am 21 März 2014, 17:32:46
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

Zitat von: martinp876 am 21 März 2014, 17:32:46
Ich dachte die Abstimmung ist eine Entscheidung - nicht?

Nö.

ZitatNö.

hm - na dann - warten wir ab.

ZitatAlles, 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?

ZitatEin 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

Zitat von: martinp876 am 21 März 2014, 20:49:00
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.

Zitat von: martinp876 am 21 März 2014, 20:49:00
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.

ZitatWenn 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

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

Zitat von: martinp876 am 22 März 2014, 14:47:35Die 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

Zitat von: martinp876 am 21 März 2014, 23:12:21
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.

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

Hallo,

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

Zitat von: papa am 22 März 2014, 19:28:03
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?


{
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

Zitat von: martinp876 am 22 März 2014, 20:06:22
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.

Ich bin dagegen numerische Readings als formatierte Strings (sowas wie 'immer mit Punkt und 2 Nachkommastellen) abzulegen. Das ist Sache des Frontends. Eine leistungsfähige Funktion (sprintf) zum Formatieren nach Wunsch ist in perl ja schon drin.
Wichtig ist, dass numerische Werte so abgelegt sind, dass man unmittelbar mit Ihnen Rechnen kann.

Der Rest von Martins Zusammenfassung ist für mich OK. Literale als Typ mit definierbarer Wertemenge würde ich auch unterstützen, hab aber noch keine (gute) Idee, wie man das effizient am Reading unterbringt. Irgendwie sieht es für mich so aus, als ob man ein Reading erst mit Angabe eines Datentyps definieren können sollte um später nur noch den eigentlichen Wert zu aktualisieren.

- Norbert

Generell sollten unter $hash->{READING} die Rohwerte stehen (also ohne sprintf, round,..), so dass (wie von Norbert angemerkt) man nachwievor mit dem Rohwert selber weiterarbeiten kann.

Ich finde die Formatierungs- und Umrechnungsformeln in den Typendefinitionen super, aber sie sollten nur von Frontendmodulen verwendet werden.

Könnte man die modulspezifischen Typen nicht im Modul in der Initialize-Funktion definieren? Dann hat man alles zusammen und keine weitere separate Datei die von allen gepflegt werden muss?

Wir definieren einmal eine Reihe an Grundtypen und alle modulspezifischen Typen müssen in den Modulen definiert werden mit sämtlichen Umrechnungsmöglichkeiten und Einheiten.

Gruß
Markus

Zitat von: Markus Bloch am 22 März 2014, 21:27:18
Generell sollten unter $hash->{READING} die Rohwerte stehen (also ohne sprintf, round,..), so dass (wie von Norbert angemerkt) man nachwievor mit dem Rohwert selber weiterarbeiten kann.

Ich meine, daß wir darüber schon dieses auch als Konsens erzielt hatten.

Ich hatte Martin auch nicht so verstanden, daß er einen String in READING-VAL schreiben wollte. Lediglich String als Default in der Typdefinition für die Anzeige unterstellen. Wenn es der Anwender besser als das Frontend weiß, darf er natürlich mit den Zahlenwerten rechnen, die dem Frontend mangels Semantik (fehlende oder dem Programmierer des Frontends unbekannte Typdefinition) nur als String erscheinen.

Zitat
Ich finde die Formatierungs- und Umrechnungsformeln in den Typendefinitionen super, aber sie sollten nur von Frontendmodulen verwendet werden.

So habe ich das auch gemeint.

Zitat
Könnte man die modulspezifischen Typen nicht im Modul in der Initialize-Funktion definieren? Dann hat man alles zusammen und keine weitere separate Datei die von allen gepflegt werden muss?

So hätte man genau einen Verantwortlichen für die globalen Typdefinitionen.

Die Frage ist aber, ob die individuellen Typdefinitionen überhaupt zu einem bestimmten Modul gehören? Also wo werden Typen redundanzfrei definiert, die in mehreren Modulen (einer Modulgruppe) benötigt werden.

In welchem Format würde man denn dann die Typdefinitionen abliefern? Es sollte für Mensch und Maschine gleich gut lesbar sein. JSON wäre so ein Format. Oder ein strukturiertes Hash wie in die Orgie von Definitionen am Anfang von 11_OWDevice.pm.

Viele Grüße
Boris

Ich sehe hier folgende Möglichkeiten:


1. eine komplette Datei mit sämtlichen Definitionen als Perl Hash oder NV-Pairs. XML und JSON würde ich nicht verwenden aufgrund zusätzlicher Module bei kleinen System (FritzBox, u. ä.) und der schwierigen Platzierung von Kommentaren (insbesondere bei JSON).

2. Pro Typdefinition eine Datei mit einem Perl Hash oder NV-Pairs. Vorteil ist, wenn eine Datei einen Syntaxfehler hat, sind alle anderen Typendefinitionen nicht davon betroffen.

Desweiteren sollte eine Typendefinition dokumentatorisch einen Hinweis enthalten welche Basiseinheit einer Typendefinition zu Grunde liegt. Also Readings vom Typ temperature müssen in °C bereitgestellt werden. Nur so funktionieren die darüber hinaus definierten Umrechnungsformeln. Genauso auch muss eine Stromstärke in Ampere bereitgestellt werden und nicht Milli-Ampere, usw.

Diesen Dokumentationsteil inkl. den Umrechnungsmöglichkeiten könnte man dann einfach in die commandref integrieren lassen.

Gruß
Markus

Angenommen, eine Typdefinition wäre ein Hash.

Würde man dann am Reading den Namen des Typs oder eine Referenz auf das Hash hinterlegen.

Hashreferenz hat vermutlich den Vorteil, daß man keinen Typen referenzieren kann, den es nicht gibt.

BN

Hashreferenz finde ich super, diese Zuweisung sollten dann die readingsUpdate-Funktionen durchführen in dem sie die entsprechende Referenz der gewünschten Typendefinition zuweisen. Sollte ein Modul eine Typdefinition angeben, die nicht existiert, so sollte eine Art Standardtyp zugewiesen werden, der den Wert ungefiltert und ohne Interpretation an das Frontend weitergibt.

Und alles in einem globalen %types-Hash, das uns dann mit $types{temperatureCelsius} die Referenz auf das Hash mit dem benannten Typ liefert.

Mal sehen, was die anderen dazu sagen.

BN

Zitatund jeder Entwickler fügt dann Typen an diese Datei an,

das ist ein nogo. Wiederspricht allem, was FHEM aktuell tut. Die Modul-spezifischen Typen sollten unbedingt auch dort definiert werden. Gründe gibt es zu hauf - u.a. das Dateien immer einem Entwickler 'gehören'

Zitat
Wie sähen Typdefinitionen aus, in Pseudokode

halte ich für exterm ungeschickt. Perl kann zwar viel, ist aber exterm langsam. Man sollte es deutlich geradliniger machen. Möglich ware, einen Pseudo-code zu nutzen, aber beim Starten zu 'kompilieren'. Am Ende sollte ein Hash existieren, mit klaren Werten, maschienen nutzbar.

ZitatIch bin dagegen numerische Readings als formatierte Strings (sowas wie 'immer mit Punkt und 2 Nachkommastellen) abzulegen

zustimmung. Die idee ist nicht, den Wert formatiert abzulegen sondern eine Methode bereitzustellen, die so etwas leistet. Sonst muss es jeder User selbst machen. Einfach nur ein Service.

ZitatLiterale als Typ mit definierbarer Wertemenge würde ich auch unterstützen, hab aber noch keine (gute) Idee, wie man das effizient am Reading unterbringt.

In CUL_HM nutze ich das bereits - so kann ich register(deviceparameter) User-readable übersetzen. Bein Schreiben und Lesen.

ZitatIch finde die Formatierungs- und Umrechnungsformeln in den Typendefinitionen super, aber sie sollten nur von Frontendmodulen verwendet werden.

Die Idee ist (schon ganz am Anfang in Threat) neben ReadingsVal ein ReadingsNum (liefert einen Numerischen Wert, wenn das Reading numerisch ist oder zumindest so beginnt - stript Units u.ä.) und wenn man will ein ReadingsNumFromated - für Nachkommastellen. Alles nur ein Service, das es nicht jeder, der nicht so firm ist es nicht selbst machen muss.

Ich erwarte eine Typdefinition die maschinenlesbar so aussehen könnte:
%readTypes = (
  time   =>{type=>"float",step=>0.2,min=>0  ,max=>10000,format=>'1.1' ,unit=>'s' ,conv=>''         ,displayLevel=>2, t=>"Ein Zeitwert"       },
  length =>{type=>"int"  ,step=>1.0,min=>0  ,max=>1000 ,format=>''    ,unit=>'m' ,conv=>'myConvFkt',displayLevel=>3, t=>"Länge in Metern"    },
  temp   =>{type=>"float",step=>0.5,min=>-40 ,max=>70  ,format=>'3.1' ,unit=>'C' ,conv=>''         ,displayLevel=>0, t=>"Temperatur Sollwert"},
  text1  =>{type=>"lit"  ,step=>0  ,min=>0  ,max=>0    ,format=>''    ,unit=>''  ,conv=>''         ,displayLevel=>1, t=>"irgend ein text"    ,lit=>{off=>0,jmpToTarget=>1,toggleToCnt=>2,toggleToCntInv=>3}},
......


Befüllen, wie gesagt, kann man auch mit Methoden und somit abstrahiert

Gruss Martin

Zitat von: martinp876 am 23 März 2014, 10:26:37
das ist ein nogo. Wiederspricht allem, was FHEM aktuell tut. Die Modul-spezifischen Typen sollten unbedingt auch dort definiert werden.

Der Punkt, die allgemeingültigen Typen zentral und die individuellen Typen dezentral in der Verantwortung jeweils genau eines Entwicklers (Dateieigentümer) zu halten, ist akzeptiert. Ich habe noch gefragt, wo die individuelle Typen redundanzfrei hinterlegt werden in dem Fall, daß ein Entwickler diese Typen in mehreren seiner Module nutzen möchte.

Zitat
In CUL_HM nutze ich das bereits - so kann ich register(deviceparameter) User-readable übersetzen. Bein Schreiben und Lesen.
Die Idee ist (schon ganz am Anfang in Threat) neben ReadingsVal ein ReadingsNum (liefert einen Numerischen Wert, wenn das Reading numerisch ist oder zumindest so beginnt - stript Units u.ä.) und wenn man will ein ReadingsNumFromated - für Nachkommastellen. Alles nur ein Service, das es nicht jeder, der nicht so firm ist es nicht selbst machen muss.

Schlägst Du ein ReadingsNum vor? Ich verstehe nicht, warum wir ein ReadingsNum brauchen. Die Werte in VAL sind ja numerisch, wenn das Modul eine Zahl (Temperatur, Füllstand, ...) reinschreibt. Immer wenn damit gerechnet wird, tut das entweder der Benutzer (weiß, was er tut) oder das Frontend (liest es aus der Typdefinition).

Zitat
Ich erwarte eine Typdefinition die maschinenlesbar so aussehen könnte:

Code Auswählen Erweitern

%readTypes = (
  time   =>{type=>"float",step=>0.2,min=>0  ,max=>10000,format=>'1.1' ,unit=>'s' ,conv=>''         ,displayLevel=>2, t=>"Ein Zeitwert"       },
  length =>{type=>"int"  ,step=>1.0,min=>0  ,max=>1000 ,format=>''    ,unit=>'m' ,conv=>'myConvFkt',displayLevel=>3, t=>"Länge in Metern"    },
  temp   =>{type=>"float",step=>0.5,min=>-40 ,max=>70  ,format=>'3.1' ,unit=>'C' ,conv=>''         ,displayLevel=>0, t=>"Temperatur Sollwert"},
  text1  =>{type=>"lit"  ,step=>0  ,min=>0  ,max=>0    ,format=>''    ,unit=>''  ,conv=>''         ,displayLevel=>1, t=>"irgend ein text"    ,lit=>{off=>0,jmpToTarget=>1,toggleToCnt=>2,toggleToCntInv=>3}},
......


Ich befürworte auch das Hash. Es ist gleichzeitig maschinen- und menschenlesbar. Über die Form müssen wir uns noch gut Gedanken machen.

Grüße
Boris

Zitat von: martinp876 am 23 März 2014, 10:26:37
Die Modul-spezifischen Typen sollten unbedingt auch dort definiert werden.

Zitat von: Dr. Boris Neubert am 23 März 2014, 10:38:53
Der Punkt, die allgemeingültigen Typen zentral und die individuellen Typen dezentral in der Verantwortung jeweils genau eines Entwicklers (Dateieigentümer) zu halten, ist akzeptiert. Ich habe noch gefragt, wo die individuelle Typen redundanzfrei hinterlegt werden in dem Fall, daß ein Entwickler diese Typen in mehreren seiner Module nutzen möchte.

OffTopic:
ich persönlich bin ja dringend dafür, dass man mal die Doktrin '1 Fhem-modul = 1 Datei' aufgibt und dafür ganz normale perl-module in 'lib' ablegt (lib sollte dann natürlich von fhem.pl schon in @INC aufgenommen werden). Dann kann man seinen modulübergreifenden code wie in perl sonst auch üblich mit einem 'use <modul> qw/zu importierende symbole/' zur Compiletime einbinden und müsste nicht auf 'LoadModule (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/00_OWX.pm#L200) zurückgreifen um dies zur Laufzeit zu tun.

OnTopic:

Zitat von: Dr. Boris Neubert am 22 März 2014, 22:58:29
Und alles in einem globalen %types-Hash, das uns dann mit $types{temperatureCelsius} die Referenz auf das Hash mit dem benannten Typ liefert.

Ein globaler %types-Hash wäre auch nach meinem Geschmack. Da finden sich dann alle 'globalen' Typen wieder, die fhem.pl beim Startup läd. Alle modulspezifischen Typen legt das jeweilige Modul beim Aufruf seiner Initialize-methode darin ab. Setz natürlich vorraus, dass modulspezifische Typen sowas wie einen Namespace a la $types{MY_MODULE_whateverReadingType} verwenden sollten um Namenskonflikte zu vermeiden.

- Norbert

ZitatSchlägst Du ein ReadingsNum vor?

ja

ZitatIch verstehe nicht, warum wir ein ReadingsNum brauchen. Die Werte in VAL sind ja numerisch, wenn das Modul eine Zahl (Temperatur, Füllstand, ...) reinschreibt.

Stand aktuell ist, dass Einheiten drin stehen - oder auch mal Werte ersetzt werden (on/off statt 0/100 habe ich häufig gesehen...)

Andererseits, wenn es korrekt implementiert ist, könnte es sich erübrigen. Einheiten sollte wegfallen. Das mit On/Off mögen einige (z.B. bei dimmern). Natürlich könnten wir ein Mapping einführen  - readingsVal ist dann ein Wert, im Display und in den Events erscheint aber kein On/Off sondern ein 0/100
=> Das sind heikle Fragen, welche die Evolution betreffen. Wenn sich hier etwas ändert werden den Usern einige Notifies um die Ohren fliegen.
Alternativ wäre ein Reading mit "Wertebereich" [on|off|0.5...99.5] auch als text möglich - ein Reading "level" wäre der reine Zahlenwert (so mache ich das Aktuell, würde sich bei HM nichts ändern)

Zitat
Dann kann man seinen modulübergreifenden code wie in perl sonst auch üblich mit einem 'use <modul> qw/zu importierende symbole/' zur Compiletime einbinden und müsste nicht auf 'LoadModule zurückgreifen um dies zur Laufzeit zu tun.

hmmm... geht das nicht? Ich habe meine Definitionen in HMConfig und nutze sie in 10_CUL_HM sowie in 98_HMInfo.  Dazu brauch ich niemanden sonst.

ZitatEin globaler %types-Hash wäre auch nach meinem Geschmack. ...modulspezifische Typen sowas wie einen Namespace a la $types{MY_MODULE_whateverReadingType} verwenden sollten um Namenskonflikte zu vermeiden.

genau.
Aber auch hier (wie immer in guter SW) sollte man nicht einfach "reingreifen" und typen definieren sondern dies mit einer Methode machen. Die Zentrale kann, wenn sie will... prüfen: gibt es Namenskonflikte, sind mindest-felder vorhanden, sind konventionen eingehalten,... was immer man für nötig hält.
Die Readingstypen müssen auch nicht zwingend im Init definiert werden. Ist zwar ein sinnvoller Zeitpunkt, muss aber keine Vorschrift sein. Wenn jemand das später machen will, dynamísch,... sollte es ok sein.
Löschen kann man sie nicht - oder???

Hallo Leute,

aktuell betrachte ich diese Diskussion als
- interessant
- grundlegend
- gescheitert (oder political correct: bis auf weiteres verschoben)

Ein Problem war und ist, dass einige nicht unterscheiden können zwischen backend (scripting und maschinen interface) und frontend (web und human readable interface). Sonst gäbe es keine Diskussion was in {READINGS}{name}{Val} steht und was ReadingsVal() liefert, also Daten und Methoden, sondern welche Methode man braucht, um den User zu unterstützen.
Fakt ist (nicht in zukunft sondern jetzt) dass der User Werte in Scripten verarbeiten will - und das mit numerischen und textuelle Daten. Perl ist hier - wie alle wissen - eine einzige Sauerei. Daher sollte FHEM dem User einfach eine Methode zu Verfügung stellen, die einen String und eine andere die einen numerischen Wert zurück liefert.
Wenn dies mit Methoden gemacht wird ist es kein Problem, später auch auf komplexe Datenstruktur einzuführen - das ist für den User transparent.

Dass es notwendig ist zeigen die Reaktionen der Nutzer (und sogar manche Developer haben hier offensichtlich massive Probleme). Es gibt werte wie "15,7","15,7 %","15,7%","15,7% - limit reached","15,7 C","15,7 Celsius". Die Nutzer kämpfen offensichtlich, hier die 15,7 zu erhalten, dabei ist es ein Kinderspiel. Schon ein blank mehr oder weniger machen Probleme. Es ist ein 3-zeiler, der das Problem KOMPLETT löst (der Vorschlag liegt von mir an mehreren Stellen bereits vor)

Dieser Threat ist begonnen worden um dieses Problem zu lösen.
Es ist eigentlich Irrsinn, dass aus diesem simplen Grund
- das Frontend keine Units darstellen soll/darf/kann (Steinzeit...)
- Developer sich über den Inhalt von {val} unterhalten - der sie von anderen Modulen eigentlich garnichts angeht. Es wird doch hoffentlich über Methoden zugegriffen!  - und hier braucht es nur die Korrekten/Fehlenden.
Aktuell ist das ganze auf einem schlechten Weg!

So, das ist meine Sicht zu diesem Sachverhalt. Ich ziehe mich hier zurück und hoffe, dass eine userfreundliche und praktikable Entscheidung von den Verantwortlichen getroffen wird - es wäre zu einfach.

Gruss Martin

Nicht weinen Martin,

die ReadingsNum() ist doch in der fhem.pl bereits vorhanden. Ich betrachte das als durchaus brauchbare Interims-Lösung (-Hilfe).

hoffentlich nicht interims - das wird hoffentlich auch genutzt werden, wenn es ein egal wie komplexes Objekt "READINGS" gibt.
Und du hast jetzt endlich keine Probleme mehr, wenn Units in Readings gepackt werden. Keine Ahnung, warum du immer noch in Foren darüber referierst und zankst, anstatt den Usern die korrekte Methode nahe zu bringen.
Diese Diskussion hier scheint mir jedenfalls aktuell ziemlich tot.

Zitat von: martinp876 am 28 März 2014, 10:16:43Keine Ahnung, warum du immer noch in Foren darüber referierst und zankst,

Tu ich doch gar nicht mehr?

Und ich betrachte die Diskussion hier im Thread bei weitem nicht als "tot" - aber sie ist auch definitiv noch nicht zu Ende geführt.

Hallo Martin,

Zitat von: martinp876 am 28 März 2014, 06:58:05
- gescheitert (oder political correct: bis auf weiteres verschoben)

wie kommst Du denn darauf?

Wir sind doch schon unglaublich weit gekommen. Und mir scheint, daß diejenigen, die zuletzt noch mitdiskutiert haben, doch schon auf einem Konsens sind, wie es gemacht werden soll (Details noch zu bestimmen).

Mir fehlt derzeit aber noch die breitere Basis an Entwicklern, die dem Vorschlag auch zustimmen sollte. Möglicherweise haben viele zwischendurch den Faden verloren. Hallo, ist da draußen jemand?

Ich denke, daß wir den Lösungskandidaten dokumentieren sollten (bin für eine Seite im Wiki, an der wir gemeinsam herumschrauben) und dann mit einem neuen Thread in die zweite Runde gehen. Die Dokumentation hilft nämlich dem gemeinsamen Verständnis (ich weiß, was ich verstanden habe und will, aber ich weiß nicht, ob Ihr das gleiche verstanden habt und wollt). Sie zeigt zudem, daß die Diskussion nicht tot ist und daß wir weitergekommen sind und was wir von den anderen Entwicklern erwarten.

Viele Grüße
Boris

P.S.: Ich war wieder die ganze Woche im Ausland und bin daher sehr froh, daß ich mich jetzt nicht durch hunderte Beiträge zu diesem Thema wühlen muß.

Hallo Boris,
nun, ich sehe, dass keiner weiter macht, und es sehr wenige interessiert, zumindest arbeitet keiner weiter - egal in welche Richtung.
Unklar ist mir, wer der owner des Readings-Objekts sein wird. Dieser könnte einen Versuch starten. Das Konzept wäre klar, die Realisierung läge bei ihm. Die Parameter sind für das Konzept zweitrangig - das konzept müsste eh hergeben, dass es erweitert werden kann. Wichtig wären die Zugriffsmethode. Die "interne Architektur" geht ist prinzipiell  design Angelegenheit.
Wie du selbst korrekt bemerkst: keine Beteiligung. Das sehe ich als klares votum: kein Interesse. Auch eine Art Abstimmung.
Gruss Martin

I am interested in this subject but google translation is not clever enough to let me understand clearly the options  :(

Ich versteh gerade dein Problem nicht so ganz, Martin.

Wir haben hier in den vergangenen Posts versucht uns klar zu machen, das was geändert werden muss. Das denke ich haben wir auch geschafft.

Es wurde auch klar dargelegt, das man nicht nur fluchs einen Wert {UNIT} im Reading unterbringen sollte, sondern dass das ganze genereller angegangen werden muss (Stichwort: Typendefinitionen).

Dazu wurden noch weitere Sachen genannt wie z.B. Umrechungsformeln (für Frontends).

Desweiteren sind wir übereingekommen, dass solche Typendefinitionen in FHEM separat bereitstehen sollten (z.B als %types) und die Module alle numerischen Readings diesen Typen zuordnen. Daraus folgt für mich, die numerischen Werte bleiben so wie sie sind, ohne Einheit hinten drann und man kann mit ReadingsVal diese Werte für Berechnungen nehmen, was ja auch eine deiner Kernforderungen war (korrigier mich, wenn ich falsch liege).

Das ist allerdings nun nur eine Lösung die innerhalb von einer Hand voll Leuten diskutiert wurde. Alle anderen Entwickler und auch Rudi haben sich dabei noch garnicht eingebracht. Aufgrund dieser elementaren Änderungen muss das aber auf jedenfall geschehen. (Wie es Boris beschrieben hat).

Wo ich dir zustimme ist momentan die Frage nach dem Verantwortlichen für dieses Thema. Da sehe ich momentan auch noch eher Nebel. Ich denke, das sollte man noch durchaus klären.

Aber ich kann dir keinesfalls zustimmen, dass diese Diskussion versandet ist, oder zu keinem Ergebnis gekommen ist.

Zitat von: Markus Bloch am 28 März 2014, 18:04:08
Ich versteh gerade dein Problem nicht so ganz, Martin.

Dann sind wir mindestens schon zwei, die das nicht verstehen.

drei... 

genau so wie du es zusammengefast hast hatte ich es auch verstanden.

vier ....

Ich habe mich nur zurück gehalten, weil ich nicht sehr FHEM-Entwicklungsprozess-erfahren bin und mir nicht klar ist, wie hier solche grundlegenden Änderungen angegangen werden. Meine Perl-Kenntnisse halten sich auch eher in Grenzen. Da kann ich weniger konkrete Vorschläge machen. Aber für Architektur-Fragen und sowas gebe ich gern meine Erfahrungen weiter.

BTW: Sollte man sich vielleicht auch gleich mal über eine Testsuite Gedanken machen, welche die Modulentwickler nutzen könnten, um Ihre Implementierungen gegen die API testen zu können ?

dazu muss man erstmal wissen, wie die API aussieht  :P

Fünf :)
Ich verfolge die Diskussion mit Interesse und finde, sie geht durchaus in die richtige Richtung.
Ich bin selbst noch nicht so tief in der Materie drin, daher nehme erstmal eine passive Rolle ein. Vorläufig ;)

nun, melden sich doch welche. Schon ein Erfolg...

Wo sind aber die Antworten
- wer wird den Implementierung des Objekts realisieren?

Zitatdazu muss man erstmal wissen, wie die API aussieht

- wo sind die Vorschläge?

Wenn es kein passendes API gibt funktioniert es nicht - egal wie die Semantik der Objekte sein könnte.

Aktuell sehe ich nur eine einzige Idee, dass es quasi ein Objekt wird. Noch kein Beschluss.  Alles andere sind mehr  neblige Ideen, welche Attribute das Objekt haben könnte. Das API ist noch viel weiter im Nebel.

Interessiert scheinen einige zu sein - schön. Das habe ich auch. Muss man unbedingt haben, an solche einer Zentralen Stelle.  Aber es wird ein Macher gebraucht. So lange dieser nicht benannt ist und  agiert steht das hier. Auch nach den letzten Wortmeldungen sehe ich nur Stillstand.

Gruss
Martin

mit deiner Drängelei wirst Du auch keine schnelle Lösung erzwingen, ganz im Gegenteil...

Hallo Martin,

ich empfinde das auch als Drängelei.

Du suchst jemanden, der das in die Hand nimmt. Das kann ich tun. Das bedeutet, daß ich recht viel Arbeit in diese Sache investieren werde, die ich nur über einen längeren Zeitraum (Monate) verteilt erübrigen kann. Ich halte es aber heute wie 2010 für wichtig für FHEM, und deswegen setze ich mich dafür ein.

Ich lehne es ab, irgendwelche Module hier zu posten. Es wird einen Development-Branch im SVN geben. Darum kümmere ich mich als erstes. Der Stable-Branch würde regelmäßig in den Development-Branch gemergt werden.

Dann werde ich einen Minimalentwurf als Proof-of-Concept zum Review einchecken. Dazu werde ich ein Typen-Modul mit Convenience-Methoden bauen, ein Gerätemodul für eine Geräteklasse, die ich nutze, anpassen, und in FHEMWEB entsprechende Anpassungen machen. Ich gehe mal davon aus, daß im Development-Branch die Regel, daß jeder nur seine Module anfaßt, nicht greift.

Viele Grüße
Boris

Hallo Boris,

Zitatich empfinde das auch als Drängelei.

vielleicht. Das Klären der Zuständigkeiten oder zumindest das Benennen eines chair hat aber nichts mit Drängeln zu tun, es legt ja keinen Zeitplan fest. Das ist nur ein Minimum an Logistik und strukturiertem Arbeiten.

ZitatDu suchst jemanden, der das in die Hand nimmt.

ich suche? nun ja, kann man so sehen. Wie läuft das sonst hier? Ich kenne Zuständigkeiten für Module. Dies ist aber eine Zentralfunktion - wird evtl auch ein Modul... . Ich hätte erwartet, dass sich einer der "Herren-des-Kernal" hier einbringen wird und dies deutlich macht. Das hast du jetzt übernommen, gut.

ZitatIch halte es aber heute wie 2010 für wichtig für FHEM

volle Zustimmung. Daher ist der strukturierten Ablauf um so wichtiger.

ZitatDazu werde ich ein Typen-Modul mit Convenience-Methoden bauen, ein Gerätemodul für eine Geräteklasse, die ich nutze, anpassen, und in FHEMWEB entsprechende Anpassungen machen.

nun, ich erwarte eins nach dem Anderen. FHEMWEB ist sicher der letzte Schritt. Wir reden hier doch von Entwicklern??? Die sollten sich einen Eindruck auch ohne das Frontend verschaffen können. Mir würde eins nach dem Anderen reichen. Wichtiger wäre eine gute Doku mit den geplanten APIs.

ZitatIch gehe mal davon aus, daß im Development-Branch die Regel, daß jeder nur seine Module anfaßt, nicht greift.

ui, ist das so? Warum? Wie sind hier die Regeln?

Gruss Martin

Zitat von: Dr. Boris Neubert am 29 März 2014, 13:32:36die ich nutze, anpassen, und in FHEMWEB entsprechende Anpassungen machen.

Hallo Boris,

beachte dabei bitte, dass Rudi gerade ein paar grundlegende Änderungen von FHEMWEB in der Planung hat. Nicht dass Du Dir Arbeit mit der "alten" FHEMWEB machst und danach alles nochmal machen musst.

Ich denke auch dass die Darstellung in FHEMWEB der allerletzte Schritt sein wird. Ein stabiles Backend ist bei dieser Sache m.E. erstmal sehr viel wichtiger.

Viele Grüße
Udo

Hallo,

zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.

zum Development-Branch: da es so etwas bisher nicht (offziell) gibt, gibt es auch keine Regeln dafür. Aber wie kann ich ein Gefühl dafür entwickeln, wie das Frontend mit den Typen im Backend umgeht, wenn ich es nicht selbst programmiere. Das kann man immer noch wegwerfen oder später vom Maintainer aus dem Development-Branch in den Stable-Branch mergen lassen.

Ich hoffe, daß meine Ideen deutlicher geworden sind.

Viele Grüße
Boris

Hallo Boris,

ich verstehe, dass du damit etwas spielen willst - ist auch korrekt. Und es muss jeder selbst wissen, wie er ein Gefühl dafür entwickelt.
fhemWeb ist sicher ein wichtiges Frontend - ich denke es "gehört" Rudi, nicht dir.

Prinzipiell hat Udo sicher recht, das Frontend ist das letzte, was gemacht wird. FHEM-WEB ist im Übrigen nur ein Kunde. Es kann mehrere Frontends geben. Scripting interfaces haben mindestens den gleichen Stellenwert (also aktuell ReadingsVal, Num, Timestamp u.ä.)
Der ganze Aufwand wird ausschließlich dafür betrieben.

Noch einmal will ich meine Bitte loswerden:
Für die Backends darf es nicht zu einem Monster werden. Im Gegensatz zu Produktentwicklungen für eine Familie (eQ3 für HM...), die starre Strukturen vorgeben ist FHEM bisher flexibel. Es lebt geradezu davon. Die Nutzung der Objekte vom Backend muss diesem Luft zum Atmen lassen. Das betrifft das Anlegen und Befüllen der Objekte.

Ich erwähne, weil Teile der Diskussion über das Ableiten von Klassen (worauf einige Diskussionen Inhaltlich hinauslaufen) eine recht aufwendige und damit starre und schwerfällige Handhabung implizieren. Die Probleme sehe ich bereits und insbesondere beim Backend.

Darüber hinaus muss die Nutzung - sowohl vom Frontend (web UND script)  vom Backend Performance-optimiert ablaufen. Perl ist nun einmal von Natur aus ein sehr langsames Vehikel. Das Nutzen der Readings ist eine extrem häufig genutzte Funktion - Performance-fresser werden sich hier multiplizieren.

Bin auf den Ansatz gespannt.

Gruss Martin

Würde nicht gerade das Entfallen von Regular Expressions in der Eventverarbeitung erheblich zur Performancesteigerung führen ? Oder sind die RegEx in Perl so schenll ?

Zitat von: papa am 31 März 2014, 13:23:30Oder sind die RegEx in Perl so schenll ?

kommt drauf an, welche ;)

Es kommt auf das Gesamtkonzept an.
Wenn man erst aus vielen datenfeldern einen String basteln muss... muss man die Datenfelder suchen oder sind sie vorhanden - wie schnell wird zugegriffen...
dann: Wieviele Felder müssen "normal" geschrieben werden (nur VAL?..) und welche werden bei Bedarf zusammengebaut?
Im Webinterface werden alle einer Entity dargestellt (oder auch nicht?)

Die Frage der Häufigkeit ist (nicht unbedingt einfach) entscheidend.

Gruss Martin

Hi,

wo wir schon dabei sind, readings zu "erneuern" - das Problem mit den Units hätte ich auch einfacher lösbar gesehen...
was aber nicht einfach zu machen geht ist, Ordnung in die Readings zu bekommen. Wenn man diese strukturieren könnte wäre das hilfreich. Man kann zumindest operationale Zustände (licht an, licht an für x sec,... ) und Maintenance Zustände (battery low,...) unterscheiden. Evtl noch Alarme (sabotage-kontakt,...) oder Dev-Infos (serial Number)
Für HM hätte ich noch mehr, da die Device Konfiguration (register) in mehreren Gruppen.
Aktuell ist die Darstellung nur eine Krücke, da es hierfür keine Handhabe in FHEM gibt.

Ich sehe auf Anhieb 2 Methoden, etwas Ordnung hier zu bekommen:
- ein Attribut "group" in dem man - mehrstufig - die Gruppe des Readings klassifizieren kann (group="alarm", group="konfig:reg:peer1")
- in READINGS weitere Strukturen erlauben, die in die Tiefen gehen.

Ich denke die erste Variante ist einfacher zu implementieren.
Im User-Interface könnte man dann Gruppen auf und zu falten, per Klick

Wenn man hier eine ordentliche Gruppierung und ein Handling  aufsetzen würde könnte ich auch einige aktuellen Internals nach Readings verschieben - diese Trennung ist in einigen Fällen eh nicht Eindeutig und nur aufgezwungen.

Nächste Stufe wäre noch, einen visibility-level einzuführen - das brauch ich in HM (aber sonst wahrscheinlich niemand...). Die aktuelle Implementierung mit '.' und global showInternalValues ist ein Anfang, aber eigentlich viel zu sperrig und kostet mich jede Menge Code.

Damit bin ich im Prinzip wieder bei einem Antrag, eine bessere (oder überhaupt eine) Struktur in Parameter zu bekommen.

Gruss Martin

Gibt es zwischenzeitlich Weiterentwicklungen oder Zwischenstände?

Hallo,

kein neuer Ansatz, keine neue Diskussion, lediglich der Versuch, zumindest etwas kleines zu schaffen, was erweiterbar ist mit all den Ideen, die wir hier gesammelt haben:

Es wurde ja kürzlich der Wunsch geäußert, bei bestimmten berechneten Readings die Anzahl der Nachkommastellen zu begrenzen. Angenommen, es gäbe die Möglichkeit zu konfigurieren, dass für Gerät X das Reading Y im Format %5.2f angezeigt wird (wie auch immer das geht, über Interfaces, Konfigurationsdateien, am Gerät definiert, ...). Dann bezieht sich dieses Anzeigen auf FHEMWEB bzw. ein API, das dem Aufrufer den formatierten Anzeigewert des Readings liefert, nicht wahr? Und FHEMWEB (und jedes andere Frontend) würde dann in FW_devState() statt ReadingsVal(X, Y, "") die API-Funktion nutzen. Seht Ihr das genauso?

Viele Grüße
Boris

Da selbst triviale Sachen ueber die unterschiedlichen Frontends kaum eingehalten werden, wuerde ich beim readings*Update die Werte gleich mit der gewuenschten Genauigkeit speichern. Haette den Vorteil, dass es in jedem Frontend sofort klappt und den Nachteil, dass es keine "interne" hoehere Genauigkeit gibt. Was wiederum in vielen Faellen die Erklaerungen vereinfacht.

Hallo,

meinem Post ging eine ähnliche Diskussion an anderen Stellen voraus, in unterschiedlich allgemeingültiger Art  die Genauigkeit direkt ins Reading zu schreiben - wie Du es auch vorschlägst.

Ich sträube mich (noch) dagegen, weil es das Eingeständnis ist, dass wir es nie mehr schaffen werden, in FHEM Content und Darstellung voneinander zu trennen.

Das Forum sieht hier im Quartalstakt Aufstieg und Fall neuer Frontend-Initiativen. Aber kein einziges scheint sich mit der Schichtung von Anzeige, Transport und Content zu beschäftigen, sonst wäre das API längst implementiert.

Viele Grüße
Boris

Zitat von: Dr. Boris Neubert am 15 Mai 2015, 09:15:49
Hallo,
kein neuer Ansatz, keine neue Diskussion, lediglich der Versuch, zumindest etwas kleines zu schaffen, was erweiterbar ist mit all den Ideen, die wir hier gesammelt haben:

Hi Boris
Das Wahlergebnis waren in 2014 klar und eindeutig ... trotz geringe Teilnahme (Stimmen insgesamt: 11)
Leider die Developers die gewhelt haben, sind nicht die Owner der Kern-Modulen von FHEM und/oder sind Hobby-Programmierer wie ich :)

Zitat
Aber kein einziges scheint sich mit der Schichtung von Anzeige, Transport und Content zu beschäftigen, sonst wäre das API längst implementiert.

Ich begruße jeden Versuch hier weiterzugehen
immi