[FHEM-devel] Standardisierung der Readings

[Dr. Boris Neubert]

Hallo,

warum brauchen wir eine Standardisierung von Readings?

Verschiedene physikalische Geraeteklassen tun praktisch dasselbe:
- Dimmer: X10, FS20
- Schalter: X10, FS20
- Wetterstationen: KS300, WS2000
- Thermometer: S555TH, HMS100T, HMS100TF, FHT80b, KS300, WS2000, OWTEMP
- Thermometer/Hygrometer-Kombinationen: S555TH, HMS100TF, FHT80b, KS300,
WS2000

Sie sind in verschiedenen Modulen implementiert, die dem Anwender
dieselbe Information (z.B. Temperatur) in verschiedenen
modulindividuellen Formen zurueckliefern.

Deswegen muessen die Frontends/GUIs fuer jedes neue Geraet/Modul wieder
angepasst werden. Wuerden Thermometer die Temperatur immer auf dieselbe
Weise zurueckliefern, z.B. als

$defs{myDevice}{readings}{temperature}{value}=23.2

(bzw. aequivalente Darstellung in xmllist), egal ob myDevice ein KS300,
S555TH, HMS100TF, FHT80b, OWTEMP oder sonstwas ist, braeuchte das
Frontend nur zu wissen, dass es sich um ein Thermometer handelt und
folglich muesste die Temperaturanzeige nur einmal implementiert werden.

Um meinen eigenen Vorschlag dazu wieder aufzugreifen, schlage ich die
Einfuehrung des Konzepts von Interfaces vor:

Jedes Geraet hat ein Internal namens Interfaces, das im Modul
hartkodiert wird:

$defs{myDevice}{internals}{interfaces}="temperature:humidity" fuer
eine Thermometer/Hygrometer-Kombination
$defs{myDevice}{internals}{interfaces}="humidity:switch_active" fuer
einen Thermostat
$defs{myDevice}{internals}{interfaces}="switch_passive:dimmer" fuer
einen Dimmer
etc.

Dazu gibt es eine allgemeinverbindliche Dokumentation (abgelegt unter
den DevelopmentGuidelines), welche standardisierten Readings ein Geraet
zurueckliefert, wenn es ein bestimmtes Interface implementiert (diese
Information wird nicht kodiert und nicht vom Modul bereitgestellt):

Geraet implementiert Interface "temperature" => Geraet hat ein Reading
"temperature"
Geraet implementiert Interface "switch_passive" => Geraet hat ein
Reading "state"
usw.

Nutzen:
- Die Frontends/GUIs orientieren sich bei der Darstellung nicht mehr an
der Geraeteklasse sondern an den Interfaces. Beispielsweise kann ein
rudimentaeres GUI, dass nur Temperaturverlaeufe, Luftfeuchteverlaeufe
und kombinierte Temperatur-/Luftfeuchteverlaeufe anzeigen kann, sofort
mit S555TH, HMS100T, HMS100TF, FHT80b, KS300, WS2000, OWTEMP umgehen,
und wird auch jede neue Thermomentersorte ohne Aenderungen am Kode
darstellen koennen.
- Die Einheiten werden ebenfalls Bestandteil der Dokumentation und
muessen nicht explizit ausgelesen werden.

Was haltet Ihr davon?

Gruesse,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
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.

[Rudolf Koenig]

> Was haltet Ihr davon?

Viel :), wir sollten mit der Definition der interfaces loslegen.

Vielleicht muss man aber nicht alle 77 Readings der KM271 oder 62 Readings der
FHT standardisieren, fuer mich reicht ein "sinnvoller" subset.

[Dr. Boris Neubert]

Am 15.05.2010 20:40, schrieb Rudolf Koenig:
> Viel :), wir sollten mit der Definition der interfaces loslegen.

siehe http://fhemwiki.de/index.php/DevelopmentInterfaces

> Vielleicht muss man aber nicht alle 77 Readings der KM271 oder 62 Readings der
> FHT standardisieren, fuer mich reicht ein "sinnvoller" subset.

siehe "The list of interfaces for a given device does not need to be
exhaustive. Readings that are not covered by the interfaces announced by
the device can still be shown by simply enumerating the readings."

Sollen Interfaces Vererbung unterstuetzen? Ich gehe mal davon aus, dass
ein Dimmer immer auch ein passiver Schalter ist. Reicht es dann,

$hash->{internals}{interfaces}= "dimmer";

zu schreiben, oder tut man dem GUI einen Gefallen, wenn man

$hash->{internals}{interfaces}= "switch_passive:dimmer";

schreibt?

Gruesse,
Boris

[Rudolf Koenig]

