Einheiten Darstellung

[Martin]

Hallo,

ich habe nichts gefunden ueber die FHEM darstellung von Einheiten in Readings und Attriburen. Manche wollen dee Wert und die Einheit getrennt mit blank, anderen zusammen geschrieben.
Beides hat Vorteile, mir ist es egal. Ich moechte nur wissen, wie es im FHEM look&feel aussehen soll.
Gruss
Martin

[Rudolf Koenig]

> Manche wollen dee Wert und die Einheit getrennt mit blank, anderen zusammen
> geschrieben.

Meiner Arnsicht nach sollten wir immer ein Leerzeichen einfuegen, damit man die
Daten per awk & co bequem verarbeiten kann.

[Dr. Boris Neubert]

Hallo,

ich bin grundsätzlich gegen Einheiten im value-Feld, weil es die Weiterverarbeitung erschwert. In DbLog ist es ein Graus. Wir hatten uns schon mal darauf geeinigt, daß sich die Einheiten qua definitionem ergeben: Temperaturen zB immer in °C - siehe Development Guidelines.

Viele Grüße
Boris

---

Von: Martin <marti...@gmail.com>
Gesendet: Thu Nov 29 10:37:15 MEZ 2012
An: fhem-de...@googlegroups.com
Betreff: [FHEM-devel] Einheiten Darstellung

--
sent from my WePad - apologies for brevity

[UliM]

Hi,
Anlass der Frage war das %-Zeichen beim Actuator-Wert.

Bei FHT wird es ohne Leerstelle dargestellt:
2012-11-29 19:18:50.869 FHT ez_FHT actuator: 100%

bei HM neuerdings ebenfalls ohne Leerstelle:
2012-11-29 19:19:59.459 CUL_HM HM_TC actuator: 100%

Wie's bei MAX aussieht weiss ich nicht.
Ich hatte Martin gebeten, HM umzustellen, um Einheitlichkeit mit FHT zu erreichen.
Da HM bisher mit Leerstelle gebucht hat, beschweren sich nun die user, dass ihre Logs nicht mehr tun.

Mit Leerstelle ist generell sicher praktischer, FHT legt hier aber ein anderes Beispiel vor.

Da HM und MAX neuer sind, würde ich FHT als Standard betrachten, da mehr user von einer Umstellung betroffen wären.

Was meint ihr?

Gruß, Uli

[Markus Bloch]

Gemäß dem Fall FHT (also ohne Leerzeichen) wird zum Standard, wie kann ich diesen Wert denn dann am einfachsten Plotten?

Gruß

Markus

[Ulrich Maass]

Siehe zB FHT.gplot :)

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
Besuchen Sie https://groups.google.com/d/msg/fhem-developers/-/Y3gryQHz0AsJ, um diese Diskussion im Web anzuzeigen.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-developers?hl=de, um weitere Optionen zu erhalten.

[Martin Fischer]

Am Donnerstag, 29. November 2012, 19:01:33 schrieb Dr. Boris Neubert:
> [...]

> ich bin grundsätzlich gegen Einheiten im value-Feld, weil es die
> Weiterverarbeitung erschwert. In DbLog ist es ein Graus. Wir hatten uns
> schon mal darauf geeinigt, daß sich die Einheiten qua definitionem ergeben:
> Temperaturen zB immer in °C - siehe Development Guidelines.

dem stimme ich zu! wir hatten die diskussion seinerzeit ja nicht aus langer
weile geführt. es wurde nur niemals _konsequent_ umgesetzt. also sollten wir
uns jetzt danach richten.

gruss

[Matthias Gehre]

Hab bisher keine Einheiten in den Readings der MAX Module. Ist aber nicht haltbar, da
es dort z.B. Felder gibt, die in Minuten angegeben werden und andere die in Sekunden angegeben werden.
Bisher ist die Einheit dafür aber nur aus der Commandref ablesbar.

