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 (https://forum.fhem.de/index.php/topic,45553) 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
Bitte einen sprechenderen Namen zu waehlen, wie defaultAttributes, deviceGroup, usw.
Bezieht sich das nur auf den Modul- oder auch auf die Attributnamen?
Ich meinte den Modulnamen: default ist mir viel zu generisch.
Was ist mit archetype oder roleModel?
Das ist eher das andere Extrem: kann darunter nichts vorstellen.
Aber von mir aus gerne :)
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
- 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
- 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
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 ;D
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!
Zitat von: vbs am 18 Juni 2016, 12:34:45
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 ;D
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.
Zitat von: vbs am 18 Juni 2016, 12:34:45
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.
Zitat von: vbs am 18 Juni 2016, 12:34:45
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.
Zitat von: vbs am 18 Juni 2016, 12:34:45
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 (https://forum.fhem.de/index.php/topic,26479.msg195105.html#msg195105))
Zusammengefasst: Erben werden verändert, Beziehungen erzeugen Erben. Dabei sollte ein Erbe jeweils nur einem archetype zugeordnet werden.
Zitat von: vbs am 18 Juni 2016, 12:34:45
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.
Zitat von: vbs am 18 Juni 2016, 12:34:45
Wenn ich nun devStateIcon für die Erben setzen möchte, dann setze ich das Attribut einfach einmalig auf dem archetype, richtig?
korrekt
Zitat von: vbs am 18 Juni 2016, 12:34:45
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
[...]
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.
Zitat von: vbs am 18 Juni 2016, 12:34:45
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
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!
Zitat von: vbs am 18 Juni 2016, 16:19:56
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.
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?
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:
attr sys_archLed attributes defaultRamp webCmd widgetOverride group icon
Und nun würde ich den Wert verändern wollen für defaultRamp:
attr sys_archLed defaultRamp 1.2
Das wird dann jedoch mit einem Fehler quittiert:
sys_archLed: unknown attribute defaultRamp. Type 'attr sys_archLed ?' for a detailed list.
Hättest du einen Tip, was ich da falsch mache? Danke!
Zitat von: vbs am 09 Juli 2016, 14:21:28
Kann ich es hinbekommen, dass das archetype-Device in der Gruppe "Archetypen" ist und ich trotzdem alle Erben auf Gruppe "Licht" setzen kann?
Ja, das geht, dazu benötigst du ein MetaArchetype. Hier der Auszug aus der commandref:
Define
define <name> archetype derive attributes
Wird in der DEF "derive attributes" angegeben handelt es sich um ein besonderes archetype. Es leitet Attribute anhand eines Musters ab:
attr <inheritor> alias <room>: <description> [<index>] [<suffix>]
attr <inheritor> group <actualGroup>
Als Erben werden alle Geräte aufgelistet welche die Attribute room oder captionRoom und description, oder das Attribut actualGroup besitzen.
Set
derive attributes
Der Befehl ist nur bei einem archetype mit der DEF "derive attributes" möglich.
Leitet für alle Erben die Attribute alias und group ab.
Dann kannst du deinem archLed das Attribut actualGroup hinzufügen. Hier wird allerdings ein Perl Ausdruck erwartet also in deinem Fall {"Licht"}
actualGroup {<perl code>}
Sofern ein archetype mit der DEF "derive attributes" definiert ist ersetzt die Rückgabe des perl code den Wert des Attributes group beim ableiten.
Zitat von: vbs am 10 Juli 2016, 11:19:01
Hättest du einen Tip, was ich da falsch mache? Danke!
Hast du dem archetype das Attribut als userattr hinzugefügt? Dies ist notwendig.
Es kommt aber auch meine ToDo-Liste, dass alle attribute die in attributes aufgeführt sind als Attribute für das archetype zur Verfügung stehen.
Danke für die Antwort! Die Geschichte mit dem userattr verstehe ich und funktioniert.
Das erste jedoch ist nicht so mein Fall, ehrlich gesagt. Wenn ich es richtig verstehe, dann ist das ja eine ziemlich andere Logik ggü. dem "normalen" archetype. Werde wohl erstmal bei der normalen Variante bleiben und group und room per Hand setzen.
Zitat von: vbs am 12 Juli 2016, 20:24:29
Das erste jedoch ist nicht so mein Fall, ehrlich gesagt. Wenn ich es richtig verstehe, dann ist das ja eine ziemlich andere Logik ggü. dem "normalen" archetype. Werde wohl erstmal bei der normalen Variante bleiben und group und room per Hand setzen.
Ja, das verhält sich volkommen anders. Wenn ich nächsten Monat wieder mehr Zeit habe versuche ich das ganze man verständlicher zu umschreiben.
So, nun habe ich wieder mehr Zeit mich dem Projekt hier zu widmen.
@vbs: wie kommst du bisher mit dem Modul zurecht?
Hi! Eigentlich hat sich da nicht viel verändert. Finde das Modul nach wie vor super!
Das einzige, was sich für mich etwas seltsam anfühlt, ist das (oben schon erwähnte) Verhalten mit den "doppelt-überladenen" Attributen wie group und room. Hat auf jeden Fall trotzdem FHEM für mich wesentlich besser wartbar gemacht. Ich konnte echt gar nicht mehr überblicken, ob meine ca. 10 HM-Dimmer wirklich identisch konfiguriert waren usw.. Also danke nochmals!
- clean und clean check als Befehle implementiert um alle archetype auf einmal zu überprüfen
- 'delete attributes' als Attribut hinzufügen
Aktuelle Version im Startpost
ToDo:
- englische CommandRef schreiben
- 'initialize device' als spezielle DEF implementieren um devices nach dem Anlegen zu initialisieren und indexieren
- Muster für derive attributes im archetype konfigurierbar machen
- "PERL WARNING: main::CommandClean() called too early to check prototype" beim Neustart behoben
Aktuelle Version im Startpost
ToDo:
- englische CommandRef schreiben
- 'initialize device' als spezielle DEF implementieren um devices nach dem Anlegen zu initialisieren und indexieren
- Muster für derive attributes im archetype konfigurierbar machen
- nonBlocking
Ich wollte das Modul nun noch mal Überprüfen und dann einchecken.
Gibt es noch Anmerkungen von den Benutzern?
Ich habe mich mal durch den ersten Beitrag gekämpft und eigentlich gar nichts verstanden... Irgendwann kam ich dann beim ersten Beitrag von vbs an und glaube jetzt zumindest mal ansatzweise zu verstehen wofür das Modul gut sein soll. Um sicher zu gehen, formuliere ich das noch mal in DAU Sprache. Bitte korrigiere mich wenn ich kauf dem Holzweg bin.
Das Modul kann dazu verwendet werden, um Attribute mehrerer Geräte zu synchronisieren. Sinnvoller Weise z.B. bei Geräten des selben Typs. Wenn ich z.b. 5 Pflanzensensoren hätte und diese in FHEM eingebunden wären, dann könnte ich mit diesem Modul hier dafür sorgen, dass bestimmte Attribute in all diesen Geräten in einem Rutsch geändert werden können (Synchronisation oder Batch Modus). Beispiel (pseudo code):
define device1, device2, device3, device4 und device5
define xyz archetype device1 device2 device3 device4 device5
set xyz synchronisation der attribute attribut1, attribut2 und attribut3
Wenn ich jetzt attribut1 im device1 ändere, dann werden diese Änderungen an das attribut1 der devices2-5 durch das Modul automatisch übertragen und ich muss das nicht manuell in den 4 anderen Modulen nachpflegen. Richtig?
Falls ja, dann würde ich von einer Attribut Synchronisation, einem Batch Modus für Attribute oder Attribut Mirror reden, wobei mir die ersten beiden Varianten am besten gefallen und ich sofort verstanden hätte was dein Modul eigentlich macht.
Im ersten Beitrag fehlt definitiv ein einfaches Beispiel, um die Funktionsweise oder den Sinn des Moduls zu verstehen. Ich mache das und dann passiert dies.
Zitat von: mumpitzstuff am 06 Mai 2017, 23:35:26
Wenn ich jetzt attribut1 im device1 ändere, dann werden diese Änderungen an das attribut1 der devices2-5 durch das Modul automatisch übertragen und ich muss das nicht manuell in den 4 anderen Modulen nachpflegen. Richtig?
Falsch. Das archetype gibt die Attribute vor. Wenn du das Attribut im archetype änderst wird es auf die devices 1-5 automatisch übertragen.
Zitat von: mumpitzstuff am 06 Mai 2017, 23:35:26
Im ersten Beitrag fehlt definitiv ein einfaches Beispiel, um die Funktionsweise oder den Sinn des Moduls zu verstehen. Ich mache das und dann passiert dies.
Das Attribute vererben ist ja nur eine Sache. Eigentlich hatte ich gehofft, dass der Einleitungssatz das Beschreibt was das Modul kann.
Zitat
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.
Nämlich
1. Attribute vom archetype auf andere Geräte übertragen
2. neue Geräte nach einem bestimmten Muster anlegen und initialisieren
Okay aber vom Grundsatz her war es schon richtig. Ich würde das Modul trotzdem AttributSync oder so nennen und Begriffe wie Archetype und Vererbung aus der Beschreibung streichen. Ist aber nur meine persönliche Meinung.
Das Modul macht insbesondere bei größeren Installationen durchaus Sinn.
Zitat von: mumpitzstuff am 07 Mai 2017, 11:01:43
Okay aber vom Grundsatz her war es schon richtig. Ich würde das Modul trotzdem AttributSync oder so nennen und Begriffe wie Archetype und Vererbung aus der Beschreibung streichen. Ist aber nur meine persönliche Meinung.
Aber AttributeSync würde dann ja nur den ersten Teil des Moduls beschreiben.
Archetype bedeutet ja so viel wie Vorbild, Urbild und Beschreibt es meiner Meinung nach ganz gut. Ursprünglich sollte das Modul ja default heißen.
Vererbung scheint auch der passende Ausdruch zu sein. Siehe Vererbung (Programmierung) (https://de.wikipedia.org/wiki/Vererbung_%28Programmierung%29)
Zitat von: mumpitzstuff am 07 Mai 2017, 11:01:43
Das Modul macht insbesondere bei größeren Installationen durchaus Sinn.
Genau dafür habe ich es ja geschrieben. Wir setzen FHEM auch bei uns in der Firma ein und da sind es schon ein paar hundert Aktoren.
Zitat von: igami am 04 Mai 2017, 19:08:12
Ich wollte das Modul nun noch mal Überprüfen und dann einchecken.
Gibt es noch Anmerkungen von den Benutzern?
Bin grad dabei die commandref zu schreiben und werde es dann nächstes Wochenende einchecken nachdem ich die neue Version getestet habe.
Mich würde ja mal interessieren bei wie vielen Installationen das Modul benutzt wird :)
Ich benutze es, aber vermutlich nur einen kleinen Teil des Funktionsumfanges.... :D
Habe das Modul nun erstmal zu contrib hinzugefügt.
Bei mir zu Hause funktioniert es. Ich möchte es aber erst noch auf anderen Installationen testen.
Bei den Attributen haben sich vorallem actual Attribute verändert:
Zitat von: Commandref
actual_<attribute> <value>
<value> kann als <Text> oder als {perl code} angegeben werden.
Wir das Attribut <attribute> vererbt, ersetz die Rückgabe des actual_<attribute> Wert des Attributes.
Bei dem archetype mit der DEF "derive attributes" können Muster definiert werden.
Beispiel: actual_alias %captionRoom|room%: %description%[ %index%][%suffix%]
Alle in % eingeschlossenen Ausdrücke sind Attribute. Eine Reihenfolge lässt sich durch | erreichen. Ist ein Ausdruck in [] eingeschlossen ist er optional.
Die Ausdrücke captionRoom, description, index und suffix sind hierbei durch addToAttrList hinzugefügte Attribute.
Gerade was die Commandref angeht könnte ich noch Hilfe benötigen. Ich weiß ja was es tut und wie man das einstellen muss, kann das aber schlecht beschreiben :-[
Also die, die das Benutzen einfach Feedback geben :)
Gerade erst darauf gestoßen und werd mir das Modul mal anschauen ... was ich auf jeden Fall verbessern würde, wäre das "Marketing". Ich hab sowas tatsächlich schon ewig gesucht.
Ich glaube, wenn du das - Vorschlag - in "deviceTemplate" umtaufst, würden es allein wegen des Namens viel mehr nutzen, auch wenn es eigentlich kein Template im engeren Sinne ist (aber im weiteren Sinne eigentlich ja doch). deviceClass wäre vielleicht auch noch ein treffender Name. Da kann man sich dann nämlich was drunter vorstellen ;)
Anfangs wollte ich es ja mal default nennen, durfte ich aber nicht :D
deviceTemplate würde ich jetzt auch ablehnen, da es template schon gibt
Wenn ich es jetzt noch mal umbenenne muss ich bei mir ja auch alles ändern :D
Hi,
ich wollte gerade auf die aktuelle Version von archetype updaten und erhalte folgendes:
Can't use a hash as a reference at ./FHEM/98_archetype.pm line 318.
Meine Perl-Version ist v5.22.3.
Wenn ich fitter in perl wäre, würde ich Dir einen Patch schicken, bin ich aber nicht, so bin ich auf Deine Hilfe angewiesen ;).
Edit:
Na vermutlich sieht der Fix so aus:
diff --git a/fhem/contrib/98_archetype.pm b/fhem/contrib/98_archetype.pm
index cd9dde3..f69cb37 100755
--- a/fhem/contrib/98_archetype.pm
+++ b/fhem/contrib/98_archetype.pm
@@ -315,7 +315,7 @@ sub archetype_Get($@) {
return(
"Unknown argument $value, choose one of "
- . join(" ", split(",", (split(":", %archetype_gets->{$argument}))[1]))
+ . join(" ", split(",", (split(":", $archetype_gets{$argument}))[1]))
);
}
}
LG
Christian
Das tauchte auch tatsächlich öfter bei mir als Warnung auf, ich habe es nur schlicht übersehen :D
Ich würde das Modul dann zu morgen unter dem Namen archetype einchecken. Der Duden gibt dazu als Synonyme an:
Urbild, Urform, Urgestalt, Urtyp
Ideal, Inbegriff, Musterbild, Vorbild
;)
Mist, 5 Minuten zu spät eingechekt, dann eben ab morgen :)
Du solltest vielleicht das gleichnamige Modul aus contrib entfernen, um Verwirrungen zu vermeiden.
Ich habe es über mv von contrib nach FHEM verschoben, muss ich noch weiteres machen?
Edit: Habs schon rausgefunden: svn delete :-[
Moin.
In Ordnung in mein fhem zu bekommen, habe ich mich jetzt auch mal an archetype gemacht.
Klappt auch soweit ganz gut.
Was mir noch nicht klar ist, gibt es Situationen, in denen ein archetype triggert?
Ideal wäre (für mich) wenn die Attribute ja auch auf neue devices übertragen werden.
Wobei neu bei mir zu 99% ein rename eines (neuen) MQTT2 devices heisst.
Ansonsten könnte ich ja nach dem rename ein clean machen das sollte ja dann alle triggern.
In der cref ist noch ein kleiner typo bei deleteAttributes.
Gruss
Maui