> Sollen Interfaces Vererbung unterstuetzen? Ich gehe mal davon aus, dass
> ein Dimmer immer auch ein passiver Schalter ist. Reicht es dann,

Wenn interfaces "nur" als Definition vorliegen, dann sollte es keine Vererbung
geben, sonst muss das Frontend immer angepasst werden. In diesen Kontext finde
ich Vererbung nicht so wichtig, es spart kaum etwas.

[Dr. Boris Neubert]

Am 17.05.2010 08:28, schrieb Rudolf Koenig:
> Wenn interfaces "nur" als Definition vorliegen, dann sollte es keine Vererbung
> geben, sonst muss das Frontend immer angepasst werden. In diesen Kontext finde
> ich Vererbung nicht so wichtig, es spart kaum etwas.

Stimme zu. Aus Bequemlichkeit sollten wir dann Vererbung nur in der
Dokumentation benutzen, um uns nicht endlos zu wiederholen, wenn Geraete
Spezialisierungen anderer Geraete sind. Und wie die GUIs dann z.B.
Darstellungsklassen implementieren, die die Vererbung nachbilden, bleibt
diesen überlassen.

Ergo:
$defs{meinDimmer}{internals}{interfaces}="switch:switch_passive:dimmer";

Apropos GUI: was meinen denn die GUI-Entwickler?

Grüße,
Boris

[Martin Haas]

On 19 Mai, 21:13, "Dr. Boris Neubert" <om...@online.de> wrote:

>
> Ergo:
> $defs{meinDimmer}{internals}{interfaces}="switch:switch_passive:dimmer";
>
> Apropos GUI: was meinen denn die GUI-Entwickler?

"Normungen" sind natürlich immer gut, alleine schon um nicht alle
Geräte wirklich kennen (haben) zu müssen, um sie korrekt darzustellen.
Die Praxis zeigt aber, dass allenfalls Subsets von den Geräten
wirklich identisch sein können.

> - Thermometer: S555TH, HMS100T, HMS100TF, FHT80b, KS300, WS2000, OWTEMP

So müssen in dieser Auflistung einige Geräte wirklich komplett anders
angefasst werden:
-- die KS300 bringt ja Unmengen an weiteren Information wie Wind etc
mit.
-- FHT80b hat zwar auch Temperatur drin, aber alles andere ist
eigentlich viel interessanter.
-- Sonst ist Temperatur und/oder Luftfeuchtigkeit enthalten. Ok, da
könnte man versuchen die Darstellung zu automatisieren.
Damit will ich sagen, dass ich mir nicht vorstellen kann, Geräte ohne
sie näher zu (er)kennen, komplett automatisch darzustellen.
Insofern sind die Normierungsbemühungen sicher der richtige Weg, zu
viel Arbeit würde ich da allerdings nicht investieren.

Ansonsten finde ich es toll, das Ihr Euch hier Gedanken macht, wie man
das alles noch besser machen kann.
Schade, dass ich zuwenig von Perl verstehe und hier nicht wirklich
mitreden kann.

Grüße,
Martin

[Dr. Boris Neubert]

Hallo Martin,

zunächst vielen Dank für Deine Kommentierung!

Am 20.05.2010 08:25, schrieb Martin Haas:
> Damit will ich sagen, dass ich mir nicht vorstellen kann, Geräte ohne
> sie näher zu (er)kennen, komplett automatisch darzustellen.
> Insofern sind die Normierungsbemühungen sicher der richtige Weg, zu
> viel Arbeit würde ich da allerdings nicht investieren.

die Standardisierung der Geräte ist mir insbesondere deswegen ein
Anliegen, weil ich Dein pgm3 nutze und gesehen habe, daß es aufwendig
ist, neue Gerätetypen zu implementieren, die dasselbe leisten, wie
bestehende. Auch bat Martin Fischer darum, daß sich die X10-Dimmer so
ansteuern lassen wie die FS20-Dimmer.

Mit den normierten Interfaces würden sich in meinem Fall zusammenfassen
lassen:
- Alle passiven Schalter (FS20 und X10)
- Alle Dimmer (FS20 und X10)
- Alle Thermometer-/Hygrometer-Kombinationen (S555TH, HMS100TF, Teil von
KS300)

Das lohnt sich und die Arbeit steckt gerade bei den Interfaces auf der
fhem-Seite nur in einer wohldurchdachten Struktur. Wieviel Aufwand in
pgm3 dann reinzustecken ist, kann ich nicht sagen.

Viele Grüße,
Boris

[Martin Haas]

Hallo Boris,