Ich wär dafür, dass man sowas wie {READINGS}{desiredTemperature}{UNIT} einführt.
Im der WebUI würde man dann für jedes Reading "{VAL} {UNIT}" anzeigen, aber trotzdem kann man im Code direkt
mit {VAL} rechnen.
Das könnte man auch erstmal optional machen, (also wenn kein {UNIT} existiert, dann zeigt man nur {VAL} an).
Und dann sollte man das in die Parameterlist der BulkUpdate Funktionen aufnehmen.

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.

[Dr. Boris Neubert]

Hallo Matthias,

bitte schaue Dir mal die Diskussion an, die in dieser Gruppe vor einigen Jahren genau zu diesem Vorschlag stattfand, und zu dem Ergebnis führte, es nicht so zu machen.

Du könntest alle Zeitdauern in Sekunden führen.

Viele Grüße
Boris

---

Von: Matthias Gehre <gehre.m...@gmail.com>
Gesendet: Fri Nov 30 00:26:19 MEZ 2012
An: fhem-de...@googlegroups.com
Betreff: Re: [FHEM-devel] Einheiten Darstellung

[Martin]

Wur sprechen hier vom User interface und dass soll lesbar sein, glaube ich. Dazu braucht der USER Einheiten. Temperatur ist in manchen Laendern Fahrenheit - und hie und da habe ich englische Anfragen gesehen. Einheitenlos geht nur fuer interen Interfaces und experten mode - sorry. Wird sonst kein User verstehen.
Zeit inSekunden zumUmrechnen ist nicht hilfreich, zum Machienenverarbeitenschon

Gruss
Martin

[tobias.faust]

Bei den OW* Modulen gibt es das Attribut "Unit" dort kann man die Einheit abbilden falls sie von der Voreinstellung abweichen möchte. Und mit dieser Info kann man dann auch backendseitig parsen.
Finde diese Lösung ganz schick

[Martin]

Am Freitag, 30. November 2012 09:00:29 UTC+1 schrieb tobias.faust:

Bei den OW* Modulen gibt es das Attribut "Unit" dort kann man die Einheit abbilden falls sie von der Voreinstellung abweichen möchte. Und mit dieser Info kann man dann auch backendseitig parsen.
Finde diese Lösung ganz schick

 

Wieviele Attribute Unit hast du?  Und wo deiten die hin? Kann ich das als user auf den ersten Blick zuordnen?
Ich habe es nicht gesehen - also die Fragen sind ernst gemeint.
Jedenfalls kann es nicht sein, dass das User interface ein Puzzle ist. Der User sollte weder raten noch suchen oder beuten muessen. Auch merken ist schlecht.

Dies ist ganz im Gegensatz zu einem Maschinen interface. Da ist alles oben erlaubt  - wer ein Maschineninterface benutzt muss sich intensiv schlau machen, Units nachlesen, mit anderen Variablen verknuepfen,... alles ok.
fhem sollte fuer beide Anwendungen eine Loesung bereithalten - ist auch kein Problem - da kann jeder von euch zig Loesungen vorschlagen, wie man es einbaut. Wir muessen uns nur einigen.

Fuer alles andere habe ich kein Verstaendniss.
Bleibt die Frage: ist das web-interface ein User-interface? Ich denke schon

[Matthias Gehre]

Ich hab natürlich darüber nachgedacht, alle Zeiten in Sekunden zu führen.
Die sog. Boost Dauer der MAX Thermostate wird auch in Sekunden angegeben, doch z.B.
die Fensteröffnungsdauer kann man nur in Minuten einstellen. Dann wäre es doch für den Benutzer verwirrend,
wenn ich ihm das aber in Sekunden anzeige.

Also ich finde, dass
1. im UI Einheiten vorhanden sein müssen
2. die Einheiten getrennt von den Werten gespeichert werden sollten

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.

Besuchen Sie https://groups.google.com/d/msg/fhem-developers/-/MrLDH6Z898wJ, um diese Diskussion im Web anzuzeigen.

[Prof. Dr. Peter A. Henning]

