neues Modul 98_archetype

[igami]

Mit einem archetype werden Attribute auf andere Geräte, Erben (inheritors), übertragen. Die Erben können, nach einem vorgegeben Muster im archetype und für eine bestimmte Gruppe von Geräten, Beziehungen (relations), definiert werden.

archetype ist seit dem 02. Juli 2017 ofizieller Bestandteil von FHEM

Originalbeitrag

Hallo zusammen,

in anlehnung an meine 99_cleanUtils wage ich mich nun daran ein Modul zu schreiben.

Mit einem archetype werden Attribute auf andere Geräte, Erben (inheritors), übertragen. Die Erben können, nach einem vorgegeben Muster im archetype und für eine bestimmte Gruppe von Geräten, Beziehungen (relations), definiert werden.

Im Modul ist eine deutsche CommandRef enthalten.

Über Fragen und Anregungen freue ich mich.

Grüße
igami

[rudolfkoenig]

Bitte einen sprechenderen Namen zu waehlen, wie defaultAttributes, deviceGroup, usw.

[igami]

Bezieht sich das nur auf den Modul- oder auch auf die Attributnamen?

[rudolfkoenig]

Ich meinte den Modulnamen: default ist mir viel zu generisch.

[igami]

Was ist mit archetype oder roleModel?

[rudolfkoenig]

Das ist eher das andere Extrem: kann darunter nichts vorstellen.
Aber von mir aus gerne

[igami]

Log3 hinzugefügt.

Aktuelle Version im Startpost.

ToDo:
- englische CommandRef schreiben
- metaNAME, metaDEF, initialize um {} erweitern um zwischen Perl-Code und FHEM beim eval zu unterscheiden
- bei get pending inheritors überprüfen ob metaDEF einen Wert zurückgibt und nicht nur ob metaNAME einen Wert zurückgibt
- 'derive attributes' als spezielle DEF implementieren um den alias nach dem Muster <room>: <description> [<index>] [<suffix>] abzuleiten
- 'initialize device' als spezielle DEF implementieren um devices nach dem Anlegen zu initialisieren und indexieren
- actualGroup als Attribut hinzufügen
- clean und clean check als Befehle implementieren um alle archetype auf einmal zu überprüfen

[igami]

- bei get pending inheritors überprüfen ob metaDEF einen Wert zurückgibt und nicht nur ob metaNAME einen Wert zurückgibt
- 'derive attributes' als spezielle DEF implementieren um den alias nach dem Muster <room>: <description> [<index>] [<suffix>] abzuleiten
- actualGroup, captionRoom als Attribute hinzugefügt
- CommandRef erweitert

Aktuelle Version im Startpost

ToDo:
- englische CommandRef schreiben
- metaNAME, metaDEF, initialize um {} erweitern um zwischen Perl-Code und FHEM beim eval zu unterscheiden
- 'initialize device' als spezielle DEF implementieren um devices nach dem Anlegen zu initialisieren und indexieren
- clean und clean check als Befehle implementieren um alle archetype auf einmal zu überprüfen
- für ein archetype mit der DEF "derive attributes" die Befehle "set <archetype> derive attributes" und "get <archetype> pending attributes" implementieren
- Muster für derive attributes im archetype konfigurierbar machen

[igami]

- metaNAME, metaDEF, initialize um {} erweitert um zwischen Perl-Code und FHEM beim eval zu unterscheiden
- für ein archetype mit der DEF "derive attributes" die Befehle "set <archetype> derive attributes" und "get <archetype> pending attributes" implementiert
- splitRooms als Attribut hinzugefügt
- CommandRef erweitert

Aktuelle Version im Startpost

ToDo:
- englische CommandRef schreiben
- 'initialize device' als spezielle DEF implementieren um devices nach dem Anlegen zu initialisieren und indexieren
- clean und clean check als Befehle implementieren um alle archetype auf einmal zu überprüfen
- Muster für derive attributes im archetype konfigurierbar machen
- 'delete attributes' als Attribut hinzufügen

[vbs]

Danke für das Modul, äußerst interessant, finde die Idee super! Hat mich schon immer genervt, dass ich viele gleichartige Geräte immer per Hand "synchron" halten musste. Das hier könnte da ja die Lösung sein!

Jedoch muss ich gestehen, dass ich etwas Schwierigkeiten habe, mit dem Modul warm zu werden. Die Doku sieht zwar sehr gut aus (sogar mit Beispielen), aber mir persönlich fehlt so ein bisschen der Anfang. Es tut jetzt bei mir etwas und es werden auch Attribute in den Erben gesetzt, aber gefühlt verstehe ich eigentlich nur Bahnhof 

