[FHEM-devel] Attribute vs. Internals

[Dr. Boris Neubert]

Hallo,

im Zusammenhang mit den verschiedenen Behaeltern readings, helper und
fhem ist mir nicht klar, wo die Abgrenzung zwischen Attributen und
Internals liegt.

Attribute:
* follow-on-for-timer (bei FS20)
* room (bei allem)
* rainadjustment (bei KS300)

Internals:
* model (bei X10)
* loglevel

Nach welchen Kriterien wird zwischen Attributen und Internals
unterschieden?

Viele 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]

> im Zusammenhang mit den verschiedenen Behaeltern readings, helper und
> fhem ist mir nicht klar, wo die Abgrenzung zwischen Attributen und
> Internals liegt.

Internal ist alles was fhem bzw. das Modul anlegt (, Attribut ist das was der
Benutzer (optional) definiert..

> Internals:
> * model (bei X10)
> * loglevel

Huch. Wo sieht man das denn?

[Dr. Boris Neubert]

Am 09.05.2010 17:36, schrieb Rudolf Koenig:
>> im Zusammenhang mit den verschiedenen Behaeltern readings, helper und
>> fhem ist mir nicht klar, wo die Abgrenzung zwischen Attributen und
>> Internals liegt.
>
> Internal ist alles was fhem bzw. das Modul anlegt (, Attribut ist das was der
> Benutzer (optional) definiert..

Ist allein die Optionalitaet das Unterscheidungsmerkmal? Wie ist es dann
um die optionalen Parameter im define-Statement bestellt?

> Huch. Wo sieht man das denn?

Bei X10 gibt es model und MODEL und wird benutzt, um zwischen dimmbaren
und nicht dimmbaren Geraeten zu unterscheiden.

In xmllist gibt es zu jedem Element ein attrs-Attribut. Beispiele
(loglevel bei at):
* FileLog: attrs="room comment alias disable:0,1 logtype nrarchive
archivedir archivecmd"
* at: attrs="room comment alias disable:0,1 skip_next:0,1
loglevel:0,1,2,3,4,5,6"
* X10: attrs="room comment alias IODev do_not_notify:1,0 dummy:1,0
showtime:1,0 model:lm12,lm15,am12,tm13 loglevel:0,1,2,3,4,5,6">

Gruesse,
Boris

[Rudolf Koenig]

> Ist allein die Optionalitaet das Unterscheidungsmerkmal? Wie ist es dann
> um die optionalen Parameter im define-Statement bestellt?

Ganz eindeutig ist die Sache nicht, denn manche define Parameter sind optional,
und man kann define parameter mit "modify" aendern. Insofern koennte man
theoretisch einen der beiden Verfahren (modify vs. attribute) abloesen obwohl
ich erstmal dagegen bin. Man sollte eher ein Gefuehl (d.h. Regelwerk)
entwickeln, was als Attribut und was als define Parameter zugelassen ist.

> Bei X10 gibt es model und MODEL und wird benutzt, um zwischen dimmbaren
> und nicht dimmbaren Geraeten zu unterscheiden.

Das Problem ist, manche Protokolle kriegen das Modell raus, und manche nicht.
Jetzt stellt sich die Frage, ob ein Modul das als interne Daten fuehrt, oder
Attribute setzen darf, und diese zu aendern dem User dann untersagt wird.

[Dr. Boris Neubert]

Damit wir uns an konkreten Attributen festhalten koennen, habe ich mal
in http://fhemwiki.de/index.php/DevelopmentOpenIssues die
Listen aus Martins Nachricht in fhem-users eingefuegt, in der er einen
sehr umfassenden Ueberblick ueber Readings, Internals etc. gab.

Am 10.05.2010 09:57, schrieb Rudolf Koenig:
> ich erstmal dagegen bin. Man sollte eher ein Gefuehl (d.h.
> Regelwerk) entwickeln, was als Attribut und was als define Parameter
> zugelassen ist.

1. Idee: define-Parameter duerfen nachtraeglich nicht geaendert werden,
auch wenn es sich um optionale Parameter handelt => nicht-modifizierbare
Internals

Begruendungen:
- define-Parameter sind elementar fuer den Betrieb des Geraetes und
koennen nicht sinnvoll zur Programmlaufzeit geaendert werden (z.B.
Hauskode bei X10, FHTId bei FHT80b)
- Aus den define-Parametern werden bei der Initialisierung des Geraets
weitere Helper und Internals abgeleitet und gespeichert. Eine
nachtraegliche Aenderung zieht Aenderungen der Helper und Internals nach
sich mit ggf. schwer durchschaubaren Nebeneffekten (z.B. corr1..corr4
bei EM, rainadjustment bei KS300)

2. Idee: Attribute enthalten Werte, die ohne Nebeneffekte zur Laufzeit
geaendert werden koennen, weil sie z.B. ad-hoc ausgewertet werden.
- follow-on-for-timer
- retrycount
- lazy

3. Idee: Attribute beinhalten geraeteunabhaengige Meta-Informationen:
- room
- defaultReading


Gruesse,
Boris

[Rudolf Koenig]

Die Diskussion ist losgegangen, weil 1wire "model" als "internal" speichert,
FS20 als Attribut, und wir fanden das irgendwie nicht richtig.

Vorschlag, nach etwas Nachdenken:
- beim FS20 bleibt, wie es ist, also model als Attribut, was Auswirkung auf die
moeglichen set Befehle hat.
- 1wire setzt nach define das model Attribut, laesst aber eine Aenderung nicht
zu, oder wenn doch, dann muss sich dementsprechend verhalten, es macht ja
evtl. Sinn es zu aendern. Was machbar ist, entscheidet der Modul-Author.
Damit ist "model" immer ein Attribut.

> Begruendungen:
> - define-Parameter sind elementar fuer den Betrieb des Geraetes und
> koennen nicht sinnvoll zur Programmlaufzeit geaendert werden (z.B.
> Hauskode bei X10, FHTId bei FHT80b)

Aber wenn ich z.Bsp mein FHT/X10 austausche, dann will ich es doch nicht
loeschen...

> - Aus den define-Parametern werden bei der Initialisierung des Geraets
> weitere Helper und Internals abgeleitet und gespeichert. Eine
> nachtraegliche Aenderung zieht Aenderungen der Helper und Internals nach
> sich mit ggf. schwer durchschaubaren Nebeneffekten (z.B. corr1..corr4
> bei EM, rainadjustment bei KS300)

Es stimmt, dass ein modify in so einem Fall wahrscheinlich nicht perfekt
ist, da es z.Bsp. die alten logfiles nicht durchackern wird. Mit delete/define
wird der Benutzer nicht erwarten koennen, dass fhem die Logfiles modifiziert.

Ich finde modify sollte trotzdem bleiben, und in diesem Fall eine Warnung
zurueckgeben.


Idee 2 und 3 finde ich eigentlich gut, aber danach muesste
attr my_at disabled
doch zu Definition gehoeren. Und "skip_next" auch.

Es faellt mir z.Zt keine gute Alternative ein.

[Dr. Boris Neubert]

Hallo,

ich habe den Stand der Diskussion dokumentiert. Da wir hier noch keine
ueberzeugende Loesung haben, stelle ich den Punkt nicht zur Abstimmung.
Fazit: es bleibt bzgl. Attributen vs. Internals im wesentlichen alles
wie bei fhem 4.x und der Modulautor entscheidet, was ein Internal und
was ein Attribut ist.

Gruesse,
Boris