Das mit den Units ist z.B. als

    $hash->{READINGS}{"$owg_channel[$i]"}{TYPE}     = $cnama[1]; 
    $hash->{READINGS}{"$owg_channel[$i]"}{UNIT}     = $unarr[0];
    $hash->{READINGS}{"$owg_channel[$i]"}{UNITABBR} = $unarr[1];
    $hash->{READINGS}{"$owg_channel[$i]"}{OFFSET}   = $offset; 
    $hash->{READINGS}{"$owg_channel[$i]"}{FACTOR}   = $factor; 

in den OW-Modulen konsequent umgesetzt. Darin ist

# attr <name> <channel>Name   <string>|<string> = name for the channel | a type description for the measured value
# attr <name> <channel>Unit   <string>|<string> = unit of measurement for this channel | its abbreviation
# attr <name> <channel>Offset <float>  = offset added to the reading in this channel
# attr <name> <channel>Factor <float>  = factor multiplied to (reading+offset) in this channel

Das macht auch Sinn, denn beispielsweise liefert ein Feuchtesensor an einem A/D-Wandler zunächst einmal eine Spannung, die im (universellen) Modul auf die (spezielle) "Einheit" Prozent umgerechnet wird.  Und der Messkanal heißt eben nicht "Kanal 1" oder "A", sondern "H", "Hum" oder "Feuchte" - und hat dem TYPE "humidity"

Ein Frontend kann also an Hand des TYPE entscheiden, wie der Wert dargestellt wird, und wie die Einheit dargestellt wird (z.B. mit der vorgeschlagenen Abkürzung UNITABBR), oder wie wie umgerechnet wird (dafür wird man UNIT auswerten). Davon werde ich auch in keinem Falle abrücken.

Insofern ist es auch nicht von Bedeutung, dass sich eine kleine Gruppe von Jahren mal darauf "geeinigt" hat, das anders zu machen - da sah die FHEM-Welt auch noch etwas anders aus.

LG

pah

[Martin]

Hi pah,

Wenn ich dich richtig deute ist deine Meinung
1) Einheiten ja
2) erstelle nach einem speziellen konzept
3) erstellungsparameter sind nicht User sichtbar oder aenderbar
4) die Zusatzparameter sind eigentlich nicht public

zu 1,3 und 4 kann ich zustimmen, quasi bedingungslos.
2 habe ich nicht wirklich verstanden, ist auch egal. wird inter-modul geregelt. Evtl hole ich mir hier tips...

Was mit fehlt ist nun das User-sichtbare Ergebnis deiner Aktionen.  Das User- und intra-modul interface ist doch immer noch {val}. Was steht am Ende in {val}? Der Wert und die Einheit? Mit oder ohne Blank?

LG Martin

[Rudolf Koenig]

> Insofern ist es auch nicht von Bedeutung, dass sich eine kleine Gruppe von
> Jahren mal darauf "geeinigt" hat, das anders zu machen - da sah die
> FHEM-Welt auch noch etwas anders aus.

Ignorieren kann mann die Meinung Anderer immer, das machen die anderen ja
schliesslich auch :)

OW benoetigt so ein System, weil die Geraete haeufig Rohdaten melden, die man
je nach Einssatzzweck erst umrechnen muss. Bei manchen anderen wuerde es nicht
schaden, weil nicht alle Werte klar sind, und bei den meisten aktuell in fhem
eingesetzten Geraeten ist es Ballast, weil es vollkommen klar ist, was gemessen
wird. Klar kann man die frontends Umbauen (lassen), es ist halt fuer die
meisten Module erstmal Arbeit und Ballast ohne konkreten Nutzen, weiterhin muss
man komische Fragen wie "welche Einheit/Abkuerzung hat eigentlich Ein / Aus /
Montag / 22:00 / auto / ok" beantworten.