Ich hätte viele Fragen, aber vielleicht darf ich mal ein paar für mich grundlegende stellen in der Hoffnung, dass sich dann viele andere selbst beantworten;

• Legt das Modul selbständig Geräte an oder muss man die zunächst selbst definieren? Im define siehts aus, als würde man Geräte angeben, die es schon gibt. Später in der Doku klingt es so, als würde das Modul auch Geräte anlegen.
• In den Beispielen werden immer zunächst Attribute gesetzt und dann erst das Attribut "attribute" gesetzt. So rein intuitiv hätte ich es jetzt anders herum gemacht. Ist das wichtig?
• Es taucht öfter der Begriff "Beziehung" / relation auf. Was ist das bzw. was ist der Unterschied zwischen Erben und Beziehungen (Attribut relations)?

Oder als Beispiel:
Ich habe zwei dummys: "dummy1" und "dummy2".
Nun lege ich ein archetype an "define archetype dummy1 dummy2".
Nun möchte ich für die beiden Dummies zB "devStateIcon" immer gleichzeitig setzen. Ich mache "attr archetype attributes devStateIcon".
Wenn ich nun devStateIcon für die Erben setzen möchte, dann setze ich das Attribut einfach einmalig auf dem archetype, richtig? Also "attr archeType devStateIcon meinIcon".

Wie ist das dann zb mit dem Attribut "setList". Das archetype-Gerät selbst kennt ja von Haus aus schon das Attribut "setList". Wenn ich nun "attr archetype attributes devStateIcon setList" mache und dann "attr archetype setList on off", dann kann ich auf einmal in der Weboberfläche des archetype-Geräts unter "set" "on" und "off" wählen, obwohl setList ja eigentlich nur für die Erben gedacht war. Ist das korrekt so?

Sorry für die vielen Fragen und nochmal danke fürs Modul, ich glaub es gefällt mir gut!

[igami]

Jedoch muss ich gestehen, dass ich etwas Schwierigkeiten habe, mit dem Modul warm zu werden. Die Doku sieht zwar sehr gut aus (sogar mit Beispielen), aber mir persönlich fehlt so ein bisschen der Anfang. Es tut jetzt bei mir etwas und es werden auch Attribute in den Erben gesetzt, aber gefühlt verstehe ich eigentlich nur Bahnhof 

So ganz glücklich bin ich auch noch nicht mit der Doku. Wie rudi weiter oben geschrieben hat weiß man nicht genau was das Modul alles macht. Verbesserungen zur Formulierung oder Nachfragen wie was genau funktioniert sind daher immer wilkommen.

Legt das Modul selbständig Geräte an oder muss man die zunächst selbst definieren? Im define siehts aus, als würde man Geräte angeben, die es schon gibt. Später in der Doku klingt es so, als würde das Modul auch Geräte anlegen.

Sowohl als auch. Dazu nachher mehr.

In den Beispielen werden immer zunächst Attribute gesetzt und dann erst das Attribut "attribute" gesetzt. So rein intuitiv hätte ich es jetzt anders herum gemacht. Ist das wichtig?

Das ist nicht wichtig, hat sich bei mir nur so ergeben, dass ich erst alle Attribute vergebe und gucke wie das dann aussieht und dann ja weiß was ich nun alles verweben möchte. Wenn man es andersrum macht kann es sein, dass einem noch ein Attribut einfällt und dies dann in der Liste ergänzen muss.

Es taucht öfter der Begriff "Beziehung" / relation auf. Was ist das bzw. was ist der Unterschied zwischen Erben und Beziehungen (Attribut relations)?

Hier das oben erwähnte "nachher".
An die Erben werden die Attribute vererbt und diese werden in der DEF angegeben.  Erben sind Geräte die bereits definiert sind.
Für jede Beziehung kann ein Erbe nach einem bestimmten Muster definiert werden. In der Doku wollte ich das mit dem Beispiel des SVG beschreiben. Es wird für jedes Gerät vom TYPE SVG ein Gerät vom TYPE weblink angelegt.
Oder auch das Beispiel für die redingsGroup zum einstellen von HomeMatic Wochenprogrammen (daher kommt auch die Idee für das Modul Antw:HM-CC-RT-DN Reading Gruppe )
Zusammengefasst: Erben werden verändert, Beziehungen erzeugen Erben. Dabei sollte ein Erbe jeweils nur einem archetype zugeordnet werden.