On 23 Mai, 16:23, "Dr. Boris Neubert" <om...@online.de> wrote:
> Das lohnt sich und die Arbeit steckt gerade bei den Interfaces auf der
> fhem-Seite nur in einer wohldurchdachten Struktur. Wieviel Aufwand in
> pgm3 dann reinzustecken ist, kann ich nicht sagen.

das hört sich alles sehr vielversprechend an. Natürlich wird dann auch
pgm3 die Struktur übernehmen um möglichst viel generisch ermitteln zu
können. Die Möglichkeit in pgm3 mit "UserDef" quasi beliebige Geräte
(oder eigene Skripte mit z.B. Rechnerauslastung) einbinden zu können,
ist ja aus der Not entstanden, dass man nicht alle Geräte automatisch
einbinden kann.
Am Rande: für Nutzer der Funktion "UserDef" in pgm3 gibt es einen
wichtigen Bugfix im CVS.

Viele Grüße,
Martin

[Dr. Boris Neubert]

Hallo,

wenn sich hier in diesem Thread bis Samstag 24:00 nicht mehr tut,
schlage ich vor, dass wir ab Sonntag ueber

E11

Die Readings werden standardisiert, indem Geraeteklassen gebildet werden
wie in DevelopmentInterfaces beschrieben. Die Definition der Interfaces
ist explizit nicht Gegenstand dieser Entscheidungsvorlage und wird
weiterentwickelt und angepasst, wie es sich bei der Entwicklung von fhem
5 ergibt.

und

E9

Verwendete Einheit:

* ergibt sich aus der Dokumentation
* ergibt sich indirekt aus der Dokumentation einer irgendwie gearteten
Interfacespezifikation (Gerät ist ein Thermometer -> es gibt ein Reading
"Temperature" und das ist immer in °C oder Celsius)
* ergibt sich aus einem expliziten Untereintrag
$defs{DeviceName}{readings}{theReading}{unit}="°C"
* ergibt sich aus Festlegung gemaess "FHEM-Standard", z.B. immer
SI-Einheiten, Temperaturen in Celsius, etc.

abstimmen. Bei E9 muesste die Entscheidung dann fuer den zweiten
Aufzaehlungspunkt ausgehen.

Gruesse,
Boris

[Dr. Boris Neubert]

Hallo,

der Link zur Abstimmung ueber die Entscheidungsvorlagen zur
Klassifizierung der Attribute in fhem (siehe
http://fhemwiki.de/index.php/DevelopmentGuidelines) wurde an die
Entwickler versendet.

E11: ja/nein

Readings werden standardisiert, indem Geraeteklassen gebildet werden wie

in DevelopmentInterfaces beschrieben. Genaue Def. der Interfaces ist
nicht Gegenstand dieser Entscheidungsvorlage.

E9: fuer eins entscheiden

Verwendete Einheit:
* ergibt sich aus Doku
* ergibt sich Interfacespezifikation
* ergibt sich aus expliziten Untereintrag

$defs{DeviceName}{readings}{theReading}{unit}="°C"

* ergibt sich aus "FHEM-Standard"

Die Abstimmung laeuft bis Freitag, 18.06.2010, 12 Uhr.

Eine Entscheidung gilt als angenommen, wenn es mehr Ja- als Nein-Stimmen
gibt.

An der Abstimmung nehmen die auf
http://fhemwiki.de/index.php/FHEM_authors gelisteten Entwickler teil.

Viele Gruesse,
Boris

[Dr. Boris Neubert]

Dr. Boris Neubert schrieb:

> E11: ja/nein
>
> Readings werden standardisiert, indem Geraeteklassen gebildet werden wie
> in DevelopmentInterfaces beschrieben. Genaue Def. der Interfaces ist
> nicht Gegenstand dieser Entscheidungsvorlage.
>
> E9: fuer eins entscheiden
>
> Verwendete Einheit:
> * ergibt sich aus Doku
> * ergibt sich Interfacespezifikation
> * ergibt sich aus expliziten Untereintrag
> $defs{DeviceName}{readings}{theReading}{unit}="°C"
> * ergibt sich aus "FHEM-Standard"

Die Entscheidungen gingen wie folgt aus:
E11: 3 ja, 0 nein
E9: 3 fuer "Einheit ergibt sich aus Interfacespezifikation", jeweils 0
fuer die anderen.

Die Dokumentation in http://fhemwiki.de/index.php/DevelopmentGuidelines
ist aktualisiert.

Ein Blick auf die ebenfalls aktualisierte Seite
http://fhemwiki.de/index.php/DevelopmentOpenIssues zeigt, dass nun nur
noch wenig Punkte offen sind, die geklaert werden sollten, bevor wir mit
fhem 5.x anfangen.

Gruesse,
Boris