Waere es nicht moeglich in Problemfaellen, wo es weder generisch dokumentiert
werden kann, noch auf dem ersten Blick klar ist, die Einheit per Leerzeichen
dranzuhaengen?
Ich bin immer noch der Ansicht, dass ich eher vergesse, wo mein
Temperatursensor haengt, als das ich die gemeldete Einheit vergesse.

Ich will versuchen, fhem einigermassen schlank zu behalten, auch wenn das
Ergebnis nicht perfekt ist, und ich plaediere auf Einsicht.

[Martin Fischer]

Am Freitag, 30. November 2012, 03:31:22 schrieb Prof. Dr. Peter A. Henning:
> [...]

> Insofern ist es auch nicht von Bedeutung, dass sich eine kleine Gruppe von
> Jahren mal darauf "geeinigt" hat, das anders zu machen - da sah die
> FHEM-Welt auch noch etwas anders aus.

so wie für dich die einigungen der "kleinen gruppe" offensichtlich keine
bedeutung hat, solltest auch du dir bewusst sein, dass auch dein vorschlag für
den einen oder anderen ggf. nicht von bedeutung sein wird.

die kleine gruppe hat u.a. selber dafür gesorgt, das fhem stetig
weiterentwickelt wurde und sich allein dadurch die "fhem-welt" schon verändert
hat.

und diese "fhem-welt" kann mit _vorschlägen_ angereichert werden, worauf sich
letztlich _alle_ drauf "committen" sollten... wie gut das klappt zeigen die
"diskussionen" rund um das release 5.3. und sei es nur das thema "html
elemente"..

worum es mir bei der aussage geht:
dieses projekt ist ein gemeinschaftsprojekt, mit rudi als "klammer". es gilt
also einen _gemeinsamen_ weg zu finden, denn dann auch alle tragen. und wer
das in seinen modulen nicht trägt, gehört aus meiner sicht nach contrib.

irgendwelche "einigungen", die (auch wenn vor jahren) beschlossen wurden,
sollten erstmal _gemeinsam_ verifiziert werden anstatt sie auf die schnelle zu
degradieren,

das ist alles was ich konkret zu dem thema "kleine Gruppe" und "Fhem-Welt"
äussere. ich steige dann wieder ein, wenn es sachlich und konrekt wird.

gruss...

[Dr. Boris Neubert]

Hallo Martin,

Du triffst genau den Punkt. Der Maschinenteil ist das, was in Value steht. Das UI, zB Fhemweb, macht das für den User verständlich. Dazu muss es die Einheit kennen. Die kann man also mitführen oder aus der Interface-Definition ableiten. Im letzteren Fall weiß das UI aufgrund des "temperature"-Interface von FHT, daß die Einheit von temperature °C ist und rechnet das in °F um und schreibt 54 °F in den HTML-Code.

Die Vor- und Nachteile dieser Vorgehensweise hat eine "kleine Gruppe" von etwa 10 Personen vor Jahren hin- und hergewendet und kam dann zu dem Ergebnis, es wie beschrieben machen zu wollen. Und auch die hunderste "cetereum censeo"-E-Mail zu diesem Thema ändert solange nichts daran, bis substantiell neue Argumente ins Feld geführt werden. Solche habe ich aber bis dato nicht gesehen - nein, noch nicht einmal die Bereitschaft zum Eingehen auf die damalige Diskussion.

Viele Grüße
Boris

---

Von: Martin <marti...@gmail.com>
Gesendet: Fri Nov 30 07:42:06 MEZ 2012

[Martin]

Am Freitag, 30. November 2012 17:56:33 UTC+1 schrieb Boris Neubert:

Hallo Martin,

Du triffst genau den Punkt. Der Maschinenteil ist das, was in Value steht. Das UI, zB Fhemweb, macht das für den User verständlich. Dazu muss es die Einheit kennen. Die kann man also mitführen oder aus der Interface-Definition ableiten. Im letzteren Fall weiß das UI aufgrund des "temperature"-Interface von FHT, daß die Einheit von temperature °C ist und rechnet das in °F um und schreibt 54 °F in den HTML-Code.