Nun lege ich ein archetype an "define archetype dummy1 dummy2".

Hier fehlt noch der <name> aber sonst alles korrekt. Es könnte auch dummy(1|2) oder dummy[12] als DEF angegeben werden, oder eine andere devspec.

Wenn ich nun devStateIcon für die Erben setzen möchte, dann setze ich das Attribut einfach einmalig auf dem archetype, richtig?

korrekt

Wie ist das dann zb mit dem Attribut "setList". Das archetype-Gerät selbst kennt ja von Haus aus schon das Attribut "setList". Wenn ich nun "attr archetype attributes devStateIcon setList" mache und dann "attr archetype setList on off", dann kann ich auf einmal in der Weboberfläche des archetype-Geräts unter "set" "on" und "off" wählen, obwohl setList ja eigentlich nur für die Erben gedacht war. Ist das korrekt so?

Das ist so gewollt für den Fall das man Erben durch Beziehungen definiert kann man diese initialisieren. In der Doku in dem Beispiel der ReadingsGroup beschrieben

Code Auswählen Erweitern


[...]
attr climate_controlUnit_archetype initialize
    setreading $name controlMode [$SELF:controlMode];
    setreading $name dayTemp [$SELF:dayTemp];
    setreading $name nightTemp [$SELF:nightTemp];
    setreading $name program [$SELF:program];

    attr $name room $room;
[...]

Man kann dadurch die Werte bequem im archetype per klick einstellen und dann auf die Erben übertragen. Dies passiert entweder wenn die Erben definiert werden oder wenn man dies manuell durch "set <archetype> inititialize inheritors" ausführt.

Sorry für die vielen Fragen und nochmal danke fürs Modul, ich glaub es gefällt mir gut!

Dafür brauchst du nicht um Entschuldigung bitten. Ich freue mich ja über Fragen und Anregungen, dann weiß ich wo ich weiter machen muss, noch ist das Modul ja nicht fertig
Ich hoffe ich konnte dir deine Fragen verständlich beantworten.

Grüße
igami

[vbs]

Vielen Dank, ja, das hilft schon sehr! Ich muss da mal etwas mit rumspielen.
Das sollte mMn viel mehr Beachtung finden in FHEM, da es gerade die Verwaltung von vielen gleichartigen Geräten sehr vereinfacht!

[igami]

Das sollte mMn viel mehr Beachtung finden in FHEM, da es gerade die Verwaltung von vielen gleichartigen Geräten sehr vereinfacht!

Wird es ja vielleicht wenn ich es mal fertig stelle und es ofiziell eingecheckt werden kann
Leider habe ich momentan keine Zeit um es weiter zu programmieren. Wenn dir noch etwas auffällt was nicht funktioniert oder fehlt einfach Bescheid geben.

[vbs]

Modul find ich nach wie vor spitze! Ich benutze es zwar nur, um Attribute für gleichartige Gerät zu managen, aber dafür ists schon super!

Aber nochmal eine Frage (habe ich so ähnlich schonmal gefragt glaub ich, aber hab es wohl noch nicht ganz verstanden). Es geht darum, dass ich ein Attribut, welches das Archetype-Device selbst auch hat, vererben möchte:
Wenn ich dem Archetype-Device im Attribut "attributes" den String "group" hinzufüge, dann möchte ich ja für alle Erbe das group-Attribut setzen können (zB auf "Licht"). Wenn ich dann also "attr devArchetype group Licht" mache, dann wird für alle Erben "group" auf "Licht" gesetzt, korrekt. Jedoch ist dann natürlich das archetype-Device selbst auch in der Gruppe "Licht".
Kann ich es hinbekommen, dass das archetype-Device in der Gruppe "Archetypen" ist und ich trotzdem alle Erben auf Gruppe "Licht" setzen kann?

[vbs]

Ich hab leider noch eine Anschlussfrage:

Ich möchte bei allen Erben das Attribut "defaultRamp" setzen. Also habe ich bei meinem archetype-Device, "attributes" so gesetzt:

Code Auswählen Erweitern

attr sys_archLed attributes defaultRamp webCmd widgetOverride group icon

Und nun würde ich den Wert verändern wollen für defaultRamp:

Code Auswählen Erweitern

attr sys_archLed defaultRamp 1.2

Das wird dann jedoch mit einem Fehler quittiert:

Code Auswählen Erweitern

sys_archLed: unknown attribute defaultRamp. Type 'attr sys_archLed ?' for a detailed list.

Hättest du einen Tip, was ich da falsch mache? Danke!