Hoert sich gut an fuer mich. User sieht Einheiten im Web interface -scripts arbeiten mit reinen Zahlen. Werde mir bei Gelegenheit die Details ansehen. Gute Vorlage waere dann OW, habe ich verstanden?

Gruss
Martin

[Dr. Boris Neubert]

-------- Original-Nachricht --------
Von: Martin <marti...@gmail.com>
Gesendet: Fri Nov 30 19:20:40 MEZ 2012

An: fhem-de...@googlegroups.com
Betreff: Re: [FHEM-devel] Einheiten Darstellung

> Hoert sich gut an fuer mich. User sieht Einheiten im Web interface
-scripts arbeiten mit reinen Zahlen. Werde mir bei Gelegenheit die Details

genau!

ansehen. Gute Vorlage waere dann OW, habe ich verstanden?

OW führt die Einheit explizit mit. Die Meinung ist aber, daß dies nicht nötig ist, wenn stattdessen das Interface-Konzept zur Anwendung kommt (siehe DevelGuidelines + Diskussion von damals).

Grüße
Boris

[Prof. Dr. Peter A. Henning]

21:52 (vor weniger als eine Minute)

Liebe Leute,

bei allem Respekt vor der jahrelangen Arbeit anderer: Der Hinweis, "wir haben das vor Jahren aber anders entschieden", geht ein wenig in Richtung abbügeln - und Letzteres habe ich bis an die Hutkante satt. Ich habe gar keine Probleme damit, mich an Standards zu halten - ihr könnt Euch gerne mal einen ISO-Standard ansehen, an dem ich mitgewirkt habe. Doch nur,  wenn sie nicht kontraproduktiv sind. Und im Falle von OW ist das der Fall, wie Rudolf König richtig ausführt - und wie man auch als "langjähriger Entwickler von FHEM " sehen kann, wenn man nur will.

Also lassen wir das Meta-Gelaber, zur Sache:

In meiner Implementation enthalten die VAL-Werte tatsächlich nur den Zahlenwert. Seine Bedeutung (TYPE) und Einheit (UNIT/UNITABBR) sind als Metadaten zugänglich. Und, _nein_ sie folgen nicht aus einer "interface"-Definition,  die ein wenig nach "Art pour l'Art" aussieht. Sondern diese Metadaten sind durch den Benutzer frei konfigurierbar.

Die veröffentlichte Version der OW-Module setzt diese ein, um die STATE-Variable zu definieren (mit Einheit eben...).

Die aktuelle Version der Module (an der bastele ich noch etwas herum...) benutzt dafür die state-Variable und den neuen Update-Mechanismus. Dadurch kann ein Anwender die Formatierung des state komplett überschreiben - und von mir aus auch die Einheiten herauswerfen.

Zwei meiner Studenten sind schon relativ weit gediehen mit einem neuen Frontend (basiert auf HTML5 und AJAX). Das werden wir genau so stricken, dass ein eventuelles TYPE Metatdatum ausgewertet wird.

LG

pah

[Willi]

>habe gar keine Probleme damit, mich an Standards zu halten - ihr könnt Euch gerne mal einen ISO-Standard 

Bitte keinen ISO-Standard aus FHEM machen. 

Wir wollen Ergebnisse haben und keine Standards festlegen, die nachher keiner implementieren kann, weil es nur ein Kompromiss und keine Lösung ist.

Mir hat es gereicht, was die ISO-Leuter in den 80er-Jahren angerichtet haben und als Standard durchsetzen wollten: X.25, X.29, X.400, X.500. In DE haben sich die Offiziellen bis zuletzt gegen TCP/IP gewehrt.

Glücklicherweise für den Anwender hat sich TCP/IP und der Weg der IETF durchgesetzt...............

[Prof. Dr. Peter A. Henning]

rofl - nein, so ein Standard ist das nicht.

pah

[Dr. Boris Neubert]

Hallo Peter,

Am 30.11.2012 21:52, schrieb Prof. Dr. Peter A. Henning:
> bei allem Respekt vor der jahrelangen Arbeit anderer: Der Hinweis,
> "wir haben das vor Jahren aber anders entschieden", geht ein wenig in
> Richtung abbügeln - und Letzteres habe ich bis an die Hutkante satt.

> Ich habe gar keine Probleme damit, mich an Standards zu halten - ihr könnt

Der Punkt ist nicht, daß wir an einer einmal getroffenen Entscheidung zu
Entwicklervorgaben in FHEM aus festhalten wollen aus "Prinzip", aus
Sturheit, aus Unverständnis, das Gute an Deiner Vorgehensweise zu sehen,
.... Deine Vorgehensweise und eine Reihe weiterer Möglichkeiten wurde
damals unter den Entwicklern diskutiert. Als Ergebnis kamen wir darauf,
daß das Mitführen von Einheiten am Reading nicht die gewünschte/beste
Lösung ist sondern jene, die in den Development Guidelines dokumentiert
ist. Solange nicht substantiell neue Argumente ins Feld geführt werden,
die wir damals nicht bedacht haben, sehe ich keinen Sinn darin, die
Diskussion wieder aufzumachen.

Die ständige Wiederholung des Vorschlags, die Einheiten doch an den
Readings mitzuführen, führte bisher nicht dazu, daß sich jemand darauf
einlassen möchte, die Diskussion von damals wieder aufzumachen. Das
bringt uns in der Qualität von FHEM nicht weiter. Es ist mir einfach nur
lästig.

Viele Grüße
Boris

[Prof. Dr. Peter A. Henning]

Oh, lästig ist mir auch vieles...

Beispielsweise das sture Beharren auf alten Positionen mit der unsinnigen Behauptung, damals alles bedacht zu haben - so etwas habe ich häufig in kirchlichen Gremien angetroffen.

Aber mach Du nur, wir haben eine freie Welt.

LG

pah

[Dr. Boris Neubert]

Ich bin enttäuscht von dieser Form der Auseinandersetzung.

Ich habe in auch in dieser Antwort kein Argument zur Sache gefunden.
Hast Du dir die Diskussionen von damals überhaupt schon einmal angesehen?

Viele Grüße
Boris

[Prof. Dr. Peter A. Henning]

Es reicht an dieser Stellle, dass das Ergebnis der Diskussion nicht mehr mit der Realität übereinstimmt: Eine Hypothese wird durch ein einzelnes Gegenbeispiel invalidiert. Das Nachlesen jahrealter Diskussionen mag zwar von manchem als spannend empfunden werden - aber ich habe dafür bei meinem Terminkalender keine Zeit.

Du findest genügend Sachargumente in dem Beispiel des A/D-Wandlers, der zwei verschiedene Spannungen und eine Temperatur misst und daraus mittels einer als Attribut übergebenen Formel die relative Feuchte berechnet. Typ und Einheit müssen hier zur Laufzeit änderbar sein - oder das Modul verlöre seine Universalität.

LG

pah

[Dr. Boris Neubert]

Am 01.12.2012 19:54, schrieb Prof. Dr. Peter A. Henning:
> Es reicht an dieser Stellle, dass das Ergebnis der Diskussion nicht
> mehr mit der Realität übereinstimmt: Eine Hypothese wird durch ein
> einzelnes Gegenbeispiel invalidiert. Das Nachlesen jahrealter
> Diskussionen mag zwar von manchem als spannend empfunden werden - aber
> ich habe dafür bei meinem Terminkalender keine Zeit.

Ach so, Du hast OWX so programmiert, daß es nicht mit den Development
Guidelines kompatibel ist, und erwartest nun, daß die Regeln geändert
werden.

>
> Du findest genügend Sachargumente in dem Beispiel des A/D-Wandlers,
> der zwei verschiedene Spannungen und eine Temperatur misst und daraus
> mittels einer als Attribut übergebenen Formel die relative Feuchte
> berechnet. Typ und Einheit müssen hier zur Laufzeit änderbar sein -
> oder das Modul verlöre seine Universalität.

Das Nachlesen wochenalter Diskussionen mag zwar von manchem als spannend

empfunden werden - aber ich habe dafür bei meinem Terminkalender keine Zeit.

Viele Grüße
Boris

[Prof. Dr. Peter A. Henning]

Ach so, Du hast OWX so programmiert, daß es nicht mit den Development
Guidelines kompatibel ist, und erwartest nun, daß die Regeln geändert
werden.

Falsche Schlussfolgerung - ich erwarte gar nichts und habe auch keine "Mission". Aber "Guidelines" sind auch keine "Regeln" - wir sind hier nicht in einem Industrieunternehmen und Du nicht der CTO.

Das Nachlesen wochenalter Diskussionen mag zwar von manchem als spannend
empfunden werden - aber ich habe dafür bei meinem Terminkalender keine Zeit.

Das war nicht sarkastisch gemeint.

LG

pah

[Dr. Boris Neubert]

Hallo,

Am 01.12.2012 21:51, schrieb Prof. Dr. Peter A. Henning:

Ach so, Du hast OWX so programmiert, daß es nicht mit den Development
Guidelines kompatibel ist, und erwartest nun, daß die Regeln geändert
werden.

Falsche Schlussfolgerung - ich erwarte gar nichts und habe auch keine "Mission". Aber "Guidelines" sind auch keine "Regeln" - wir sind hier nicht in einem Industrieunternehmen und Du nicht der CTO.

Deine Antwort zeigt mir, daß es mir nicht gelungen ist, Dir zu vermitteln, worum es mir geht.

Das Nachlesen wochenalter Diskussionen mag zwar von manchem als spannend
empfunden werden - aber ich habe dafür bei meinem Terminkalender keine Zeit.

Das war nicht sarkastisch gemeint.

Stimmt, und genau deswegen sehe ich für mich keinen Sinn mehr darin, das Gespräch an dieser Stelle weiter fortzusetzen.

Viele Grüße
Boris

[Rudolf Koenig]

> Typ und Einheit m�ssen hier zur Laufzeit �nderbar sein - oder das Modul
> verl�re seine Universalit�t.

Das ist volkommen richtig, ich moechte aber vermeiden wegen einem Modul, 100
andere Module mit "Ballast" versehen zu muessen. Vielleicht reicht fuer OW
auch eine Notloesung, z.Bsp. Einheit mit Leerzeichen ranzuhaengen.
Genauso hat HM das Problem Geraet vs. Kanal, fuer EnOcean und Zwave koennte man
fhem auch komplett umbauen, wuerde aber fuer alle anderen Module nur Ballast
bedeuten. Ich will vermeiden unbedingt alle Probleme theoretisch perfekt zu
loesen, da ich vermute, dass sowas nicht mit akzeptabler Aufwand realisierbar
ist.

[Prof. Dr. Peter A. Henning]

Deine Antwort zeigt mir, daß es mir nicht gelungen ist, Dir zu vermitteln, worum es mir geht.

Das ist wahr. Lass Dir mal einen Tipp von einem mehrfach ausgezeichneten Pädagogen geben: Das liegt nicht am Empfänger, sondern meistens am Sender...

LG

pah

 

[UliM]

Am Sonntag, 2. Dezember 2012 16:03:20 UTC+1 schrieb Prof. Dr. Peter A. Henning:

mehrfach ausgezeichneten Pädagogen geben: Das liegt nicht am Empfänger, sondern meistens am Sender...

Schade dass Du Deine grossartige Qualifikation v.a. in fhem-users ständig hinter destruktiven Kommentaren versteckst.

[Willi]

Schade dass Du Deine grossartige Qualifikation v.a. in fhem-users ständig hinter destruktiven Kommentaren versteckst.

Ich finde es auch schade, dass solches Verhalten dazu führt die Vorurteile gegen selbstherrliche deutsche Professoren weiter zu festigen. Zumindest kommt das bei mir so an.

Insbesondere da pah bei fast jedem Posting betont, dass er ein Professor ist, was meines Erachtens nach nicht in diese Diskussionsgruppe gehört. Kompetenz erlangt man nicht durch einen Titel.

[Prof. Dr. Peter A. Henning]

Das erwarte ich ja auch gar nicht. Nicht einmal in meinen anderen Modulen (NT5000 und EMX) habe ich das bisher selber umgesetzt.

Es geht mir, um das noch einmal klar zu sagen, nicht um die Definition von "Standards" oder "Guidelines" für andere Leute oder Module. Ich akzeptiere aber auch keine Vorschriften, die für den gegebenen Anwendungszweck kontraproduktiv sind.

Auch sehe ich das bei den 1-Wire Modulen nicht als Notlösung, bisher passt das doch bestens. Und mit dem neuen "State"-Mechanismus kann jeder die Einheiten rauswerfen, der sie nicht will.

Für sinnvoll halte ich diesen Einheitenmechanismus auch in anderen Modulen (nicht in allen, Gott bewahre...)

LG

pah

[Prof. Dr. Peter A. Henning]

@Willi:

Ich betone gar nichts. Ich habe aber auch keinen Grund, meinen Accountnamen zu ändern. Über den Zusammenhang zwischen Titel und Qualifikation kannst Du ja gerne mal vor einem angemessenen Publikum eine Podiumsdiskussion mit mir führen - ob Du das aber mit Deinen gefestigten Vorurteilen über Herz bringst, wage ich zu bezweifeln. Also arbeite Dich halt weiter daran ab, da gibt es noch andere. Sehr amüsant, im Übrigen.

Zur Sache:

Einheiten im Log: In dem Modul NT5000.pm wird das so geregelt, dass einmal pro Tag bei der Anlage eines neuen Logs eine Spaltenüberschrift geschrieben wird. Das ist schon sinnvoll, weil man sonst beim Durchforsten der Log-Datei ständig suchen muss. In den Zeilen kommen die Einheiten nicht vor.

Benutzungsoberfläche: Wenn wir ein Frontend hätten, das die Anzeige aus VAL und UNIT zusammenbaut, könnte man auf die EInbindung in State verzichten. Haben wir aber nicht (zumindest, solange unser eigenes FE noch nicht steht). Also derzeit: State mit Einheiten. Logfiles kann man mit dem neuen State-Mechanismus aus den reinen VAL-Einträgen bestücken - leider derzeit noch nicht so, dass eine Zeile mit mehreren Werten beschrieben wird.

Leerzeichen: Zustimmung

LG

pah

[Willi]

Am Sonntag, 2. Dezember 2012 17:22:26 UTC+1 schrieb Prof. Dr. Peter A. Henning:

@Willi:

Ich betone gar nichts. Ich habe aber auch keinen Grund, meinen Accountnamen zu ändern. Über den 

@pah:

Es geht nicht um den Accountnamen.

Vermutlich merkst Du das gar nicht mehr, weil Du es ständig so machst....

Wenn es Dir hilft, kann ich Dich beim nächsten Mal daran erinnern ;-)

[Dr. Boris Neubert]

Am 02.12.2012 16:03, schrieb Prof. Dr. Peter A. Henning:

Deine Antwort zeigt mir, daß es mir nicht gelungen ist, Dir zu vermitteln, worum es mir geht.

Das ist wahr. Lass Dir mal einen Tipp von einem mehrfach ausgezeichneten Pädagogen geben: Das liegt nicht am Empfänger, sondern meistens am Sender...

Von Dozent zu Dozent: solche Ratschläge verbitte ich mir.

Und nachdem der Thread nun ins Persönliche abgeglitten ist, ist für mich hier endgültig Schluß.

BN

[Prof. Dr. Peter A. Henning]

Ach danke, ich verzichte.

Verhaltenskorrekturen kannst Du bei Deinen Kindern anbringen.

pah