[archetype] - support Thread ab 2022

[Beta-User]

Hallo zusammen,

wie ihr vielleicht mitbekommen habt, kann  der Erfinder von archetype - igami - die Pflege seiner Module nicht weiter übernehmen. Auch an dieser Stelle nochmal ein fettes "Dankeschön" an igami für seinen langjährigen und konstruktiven Einsatz für FHEM!

Da man mit dem Modul nach meinem Verständnis "Standardkonfigurationen" an viele/mehrere Geräte verteilen kann (und: diese im laufenden Betrieb überwachen bzw. zentral ändern kann), scheint eine gewisse Nähe zu attrTemplate zu bestehen. Daher habe ich mich übergangsweise bereit erklärt, das zu übernehmen.

Irgendwelche Kenntnisse im Modul dürft ihr (noch) nicht erwarten, und ich wäre ausgesprochen froh, wenn mir (mind.) einer derjenigen, die das heute im Einsatz haben, eine gewisse Starthilfe geben könnte, wie man das Modul im einzelnen nutzen kann - aus der commandref und den wenigen vorhandenen Beiträgen dazu bin ich jedenfalls bisher  nicht so recht schlau geworden.
Als erste Aktion wird es nachher ein update geben, das die commandref auf "id" umstellt, so dass die Hilfetexte auch direkt bei den set/get-Befehlen und den Attributen angezeigt werden - nix großes, aber m.E. grundsätzlich hilfreich.

Wer Fragen oder Anregungen (v.a. auch zur commandref) hat, möge diese bitte hier platzieren und/oder für "spezielle Themen" auf separate Threads ausweichen. 
Wer die Pflege stattdessen lieber selbst (statt meiner oder ergänzend) übernehmen möchte, darf sich selbstredend melden.

Weitere Pläne und Gedanken:
Falls ich dann dazu komme, wird es ggf. gepackaged (in dem Zuge werde ich auch den Code mal intensiver ansehen). Eventuell kann man das so erweitern, dass darüber feststell- und anzeigbar wird, wenn es Änderungen am attrTemplate gab, das der aktuellen Konfiguration zugrunde liegt. (Bis dahin wird es aber sicher noch lange dauern!)

Soviel erst mal für's erste,

Beta-User

Hinweis: mit dem Befehl "template" (https://fhem.de/commandref_modular_DE.html#template) gibt es noch eine Variante, die ggf. in diesem Gesamtzusammenhang für den einen oder anderen interessant sein kann.

EDIT: Für's leichtere Wiederfinden bis auf weiteres die aktuelle Entwicklerversion anbei.

[Beta-User]

So, hier also mal eine erste Lautmeldung und gleich eine Ladung Fragezeichen...

Um in das Thema reinzukommen, lag es recht nahe, mal ein "typisches Problem" aufzugreifen - CUL_HM wirft (mir) zu viele Events, und neue Devices brauchen (bei VCCU-Nutzung) auch alle ein Attribut IOgrp.

Also erst mal eine devspec für die Haputkanäle genommen und flugs gestartet mit:

Code Auswählen Erweitern

define archHM1 archetype TYPE=CUL_HM:FILTER=DEF=.{6}
Als erstes sollen zwei Attribute überwacht werden, "commStInCh" und "IOgrp" - also

Code Auswählen Erweitern

attr archHM1 attributes commStInCh IOgrpUm die zu setzen, muss die archetype-Instanz ggf. diese Attribute erst lernen, daher:

Code Auswählen Erweitern

attr archHM1 userattr commStInCh IOgrp
Wer den angehängten Code nutzt wird feststellen, dass archetype das erforderlichenfalls jetzt gleich anlegt, wenn man "attributes" setzt.

Nach

Code Auswählen Erweitern

attr archHM1 IOgrp undef:VCCU
attr archHM1 commStInCh undef:off

(vorhandene speziellere Werte sollen nicht überschrieben werden, daher der "undef"-Präfix) zeigt ein "get archHM1pending attributes" an, wo es noch hakt, "set archHM1 inheritance" setzt dann die Attribute, wo sie noch fehlen.

Weil's so schön ist, noch

Code Auswählen Erweitern

attr archHM1 autocreate 1
gesetzt und mal ein CUL_HM-Gerät definiert => Attribute sind direkt vorhanden .
EDIT: autocreate 1 ist der default, muss man nicht extra setzen...

Bis dahin: sehr schön  . (auch, weil  bis dahin anscheinend erst mal nichts wesentliches zerstört worden ist ).

Nach dem "Appetizer" der Status- und Frageteil:
Lt. Statistik gibt es derzeit ca. "offizielle" 13 Nutzer des Moduls mit ~10 Instanzen/Installation.

Wenn ich die Rückmeldungen aus den wenigen vorhandenen Threads richtig deute, ist kaum einer über diese oben dargestellte "Basisnutzung" (evtl. noch mit dem erweiterten "Weblink"-Beispiel) hinausgekommen? Oder übersehe ich irgendwo was wesentliches? Gibt es doch irgendwo einen Thread, der etwas aufschlussreicher ist wie der "neues Modul"-Thread? Gibt es Installationen, die deutlich komplexere (Perl-) settings haben?!? (Da scheint ja einiges möglich zu sein, und bevor versehentlich was kaputt geht, wären Testmöglichkeiten hilfreich...)

Zum Praktischen:

Dabei sollte ein Erbe jeweils nur einem archetype zugeordnet werden

Mein Beispiel setzt zwei recht spezifische Module. An sich hätte ich jetzt keine gedanklichen Probleme, einen "archHM2" anzulegen, der was ganz anderes macht (z.B. event-on-.*-Attribute zu verteilen). Der müßte dann aber deutlich differenzierter ausfallen (und vermutlich recht komplexen Perl-Code enthalten). Wichtig scheint mir im Ergebnis v.a., dass die sich nicht widersprechen, aber sonst?

Und:

Vorab würde mich interessieren, ob triftige Gründe dagegen sprechen würden, den command in "archetype" umzubenennen und für die Ausführung ein explizites "clean" zu verlangen? (also künftig: "archetype clean" oder "archetype check")

(Hinweis: Die angehängte Version arbeitet bereits mit den neuen Befehlen).

Hintergrund dazu ist der, dass mir der Gedanke, dass ein "archetype clean" wirklich immer alles "aufräumt", ist mir noch unheimlich; bin am Überlegen, ob es ein Attribut geben sollte, mit dem man selektiv ausschalten kann, ohne ganz gleich "disable" zu verwenden.

Gab es einen Grund, warum beim Setzen der Attribute vor $init_done weiterer Code aufgerufen wurde?

Die Logik in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_archetype.pm?rev=20798#L394 ff verstehe ich (noch) nicht - folgendes habe ich veranstaltet (ac2 ist ein archetype):

Code Auswählen Erweitern

attr ac2 attributes actual_temp
ergibt

Code Auswählen Erweitern

attr ac2 attributes userattr actual_temp
Das sieht mir nicht richtig aus, userattr geht doch immer, und actual_.+ geht eigentlich auch, es ist nur nicht komfortabel zu erreichen (was aber eher ein Doku-Thema ist)...

Soviel für's erste, wäre schön, wenn mich jemand (auch zu Teilen) aufschauen könnte .

Ansonsten muss damit gerechnet werden, dass ich halt mache, was mir zweckmäßig vorkommt... (Wer Sorgen hat, sollte rechtzeitig exclude_from_update setzen!).

[Benni]

CUL_HM wirft (mir) zu viele Events

Hallo Beta-User

Genau da bin ich gerade auch dran! 

Ich habe mir den NOTIFYDEV-Thread von neulich zum Anlass genommen und mal meine eocr etwas verschärft.

Dabei kam bei mir relativ schnell der Gedanke, "das muss doch besser gehen!"

Rudimentär habe ich bei mir aktuell einige notify, die beim global:DEFINED "Vorbelegungen" für verschiedene Device-Typen übernehmen, aber so richtig schön ist das auch nicht.

Ich habe die Verfolgung von archetype zum Entstehungszeitpunkt des Moduls aufgrund des, zumindest gefühlt hohen Abstraktionsgrades und mangels Zeit, aufgegeben.

Mal sehen, was meine Zeit hergibt, aber ich werde ich mir das User-seitig (!) jetzt jedenfalls auch mal genauer anschauen und stehe in dem Rahmen natürlich gerne auch als Tester zur Verfügung!

So wird aus dem Monolog zumindest schon mal ein Dialog
Nichts desto trotz meldet sich hoffentlich noch der eine oder andere Alt-Anwender!

gb#

[Beta-User]

So wird aus dem Monolog zumindest schon mal ein Dialog

freut mich!

(Zumal ich mich dann auch trauen kann, mal die eine oder andere Frage zum Code zu stellen oder eine Zeile zwecks Test in den Raum zu werfen, selbst wenn es "nur" um eine User-Frage geht ).

Rudimentär habe ich bei mir aktuell einige notify, die beim global:DEFINED "Vorbelegungen" für verschiedene Device-Typen übernehmen, aber so richtig schön ist das auch nicht.

Überhaupt nicht vergleichbar, ich bin schon jetzt überzeugt, dass die "einfache" archetype-Variante dem deutlich überlegen ist, einfach, weil man auch im laufenden Betrieb immer wieder checken kann, ob alles noch paßt (und auch eine Art "Checkliste" hat, auf was man eigentlich achten wollte...).
Bin nur mal gespannt, wie "kompakt" man das hinbekommen kann .

@igami nochmal:
Was das Coding angeht, will ich das einpacken und auch möglichst string-evals loswerden. Das ist erfahrungsgemäß "gefahrgeneigt", und noch fehlt mir der Durchblick, wieso im Einzelnen eval verteilt wurden.
In msgDialog gab es sowas auch, es war dort aber vermutlich (!) deutlich einfacher, weil recht klar war, wo es "nur" um die Auflösung von Variablen ging (das ist lexical context abhängig) und wo wirklich der (vorbehandelte) Code ausgeführt werden soll. Vielleicht kannst du das schneller aufdröseln?

Aus:

Code Auswählen Erweitern

$msgCommand = eval($msgCommand);
fhem($msgCommand);
wird dann sowas:

Code Auswählen Erweitern


  $msgCommand  = EvalSpecials($msgCommand, %specials);
  $msgCommand =~ s{\\[\@]}{@}x;
  AnalyzeCommandChain($hash, $msgCommand);

EDIT: Geänderter Code.

Die zweite Variante geht tendenziell wohl sicherheitshalber immer nach "AnalyzeCommandChain();".

Hmm, dickeres Brett...

[Beta-User]

So, erste Korrekturen an meinen eigenen Anteilen...

Die commandref ist jetzt auch etwas umstrukturiert bzw. (de) ergänzt - mittelfristig stellt sich die Frage, ob der de-Teil nicht ins Wiki sollte, mal schauen.

Was ich noch nicht so richtig zu greifen bekommen: Zwischen "Basis" und "ganz abgefahren" (derive attributes, lt. Code nur 1x pro Installation zulässig) scheint es noch eine Zwischenstufe zu geben. Ich frage mich, ob das Beispiel mit dem weblink für SVG "alles" ist, oder ob es nicht z.B. auch dazu gedacht war, mit "initialize" und "meta.*"-Attributen sowas wie CUL_HM-Kanäle gleich mit zukonfigurieren... In diese Richtung gingen ein paar Anhänge im Ur-Ausgangs-Thread.

Auch hier wäre Nachhilfe nett ...

[Beta-User]

Nächster Schritt.

Gaaaanz langsam lichtet sich in Teilen der Nebel. Zumindest zum Start sollte man anscheinend nicht zu sehr um die Ecke denken ...

Daher hier mal zwei spezielle Aspekte:
- Zumindest nach meinem aktuellen Erkenntnisstand sind die "actual.*"-Attribute in der Doku bisher etwas unterbetont. Tatsächlich überspielen sie die "ureigenen" (bis auf den Präfix) namensgleichen Attribute des archetype als Quell-Info für's Vererben.
- ein archetype wirkt direkt auf alle neu angelegten Devices, autocreate=1 ist der Default (wie schon immer in der commandref beschrieben). (Nur) wer was anderes haben will, kann das ausschalten. Aha.

Da wir neulich die (möglicherweise sachlich völlig verfehlte) Aufgabe hier diskutiert hatten, wie man "triggere nie auf ..." umsetzt, hier mal ein entsprechendes archetype für "simple HUEDevice-Relays":

Code Auswählen Erweitern

define archHUE1 archetype TYPE=HUEDevice:FILTER=type=On.Off.light
attr archHUE1 userattr actual_event-on-change-reading actual_icon
attr archHUE1 actual_event-on-change-reading undef:(?!lastseen).*
attr archHUE1 actual_icon undef:FS20.on
attr archHUE1 actual_webCmd undef::
attr archHUE1 attributes icon alias webCmd event-on-change-reading
attr archHUE1 icon robot
Man muss also demnach eine ganze Menge zusätzlicher Attribute anlegen => ziemlich viel Handarbeit... (Bis jetzt )

Mein gedanklicher Musterablauf für das Erstellen "einfacher archetype" wäre jetzt in etwa in diese Richtung:
- Man wähle ein "gutes Device" (ein beliebiges vorhandenes, bei dem alles so ist, wie es sein soll) aus
- define xy archetype <devspec, die auch das "gute Device" umfasst>
- importiere das "gute Device" (entweder alle gesetzten Attribute oder nur eine Auswahl) in das archetype.
- bearbeite das nach
- verteile das Ergebnis an den Rest und freue sich, dass alle danach angelegten Geräte auch erst mal automatisiert ebenfalls so aussehen...

Was dazu fehlte, war eine Import-Funktion, die ist im Anhang im ersten Post jetzt enthalten und zudem einiges an der (de-) commandref geändert.
Wer das als CUL_HM-Nutzer testen will, kann z.B. folgende Basis nehmen:

Code Auswählen Erweitern

defmod archHM1 archetype TYPE=CUL_HM:FILTER=DEF=.{6}
attr archHM1 attributes commStInCh IOgrp

Dann eines der im setter "import" aufgeführten Devices nehmen (das die beiden Attribute gesetzt hat) und loslegen .

Wer mag, kann auch das "attributes"-Attribut mal löschen (oder ergänzen) und schauen, was dann alles importiert wird .

Für diese Basisfunktionalität sollte die Testversion keine Probleme verursachen, ab "initialize" und erst recht mit Perl-Code könnte es sein, dass es Schwierigkeiten bis hin zu crashes gibt. Leider habe ich bisher nirgends "Spielmaterial" gefunden, mit dem man ansatzweise hätte checken können, ob die teils massiven Umbauten weg von "eval" (im Vorgriff auf das package) ok sind.

EDIT: Ein paar interessante Links wollte ich mir auch irgendwo passend merken:
- https://forum.fhem.de/index.php/topic,68455.0.html (Templates in FHEM)
- https://forum.fhem.de/index.php/topic,53402.0.html (der seitherige Diskussionsthread zum Modul)

[Benni]

Hallo Beta-User,

Das mit der Import-Funktion ist nett: Damit wird ein existierendes device quasi zum Archetyp für den archetype

Bin gerade dabei auf meiner Testinstallation etwas mit archetype zu spielen. Allerdings erst mal nur mit Dummys. Das verteilen von Attributen funktioniert soweit ganz gut!

derive attributes habe ich noch nicht ganz verstanden. Dem Ursprungs-Thread nach kann ich damit die FHEM-Attribute für archetype-devices festlegen... schaue ich mir später noch an.

Die Empfehlung ein device nur einem archetype zuzuordnen verstehe ich zwar, zwecks Überblick. Könnte mir aber gut vorstellen, dass man hier auch sinnvoll Überschneidungen nutzen kann. Man muss eventuell aufpassen, dass man da nicht so eine Art Rekursion baut.

Wollte eben noch das Attribut Initialize testen. Aber das ist mir noch nicht gelungen. Idee war, dass bei Einem dummy mit on off setList initial off gesetzt wird.

Erster Ansatz hat nicht funktioniert und die Hilfe zum Initialize-Attribut macht leider nicht schlauer.

Code Auswählen Erweitern


defmod atTst archetype TYPE=dummy:FILTER=NAME=dmTst.*
attr atTst userattr actual_room actual_setLIst actual_setList actual_webCmd
attr atTst actual_room undef:TestDummys
attr atTst actual_setList undef:on off
attr atTst actual_webCmd undef:on:off
attr atTst attributes room setList webCmd
attr atTst autocreate 1
attr atTst initialize set $name off


... so lange bin ich jetzt aber auch noch nicht dran!

gb#

[Beta-User]

Das mit der Import-Funktion ist nett: Damit wird ein existierendes device quasi zum Archetyp für den archetype

Freut mich, wenn es als positiv wahrgenommen wird. Jedenfalls ist es genauso gedacht: Man wähle einen "Rohling" aus, "clone" ihn, verfeinere das ganze ggf. und "fertig die Laube"...

So finde ich das als "Basisfunktionalität" gut nutzbar, und man kann es auch schnell erklären...

Die Empfehlung ein device nur einem archetype zuzuordnen verstehe ich zwar, zwecks Überblick. Könnte mir aber gut vorstellen, dass man hier auch sinnvoll Überschneidungen nutzen kann. Man muss eventuell aufpassen, dass man da nicht so eine Art Rekursion baut.

Na ja, soweit es bisher implementiert ist, werden bei einem "archetype clean" halt alle Instanzen nacheinander aufgerufen, so dass ggf. dann vielleich eine Ladung widersprüchlicher Attribut-Setzungen erfolgt ist und am Ende ein oder mehrere archetype wieder anzeigen, dass was nicht passt. Solange man keine Events wirft und den Prozess wieder von vorne startet, ist damit erst mal noch nichts dramatisches passiert.

derive attributes habe ich noch nicht ganz verstanden. Dem Ursprungs-Thread nach kann ich damit die FHEM-Attribute für archetype-devices festlegen... schaue ich mir später noch an.

Bin da auch (noch) etwas ratlos, aber meinem jetzigen Bauchgefühl nach geht es in etwa darum:
- Man hat z.B. (zu einer Art "Funktionsgruppe") ein "Hauptdevice" (kann alles mögliche sein).
- Rund um das jeweilige "Hauptdevice" soll es immer wieder dieselben "Hilfsgeräte" drumrum geben (Beispiel war: SVG + weblink).
Dann geht es darum, aus den Attributen des Hauptdevice die weiteren Attribute auch für die Hilfsdevices ableiten zu können (?). Dafür braucht man aber weitere "globale" Attribute.

Der Teil wirkt irgendwie noch nicht ausgereift, was vielleicht auch erklärt, dass es (außer dem Beispiel in der commandref) keine publizierten Beispiele gibt?

Wollte eben noch das Attribut Initialize testen.

Hmm, der Blick in den Code zeigt, dass "initialize" nur im Zusammenhang mit "relations" eine Rolle spielt. Von daher dürfte es bis dahin nicht daran liegen, dass ich was kaputt gemacht habe . Auf die Schnelle bin ich aber auch beim Versuch gescheitert, dein Beispiel aufzubohren und frage mich andererseits, ob man dann nicht den Befehl nur dann anzeigen sollte, wenn relations befüllt ist? (und/oder auch gleich das betreffende Attribut?)

Vielleicht erklärt uns jemand, warum "initialize" nicht (abschaltbar?) automatisch mit dem define (unabhängig von eventuellen relations) ausgeführt wird? Auf die Schnelle fand ich diese Feststellung nämlich auch überraschend.

Notiz noch zum Thema "derive attributes":
Eigentlich fände ich es einleuchtender, wenn die global zu verstreuenden Attribute auch einen eindeutigen Präfix (vergleichbar zu "actual") hätten, aus dem erkennbar ist, dass sie Hilfsattribute für archetype sind ("archetype_.+"). Dann könnte man zum einen auch systemweit leichter einen passenden Hilfstext einblenden und/oder auch Vorgaben in einem Attribut ("archetype_relationParams"?) bündeln (parseParams wäre unser Freund, und ein "setstate" (oder setreading?) statt "attr" könnte man mit einem Präfix kenntlich machen?

Code Auswählen Erweitern

setList="on off foo" s:state=off r:foo="das ist ein Test"

(Erst müßte man aber den Mechanismus verstehen ).

[Beta-User]

...es schien doch mal ein paar Beispieldefinitionen aus der dummy+code-Ära zu geben. Hier mal ein Beispiel-Satz für den RT-DN:

Code Auswählen Erweitern

define default_HM_CC_RT_DN dummy
attr default_HM_CC_RT_DN userattr attributes expert regexp
attr default_HM_CC_RT_DN actualRoom hidden
attr default_HM_CC_RT_DN attributes captionRoom description event-on-change-reading expert group icon index room suffix
attr default_HM_CC_RT_DN attributesExclude alias
attr default_HM_CC_RT_DN captionRoom {AttrVal((devspec2array("device=$name:FILTER=chanNo=04"))[0], "room", undef)}
attr default_HM_CC_RT_DN description {AttrVal((devspec2array("device=$name:FILTER=chanNo=04"))[0], "description", undef)}
attr default_HM_CC_RT_DN event-on-change-reading R-btnLock,R-globalBtnLock,R-modusBtnLock,battery,motorErr,state
attr default_HM_CC_RT_DN expert 3_all
attr default_HM_CC_RT_DN group Heizung
attr default_HM_CC_RT_DN icon hc_wht_regler
attr default_HM_CC_RT_DN index {AttrVal((devspec2array("device=$name:FILTER=chanNo=04"))[0], "index", undef)}
attr default_HM_CC_RT_DN regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo!=.+
attr default_HM_CC_RT_DN room default
attr default_HM_CC_RT_DN setList 
attr default_HM_CC_RT_DN subType default
attr default_HM_CC_RT_DN suffix thermostat
attr default_HM_CC_RT_DN webCmd :

define default_HM_CC_RT_DN_Clima dummy
attr default_HM_CC_RT_DN_Clima userattr attributes regexp
attr default_HM_CC_RT_DN_Clima attributes description event-on-change-reading group icon
attr default_HM_CC_RT_DN_Clima attributesExclude alias
attr default_HM_CC_RT_DN_Clima description Heizung
attr default_HM_CC_RT_DN_Clima event-on-change-reading ValvePosition,boostTime,controlMode,desired-temp,measured-temp
attr default_HM_CC_RT_DN_Clima group Heizung
attr default_HM_CC_RT_DN_Clima icon hc_wht_regler
attr default_HM_CC_RT_DN_Clima regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo=04
attr default_HM_CC_RT_DN_Clima room default
attr default_HM_CC_RT_DN_Clima setList 
attr default_HM_CC_RT_DN_Clima subType default
attr default_HM_CC_RT_DN_Clima webCmd :

define default_HM_CC_RT_DN_ClimaTeam dummy
attr default_HM_CC_RT_DN_ClimaTeam userattr attributes regexp
attr default_HM_CC_RT_DN_ClimaTeam actualRoom hidden
attr default_HM_CC_RT_DN_ClimaTeam attributes captionRoom description event-on-change-reading group icon index room suffix
attr default_HM_CC_RT_DN_ClimaTeam attributesExclude alias
attr default_HM_CC_RT_DN_ClimaTeam captionRoom {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "room", undef)}
attr default_HM_CC_RT_DN_ClimaTeam description {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "description", undef)}
attr default_HM_CC_RT_DN_ClimaTeam event-on-change-reading none
attr default_HM_CC_RT_DN_ClimaTeam group Heizung
attr default_HM_CC_RT_DN_ClimaTeam icon hc_wht_regler
attr default_HM_CC_RT_DN_ClimaTeam index {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "index", undef)}
attr default_HM_CC_RT_DN_ClimaTeam regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo=05
attr default_HM_CC_RT_DN_ClimaTeam room default
attr default_HM_CC_RT_DN_ClimaTeam setList 
attr default_HM_CC_RT_DN_ClimaTeam subType default
attr default_HM_CC_RT_DN_ClimaTeam suffix ClimaTeam
attr default_HM_CC_RT_DN_ClimaTeam webCmd :

define default_HM_CC_RT_DN_Climate dummy
attr default_HM_CC_RT_DN_Climate userattr attributes regexp
attr default_HM_CC_RT_DN_Climate actualRoom hidden
attr default_HM_CC_RT_DN_Climate attributes captionRoom description event-on-change-reading group icon index room suffix
attr default_HM_CC_RT_DN_Climate attributesExclude alias
attr default_HM_CC_RT_DN_Climate captionRoom {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "room", undef)}
attr default_HM_CC_RT_DN_Climate description {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "description", undef)}
attr default_HM_CC_RT_DN_Climate event-on-change-reading none
attr default_HM_CC_RT_DN_Climate group Heizung
attr default_HM_CC_RT_DN_Climate icon hc_wht_regler
attr default_HM_CC_RT_DN_Climate index {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "index", undef)}
attr default_HM_CC_RT_DN_Climate regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo=02
attr default_HM_CC_RT_DN_Climate room default
attr default_HM_CC_RT_DN_Climate setList 
attr default_HM_CC_RT_DN_Climate subType default
attr default_HM_CC_RT_DN_Climate suffix Climate
attr default_HM_CC_RT_DN_Climate webCmd :

define default_HM_CC_RT_DN_Weather dummy
attr default_HM_CC_RT_DN_Weather userattr attributes regexp
attr default_HM_CC_RT_DN_Weather actualRoom hidden
attr default_HM_CC_RT_DN_Weather attributes captionRoom description event-on-change-reading group icon index room suffix
attr default_HM_CC_RT_DN_Weather attributesExclude alias
attr default_HM_CC_RT_DN_Weather captionRoom {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "room", undef)}
attr default_HM_CC_RT_DN_Weather description {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "description", undef)}
attr default_HM_CC_RT_DN_Weather event-on-change-reading none
attr default_HM_CC_RT_DN_Weather group Heizung
attr default_HM_CC_RT_DN_Weather icon hc_wht_regler
attr default_HM_CC_RT_DN_Weather index {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "index", undef)}
attr default_HM_CC_RT_DN_Weather regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo=01
attr default_HM_CC_RT_DN_Weather room default
attr default_HM_CC_RT_DN_Weather setList 
attr default_HM_CC_RT_DN_Weather subType default
attr default_HM_CC_RT_DN_Weather suffix Weather
attr default_HM_CC_RT_DN_Weather webCmd :

define default_HM_CC_RT_DN_WindowRec dummy
attr default_HM_CC_RT_DN_WindowRec userattr attributes regexp
attr default_HM_CC_RT_DN_WindowRec actualRoom hidden
attr default_HM_CC_RT_DN_WindowRec attributes captionRoom description event-on-change-reading group icon index room suffix
attr default_HM_CC_RT_DN_WindowRec attributesExclude alias
attr default_HM_CC_RT_DN_WindowRec captionRoom {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "room", undef)}
attr default_HM_CC_RT_DN_WindowRec description {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "description", undef)}
attr default_HM_CC_RT_DN_WindowRec event-on-change-reading none
attr default_HM_CC_RT_DN_WindowRec group Heizung
attr default_HM_CC_RT_DN_WindowRec icon hc_wht_regler
attr default_HM_CC_RT_DN_WindowRec index {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "index", undef)}
attr default_HM_CC_RT_DN_WindowRec regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo=03
attr default_HM_CC_RT_DN_WindowRec room default
attr default_HM_CC_RT_DN_WindowRec setList 
attr default_HM_CC_RT_DN_WindowRec subType default
attr default_HM_CC_RT_DN_WindowRec suffix WindowRec
attr default_HM_CC_RT_DN_WindowRec webCmd :

define default_HM_CC_RT_DN_remote dummy
attr default_HM_CC_RT_DN_remote userattr attributes regexp
attr default_HM_CC_RT_DN_remote actualRoom hidden
attr default_HM_CC_RT_DN_remote attributes captionRoom description event-on-change-reading group icon index room suffix
attr default_HM_CC_RT_DN_remote attributesExclude alias
attr default_HM_CC_RT_DN_remote captionRoom {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "room", undef)}
attr default_HM_CC_RT_DN_remote description {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "description", undef)}
attr default_HM_CC_RT_DN_remote event-on-change-reading none
attr default_HM_CC_RT_DN_remote group Heizung
attr default_HM_CC_RT_DN_remote icon hc_wht_regler
attr default_HM_CC_RT_DN_remote index {AttrVal((devspec2array("device=".InternalVal($name, "device", 0).":FILTER=chanNo=04"))[0], "index", undef)}
attr default_HM_CC_RT_DN_remote regexp model=HM-CC-RT-DN(-\d)?:FILTER=chanNo=06
attr default_HM_CC_RT_DN_remote room default
attr default_HM_CC_RT_DN_remote setList 
attr default_HM_CC_RT_DN_remote subType default
attr default_HM_CC_RT_DN_remote suffix remote
attr default_HM_CC_RT_DN_remote webCmd :

define default_default_HM_CC_RT_DN dummy
attr default_default_HM_CC_RT_DN userattr attributes regexp
attr default_default_HM_CC_RT_DN attributes group icon
attr default_default_HM_CC_RT_DN attributesExclude alias
attr default_default_HM_CC_RT_DN group Heizung
attr default_default_HM_CC_RT_DN icon hc_wht_regler
attr default_default_HM_CC_RT_DN regexp default_HM_CC_RT_DN.*
attr default_default_HM_CC_RT_DN room default
attr default_default_HM_CC_RT_DN setList 
attr default_default_HM_CC_RT_DN subType default
attr default_default_HM_CC_RT_DN webCmd :

Das ganze ist als RAW-listing aus dem Anhang von https://forum.fhem.de/index.php/topic,45553.msg393901.html#msg393901 iVm. dem dort verlinkten Tool generiert...

EDIT: Im Anhang das gesamte ausgepackte Ergebnis

[Beta-User]

So, eine halbe Iteration weiter:

- Perl scheint weiter evaluiert zu werden. Schön. Allerdings nur, wenn man keine Perl-Inhalte in den Attributen hatte... Meine Perl-devStateIcon für die RT-DN sahen ziemlich lustig aus in der "Änderungsübersicht" .
- Irgendwie hatte ich beim Rumtesten im Echtsystem nach dem Import doch ziemlich viele Änderungen drin, die ich auf die Schnelle nicht so recht überblicken wollte. Daher werden jetzt beim Import alle Attribute erst mal als "überschreibe nur, was nicht vorhanden ist" markiert.
- Unschön fand ich auch, dass man für die RT-DN dann z.B. anscheinend bisher 7 archetype gebraucht hat, wenn man alle Kanaldevices konfigurieren bzw. synchron halten wollte. Da sich das Thema mehr oder weniger bei allen mehrkanaligen Devices stellt (und z.B. auch bei HUEDevice, bei denen man bei "angehängter Sensorik" nur an einem Inernal erkennen kann, was wie zusammengehört), gibt's jetzt noch eine "oberste Schicht", die man über die vorhandene Logik drüberlegen kann. Attribute in der Form "actual_<attribute>_<irgendwas>" werden als FILTER+Attributwert-Angabe verstanden, Trenner ist das erste Leerzeichen.

Da das vermutlich ohne Beispiel kaum verständlich ist, hier mal ein Satz achetype+dummy zum Testen mit der vorhin im ersten Post aktualisierten Version:

Code Auswählen Erweitern

defmod atTst archetype TYPE=dummy:FILTER=NAME=dmTst.*
attr atTst actual_devStateIcon Perl:{ReadingsVal($name,'state','test')}
attr atTst actual_devStateIcon_1 NAME=.+2 undef,Perl:{ReadingsVal($name,'test','test2')}
attr atTst actual_room undef:TestDummys
attr atTst attributes room devStateIcon


Code Auswählen Erweitern

define dmTst1 dummy
define dmTst2 dummy

[Benni]

Ein Beispiel hilft da tatsächlich weiter!

Das heißt ich kann meine möglichen Inheritors hier noch weiter filtern und die Attribute je nach FILTER-Match anders belegen.

So weit so gut! Ja, spart archetype-Devices, muss man sehen ab wann es unübersichtlich wird, bzw. schwer zu filtern.
Aber grundsätzlich finde ich die Idee gut, zusammengehöriges (Device+Kanäle) in einem archetype für einen Device-Typ zusammenfassen zu können.

Ich habe heute mal noch versucht mit den Relations zu spielen, analog zum Beispiel in der commandref. Dazu habe ich das Dummy-Beispiel um einen archetype erweitert, der einen readingsProxy auf das state-Reading anlegen soll. Es ist mir leider nicht gelungen!

Code Auswählen Erweitern


defmod atTst_rpRelation archetype defined_by=atTst_rpRelation
attr atTst_rpRelation userattr actual_group actual_room
attr atTst_rpRelation actualTYPE readingsProxy
attr atTst_rpRelation actual_group RelationDevice
attr atTst_rpRelation actual_room RelationProxies
attr atTst_rpRelation attributes room group
attr atTst_rpRelation metaDEF dmTst1:state
attr atTst_rpRelation metaNAME $relation\_Proxy
attr atTst_rpRelation relations TYPE=dummy:FILTER=NAME=dmTst.*


Die readingsProxy werden nicht angelegt.

Das Log (verbose 5 für das archetype-device) sagt mir nur ".... not found":

Code Auswählen Erweitern


2022.02.10 20:21:37 4: archetype (atTst_rpRelation) - triggered by event: "DEFINED dmTst8"
2022.02.10 20:21:37 5: archetype (atTst_rpRelation) - call archetype_devspec
2022.02.10 20:21:37 5: archetype (atTst_rpRelation) - call archetype_devspec
2022.02.10 20:21:37 3: archetype (atTst_rpRelation) - starting define inheritors
2022.02.10 20:21:37 5: archetype (atTst_rpRelation) - call archetype_AnalyzeCommand
sh: 1: dmTst8_Proxy: not found
2022.02.10 20:21:37 5: archetype (atTst_rpRelation) - call archetype_AnalyzeCommand
sh: 1: dmTst1:state: not found
2022.02.10 20:21:37 5: archetype (atTst_rpRelation) - call archetype_devspec
2022.02.10 20:21:37 3: archetype (atTst_rpRelation) - define inheritors done
2022.02.10 20:21:37 4: archetype (atTst_rpRelation) - triggered by event: "ATTR dmTst8 room TestDummys"
2022.02.10 20:21:37 4: archetype (atTst_rpRelation) - triggered by event: "ATTR dmTst8 setList on off"
2022.02.10 20:21:37 4: archetype (atTst_rpRelation) - triggered by event: "ATTR dmTst8 webCmd on:off"
2022.02.10 20:21:37 4: archetype (atTst_rpRelation) - triggered by event: "ATTR dmTst8 devStateIcon {ReadingsVal($name,'state','test')}"


gb#

[Beta-User]

Ein Beispiel hilft da tatsächlich weiter!

Das heißt ich kann meine möglichen Inheritors hier noch weiter filtern und die Attribute je nach FILTER-Match anders belegen.

Soweit die Theorie. Bin aber noch nicht sicher, wie weit das trägt, da muss ich auch erst mal noch etwas testen...

Ich habe heute mal noch versucht mit den Relations zu spielen, analog zum Beispiel in der commandref. Dazu habe ich das Dummy-Beispiel um einen archetype erweitert, der einen readingsProxy auf das state-Reading anlegen soll. Es ist mir leider nicht gelungen!

Da war durch die Umstellung auf AnalyzeCommandChain in der Tat was kaputt gegangen, das funktioniert mit der svn-Version tadellos.
Habe mal ein paar "eval" gelassen, obwohl mir das für die reine Text-Ersetzung nicht so recht gefällt. Na ja, eines nach dem anderen...

initialize wollte dagegen auch mit der svn-Version nicht so recht, was aber nach meinem jetzigen Kenntnisstand vermutlich eher daran liegt, dass wir uns mit rP ein ungünstiges Beispiel ausgesucht hatten - da spielt die Reihenfolge des Anlegens eine Rolle...

Bin noch nicht so richtig durch und auch nicht sicher, ob nicht bei der jetzt bei der neueren im 1. Beitrag zu findenden Fassung wieder was anderes kaputt gegangen ist; mal sehen, wann ich weiter testen kann und mag...

[Benni]

Soweit die Theorie. Bin aber noch nicht sicher, wie weit das trägt, da muss ich auch erst mal noch etwas testen...
Da war durch die Umstellung auf AnalyzeCommandChain in der Tat was kaputt gegangen, das funktioniert mit der svn-Version tadellos.
Habe mal ein paar "eval" gelassen, obwohl mir das für die reine Text-Ersetzung nicht so recht gefällt. Na ja, eines nach dem anderen...

Habe mich an der Stelle eben auch mal durch den code gequält. Und festgestellt, das zumindest metaNAME nicht (mehr) korrekt umgesetzt wird und letztendlich leer bleibt.

Werde gleich mit der neuen Version weiter testen

initialize wollte dagegen auch mit der svn-Version nicht so recht, was aber nach meinem jetzigen Kenntnisstand vermutlich eher daran liegt, dass wir uns mit rP ein ungünstiges Beispiel ausgesucht hatten - da spielt die Reihenfolge des Anlegens eine Rolle...

Hmm ... Beispiel war ja eigentlich erst mal nur dummy und zwar ohne relations. rP hat da noch keine Rolle gespielt! Nichts desto trotz scheint das Initialize aber wohl nur beim Anlegen der relations zum Tragen zu kommen.
Wobei ich es auch grundsätzlich bei "normalen" archetypes beim ersten Anlegen sinnvoll finden würde!
Btw.: readingsProxy ist anscheinend egal, ob beim define das angegebene Quelldevices und/oder Reading existiert.

Bin noch nicht so richtig durch und auch nicht sicher, ob nicht bei der jetzt bei der neueren im 1. Beitrag zu findenden Fassung wieder was anderes kaputt gegangen ist; mal sehen, wann ich weiter testen kann und mag...

... werden wir sehen

[Benni]

Also das funktioniert jetzt:

Code Auswählen Erweitern


defmod atTst_rpRelation archetype defined_by=atTst_rpRelation
attr atTst_rpRelation userattr actual_group actual_room
attr atTst_rpRelation actualTYPE readingsProxy
attr atTst_rpRelation actual_group RelationDevice
attr atTst_rpRelation actual_room RelationProxies
attr atTst_rpRelation attributes room group
attr atTst_rpRelation initialize set $relation off
attr atTst_rpRelation metaDEF $relation:state
attr atTst_rpRelation metaNAME $relation\_Proxy
attr atTst_rpRelation relations TYPE=dummy:FILTER=NAME=dmTst.*
attr atTst_rpRelation verbose 5


Auch der darin enthaltene Initialize wird korrekt ausgeführt und setzt am relation-Device den Wert auf off.
Genau das sollte aber m.E. initial vom vererbenden archetype ausgeführt werden.

[Beta-User]

Hmm, die Beschränkung auf relations erschließt sich mir auch nicht, allerdings würde ich gerne die eval loswerden (#571 und #742, z.B.), und bei den %specials ab Zeile 613 muss es vorne % statt $ sein.

Notfalls muss man einen Bruch mit der alten Syntax in Kauf nehmen, lieber wäre mir

Code Auswählen Erweitern

$relation_Proxy
oder

Code Auswählen Erweitern

${relation}_Proxy
statt des backslash-escape.
Also falls du eine Idee hast...

[Benni]

Hmm, die Beschränkung auf relations erschließt sich mir auch nicht, allerdings würde ich gerne die eval loswerden (#571 und #742, z.B.), und bei den %specials ab Zeile 613 muss es vorne % statt $ sein.

Notfalls muss man einen Bruch mit der alten Syntax in Kauf nehmen, lieber wäre mir

Code Auswählen Erweitern

$relation_Proxy
oder

Code Auswählen Erweitern

${relation}_Proxy
statt des backslash-escape.
Also falls du eine Idee hast...

Auch nicht so recht!
Variante 1 wird halt unleserlich wenn's zu sowas kommt:

Code Auswählen Erweitern

prefix$relationsuffix

Variante 2 sieht nach Perl aus, ist aber keins

Aber eine Klammerung mit sauberem Anfang und Ende wären denke ich am besten, also irgendwie in der Art

Code Auswählen Erweitern


prefix[relation]suffix

(Eckige klammern kenn ich doch woher ...  )

oder

Code Auswählen Erweitern

prefix%relation%suffix

mit oder ohne $ am Special-Namen ... egal.
Hat u.U noch den Nachteil, dass man den umgekehrten Fall ggf. maskieren müsste, dürfte in dem Fall aber sehr unwahrscheinlich sein.

[Benni]

Es kam mir gerade noch ein Gedanke, bzw. ist es mir beim Bereinigen meiner Tests aufgefallen.

Konsequenterweise sollte man die relation auch als echte Abhängikeit definieren können. So müsste man auch bei einem delete des relation-Devices die abhängigen Devices löschen können, wenn entsprechende (per attribut?) definiert. Mit rename verhält es sich ähnlich.
Vergleichbares gibt es ja bei Tabellenbeziehungen auf Datenbanken (foreign-key contraints) ... vielleicht ist es dann auch eher eine dependency, denn eine relation.

Ansonsten habe ich jetzt mal mit devices gespielt, die mehreren archetypes zugeordnet sind. Das scheint soweit erst mal problemlos zu funktionieren. Wobei ich bisher ohne Überschneidungen, ggf. mit widersprüchlichen Angaben getestet habe. Da wird aber schätzungsweise mehr oder weniger der Zufall entscheiden, was zuschlägt. In dem Fall könnte eine Priorisierung analog zu NTFY-ORDER aushelfen.

... aber ja! Erst mal die bestehende Grundfunktionalität vollends begreifen und sauber umsetzen und dann neue Ideen verwursten. Ich schreibe das hier auch mehr als Gedankenstütze auf, damit nichts verloren geht

Ich denke um meinen eigentlichen Trigger für das Thema die eocr Varianten nach Typen sauber zu setzen kommt man mit dem was da ist schon recht weit.

Was mir in dem Zusammenhang noch aus meiner manuellen Umstellung im Hinterkopf geblieben ist, ist dass man nicht nur den Typ berücksichtigen muss, sondern speziell bei eocr auch ggf. zusätzlich definierte userredings.
könnte mit actual_attribute_irgendwas beliebig komplex werden.

... so genug Brainstorming für heute!

[Beta-User]

Das hier ist eigentlich ein optisch guter Vorschlag:

Code Auswählen Erweitern

prefix%relation%suffix

Hat aber alles den Nachteil, dass man "noch eine Syntax" hat. Tendiere (auch wg. der Einheitlichkeit innerhalb des Moduls) weiter zu der "einfachen" $-Schreibweise, eine Idee für Code gibt es schon.

Was das mit Umbenennen und Löschen angeht: Sehr wichtiger Hinweis, finde ich v.a. für Anfänger/Einsteiger+ eine wichtige Sache, dass das "intuitiv" geht... Kommt auf die Liste, mal sehen, ob/wann das in der einen oder anderen Form Eingang findet.

Erst steht auch bei mir noch das Verstehen der "derive attributes"-Variante im Vordergrund bzw. das "unfallfreie Einpacken".

igami hatte um etwas Geduld gebeten, bis er mir (ggf. noch weiteren?) eine Einführung in den "Ist-Stand" geben kann.

Ich denke um meinen eigentlichen Trigger für das Thema die eocr Varianten nach Typen sauber zu setzen kommt man mit dem was da ist schon recht weit.

Das ist doch schon mal was...!

Was mir in dem Zusammenhang noch aus meiner manuellen Umstellung im Hinterkopf geblieben ist, ist dass man nicht nur den Typ berücksichtigen muss, sondern speziell bei eocr auch ggf. zusätzlich definierte userredings.
könnte mit actual_attribute_irgendwas beliebig komplex werden.

Muss mit dem ganzen auch erst noch etwas spielen, damit klar ist, was geht, was nicht, und wo ggf. noch was fehlt...

... so genug Brainstorming für heute!

DANKE auf alle Fälle für deinen Input, es hilft mir sehr weiter, wenn Rückmeldung zu meinen Gedanken kommen und das eine oder andere "anders" ausgetestet wird wie es mir in den Sinn gekommen wäre .

[Beta-User]

Mal wieder ein "teaser"...

Auf die Schnelle zusammengeschustert, vielleicht auch noch nicht ganz fertig, aber prinzipiell erst mal gar nicht so unübersichtlich wie zunächst befürchtet: Das (vorläufige) "Komplettpaket" für den HM-CC-RT-DN.

Code Auswählen Erweitern

defmod archHM_RT_DN archetype TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN
attr archHM_RT_DN userattr actual_devStateIcon_4 actual_event-min-interval_4 actual_event-on-change-reading_4 actual_group actual_icon actual_room actual_room_4 actual_tempListTmpl actual_tempListTmpl_4 actual_userattr_4 actual_webCmd_4 actual_widgetOverride_4
attr archHM_RT_DN actual_devStateIcon_4 chanNo=04 {devStateIcon_Clima($name)}
attr archHM_RT_DN actual_event-min-interval_4 chanNo=04 undef:measured-temp:900,desired-temp:1800
attr archHM_RT_DN actual_event-on-change-reading_4 chanNo=01 undef:none
attr archHM_RT_DN actual_group Heizung
attr archHM_RT_DN actual_icon hm-cc-rt-dn
attr archHM_RT_DN actual_room Steuerung->Heizung
attr archHM_RT_DN actual_room_4 chanNo=04 undef:Steuerung->Heizung
attr archHM_RT_DN actual_tempListTmpl_4 chanNo=04 none
attr archHM_RT_DN actual_userattr_4 chanNo=04 weekprofile
attr archHM_RT_DN actual_webCmd_4 chanNo=04 desired-temp
attr archHM_RT_DN actual_widgetOverride_4 chanNo=04 desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
attr archHM_RT_DN attributes room webCmd tempListTmpl group widgetOverride event-min-interval event-on-change-reading
attr archHM_RT_DN room Steuerung->Config


Für den WT sieht es bestimmt auch nicht so viel anders aus...

[Beta-User]

Im ersten Beitrag ist jetzt die erste gepackagte Version zu finden, ist noch nicht ausgiebigst getestet, aber scheint soweit akzeptabel zu laufen.

Habe jetzt auch mal mit Filtern und Perl-Code rumexperimentiert, u.a. auch, weil ich irgendwann man meine fhemApp-Einstellungen vollends ausrollen wollte. Das ganze funktioniert auf Basis der genericDeviceType-Angaben, die für RHASSPY sowieso erforderlich waren und die "betroffenen" Geräte weitestgehend sinnvoll abgrenzen. Außerdem wollte ich verstehen, welchen Sinn es hat, Attribute aus Attributen abzuleiten (allerdings auf eine etwas andere Weise wie die commandref das z.B. für "alias" als Beispiel zeigt).

Wer es nachbasteln will:
Code für myutils:

Code Auswählen Erweitern

sub genericDeviceType2appOption {
    my $device = shift // return;
    return if !$defs{$device};
    my $TYPE = InternalVal($device,'TYPE',undef) // return;
    my $gDT  = AttrVal($device,'genericDeviceType',undef) // return;
    my $str='{ "template": "';
   
    my %gDT2template = (
        lightHUEDevice => 'dimmer3',
        light            => 'dimmer',
        switch            => 'switch',
        thermometer       => 'thermometer',
        thermostat       => 'thermostat',
        shutter           => 'shutter'
    );
    my $str2 = $gDT2template{"${gDT}$TYPE"} // $gDT2template{$gDT} // return;
    $str .= $str2;
    $str .= '", "room": "';
    $str2 = AttrVal($device,'room','unknown');
    $str2 = (split m{,}, $str2)[0];
    $str .= $str2;
    my ($arr, $extras) = parseParams(AttrVal($device,'appOptions2',''));
    for (sort keys %{$extras}) {
        $str .= qq(", "$_": "$extras->{$_});
    }
    $str .= '" }';
    return $str;
}


attr global userattr erhält einen etwas modifizierten Eintrag:

Code Auswählen Erweitern

appOptions.*:textField-long

Der archetype:

Code Auswählen Erweitern

defmod acFhemApp archetype genericDeviceType=.+
attr acFhemApp attributes appOptions
attr acFhemApp actual_appOptions_1 appOptions2!~ignore {genericDeviceType2appOption($name)}

Die (Nicht-) Zieldevices kann man jetzt über das (per Kommandfeld zu setzende) Attribut "appOptions2" von der Behandlung ausschließen (ignore eintragen), oder dem Code zusätzliche key/value-Paare vorgeben:

Beispiele:

Code Auswählen Erweitern

attr Licht_Essen appOptions2 home=true dashboard=true
attr Licht_Stehlampe_links_alt appOptions2 ignore


Den myUtils-Code kann man sicher noch verbessern, war jetzt v.a. erst mal wegen des Prinzips...

[Benni]

Mist! Mein Produktiv-System ist wohl zu alt!

Wollte den Spielplatz dorthin verlagern und habe mein FHEM gekillt

Undefined subroutine &main::setNotifyDev called at ./FHEM/98_archetype.pm line 141.

Ich setze das NOTIFYDEV in archetype bei mir nun vorerst wieder direkt!

Notiz an mich selbst:
Beim nächsten einspielen einer neuen Version daran denken!

gb#

PS: Update vermeide ich aktuell, zumindest so lange an der unicode-Geschichte noch gearbeitet wird und insb. configDb da noch Ausstände hat.

[Beta-User]

Mist! Mein Produktiv-System ist wohl zu alt!

Ups, sorry, hatte ich nicht dran gedacht ...

Symptome klingen nach "reload". Bei Neustart sollte das Modul nicht geladen werden können...

Beim nächsten einspielen einer neuen Version daran denken!

gb#

PS: Update vermeide ich aktuell, zumindest so lange an der unicode-Geschichte noch gearbeitet wird und insb. configDb da noch Ausstände hat.

Alternativvorschlag: Die Funktion in fhem.pl reinknödeln. Beim nächsten "echten" update ist es dann ordnungsgemäß entsorgt...

Bin übrigens auch auf configDB und habe mit dem heutigen Update noch keine Probleme feststellen können. Habe aber auch nicht allzuviele Schnittstellen ala HTTPMOD usw.;   das "magische Attribut" ist aber auch noch nicht gesetzt...

[Beta-User]

Für den WT sieht es bestimmt auch nicht so viel anders aus...

Hier mal ein "kombiniertes archetype" für den WT und RT-DN (das devStateIcon ist code von hier):

Code Auswählen Erweitern

define archHM_RT_DN_WT archetype TYPE=CUL_HM:FILTER=model=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU)
attr archHM_RT_DN_WT actual_devStateIcon_RT model=HM-CC-RT-DN:FILTER=chanNo=04 Perl:{devStateIcon_Clima($name)}
attr archHM_RT_DN_WT actual_devStateIcon_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 Perl:{devStateIcon_Clima($name)}
attr archHM_RT_DN_WT actual_event-min-interval_0 DEF=.{6} measured-temp:900,desired-temp:1800,humidity:1800,actuator:7200
attr archHM_RT_DN_WT actual_event-min-interval_RT4 model=HM-CC-RT-DN:FILTER=chanNo=04 measured-temp:900,desired-temp:1800
attr archHM_RT_DN_WT actual_event-min-interval_WT2 model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 measured-temp:900,desired-temp:1800,humidity:1800
attr archHM_RT_DN_WT actual_event-on-change-reading_0 DEF=.{6} measured-temp:0.2,.*,
attr archHM_RT_DN_WT actual_event-on-change-reading_RT1 model=HM-CC-RT-DN:FILTER=chanNo=01 none
attr archHM_RT_DN_WT actual_event-on-change-reading_RT4 model=HM-CC-RT-DN:FILTER=chanNo=04 measured-temp:0.2,.*
attr archHM_RT_DN_WT actual_event-on-change-reading_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 measured-temp:0.2,.*
attr archHM_RT_DN_WT actual_group Heizung
attr archHM_RT_DN_WT actual_icon_1 model=HM-CC-RT-DN hm-cc-rt-dn
attr archHM_RT_DN_WT actual_icon_2 model=HM-TC-IT-WM-W-EU hm-tc-it-wm-w-eu
attr archHM_RT_DN_WT actual_room Steuerung->Heizung
attr archHM_RT_DN_WT actual_room_RT model=HM-CC-RT-DN:FILTER=chanNo=04 undef:Steuerung->Heizung
attr archHM_RT_DN_WT actual_room_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 undef:Steuerung->Heizung
attr archHM_RT_DN_WT actual_tempListTmpl_RT4 model=HM-CC-RT-DN:FILTER=chanNo=04 none
attr archHM_RT_DN_WT actual_userattr_RT4 model=HM-CC-RT-DN:FILTER=chanNo=04 weekprofile
attr archHM_RT_DN_WT actual_webCmd_RT4 model=HM-CC-RT-DN:FILTER=chanNo=04 desired-temp
attr archHM_RT_DN_WT actual_widgetOverride_RT4 model=HM-CC-RT-DN:FILTER=chanNo=04 desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
attr archHM_RT_DN_WT actual_widgetOverride_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
attr archHM_RT_DN_WT attributes room webCmd tempListTmpl group widgetOverride event-min-interval event-on-change-reading
attr archHM_RT_DN_WT room Steuerung->Config

Fazit: die Filter-Geschichte ist nicht nur in der Theorie hilfreich, wenn man es mal durchschaut hat. (Schon klar, dass der WT gar keinen "actuator" liefert, aber groß schaden tut es auch nicht ).

Hier noch ein weiteres kleines Beispiel wie sowas aussehen kann:

Code Auswählen Erweitern

define archOMGTemp archetype TYPE=MQTT2_DEVICE:FILTER=a:model=OpenMQTTGateway_BT_temp_hum_sensor
attr archOMGTemp actual_event-min-interval batteryPercent:7200,temperature:300,humidity:900
attr archOMGTemp actual_event-on-change-reading batteryPercent,temperature:0.2,humidity:0.5,distance:5
attr archOMGTemp attributes event-on-change-reading event-min-interval
attr archOMGTemp room Steuerung->Config
Anmerkungen:
- Die Dinger liefern noch eine ganze Menge weiterer "bulk"-Reading-Updates, aber das meiste interessiert überhaupt nicht...
- Da die auch ein Reading "model" kennen, das aber andere Werte enthält, muss man hier die devspec diese Doppelung ebenfalls abbilden, damit auf den richtiger Datenpunkt (Attribut-Wert) zugegriffen wird.

Nachdem ich jetzt dann noch an ein paar weiteren Einzelgeräten (TYPE z.B. YAMAHA_AVR, FRITZBOX, SYSMON) einige wenige "eocr .*" verteilt habe, geht es im Event-Monitor wieder eher sehr beschaulich zu, ohne dass bisher erkennbar Funktionalität gelitten hätte... Dafür bekommt man wieder genug Zeit zu realisieren, wenn ein virtueller Temp-Sensor seinen Wert an den/die RT versendet hat .

Bin damit erst mal zufrieden und hoffe, die Beispielchen helfen jemandem weiter.

[zife]

Also, nutzt mich mal als Tester, der einen DAU nachahmt (ob freiwillig oder unfreiwillig, das verrate ich nicht). Jedenfalls möchte ich mal was ganz, ganz Simples beitragen:

Da wird man bekehrt, nicht in der fhem.cfg rumzuschrauben... und wenn man nun versucht, ein Attribut per GUI zu setzen, bekommt man...

Code Auswählen Erweitern

RolladenArchetype1: bad attribute name 'actual_.+' (allowed chars: A-Za-z/\d_\.-)



Das passiert mir, wenn ich das Attribut "actual_" setzen will (also aus dem Dropdown auswähle), und dann in das Freitextfeld mein Attribut reinschreibe.

Zu blöd zum bedienen oder kleine Unzulänglichkeit? Irgendwie wirkt das Regex nicht?

@Beta-User:
Du hast im Automatisierungs-Faden von der "DEV"-Version gesprochen. Welche ist das? Ich hab erstmal die aus der Standard-Verteilung genutzt...

[Beta-User]

Du hast im Automatisierungs-Faden von der "DEV"-Version gesprochen. Welche ist das? Ich hab erstmal die aus der Standard-Verteilung genutzt...

Die dev-Version ist im ersten Beitrag zu finden. Wenn du die in deine Installation kopierst bitte darauf achten, dass die Rechte hinterher noch stimmen... (owner =>fhem:dialout)

Also, nutzt mich mal als Tester, der einen DAU nachahmt (ob freiwillig oder unfreiwillig, das verrate ich nicht). Jedenfalls möchte ich mal was ganz, ganz Simples beitragen:

Da wird man bekehrt, nicht in der fhem.cfg rumzuschrauben... und wenn man nun versucht, ein Attribut per GUI zu setzen, bekommt man...

Code Auswählen Erweitern

RolladenArchetype1: bad attribute name 'actual_.+' (allowed chars: A-Za-z/\d_\.-)



Das passiert mir, wenn ich das Attribut "actual_" setzen will (also aus dem Dropdown auswähle), und dann in das Freitextfeld mein Attribut reinschreibe.

Zu blöd zum bedienen oder kleine Unzulänglichkeit? Irgendwie wirkt das Regex nicht?

Das Regex bewirkt schon was, allerdings funktioniert das per drop-down erst, wenn das jeweilige Attribut "richtig" benannt wurde und sich ein Inhalt darin findet (weil z.B. "importiert" wurde => dev-Version), oder, wenn das "Zusatzattribut" in userReadings eingetragen wurde (auch das macht uU. die dev-Version automatisch).

Anders gesagt:

Du willst z.B. haben:

Code Auswählen Erweitern

attr RolladenArchetype1 actual_userReadings positionR:position:.* {10*(round((ReadingsNum($name,'position',-1)/10),0))}
Dann kannst du das über das Kommandofeld (oder auch "grüne Plus") so eingeben, die regex bewirkt, dass FHEM das "schluckt".

Mit

Code Auswählen Erweitern

attr RolladenArchetype1 attributes userReadings
würde das dann zur Verteilung an die der devspec entsprechenden Geräte vorgesehen.

[zife]

Na, ich hatte erstmal ganz plump angefangen und wollte ein event-on-change-reading vorgeben und vererben.

Also hab ich das Archetype definiert, dann
   attr RolladenArchetype1 attributes event-on-change-reading
gesetzt,

und dann bin ich steckengeblieben. Per GUI ist mir das Anlegen von "actual_event-on-change-reading .*" nicht gelungen, über die Kommandozeile sehr wohl (und es vererbt sich auch hübsch bei "set RolladenArchetype inheritance".

Vielleicht klemmt da noch mein Grundverständnis - ich hätte gedacht, ich kann das auch per GUI erledigen.

Sorry, für den Moment ist das wohl noch keine große Tester-Hilfe, aber kommt schon noch 

[Beta-User]

Sorry, für den Moment ist das wohl noch keine große Tester-Hilfe, aber kommt schon noch 

Doch, grade wegen solcher "Anfänger-Stolpersteinchen" ist das eine große Hilfe (und sei es nur für "kommende Generationen", die das hier lesen...)

Solche "muss man das erste Mal händisch setzen"-Attribute kennen einige Module, z.B. HTTPMOD, MQTT_DEVICE  (also 1. Generation) und MYSENSORS_DEVICE.

(und es vererbt sich auch hübsch bei "set RolladenArchetype inheritance".

...das ist doch schon mal was. Modul prinzipiell verstanden, alles gut .

Vielleicht klemmt da noch mein Grundverständnis - ich hätte gedacht, ich kann das auch per GUI erledigen.

Es kann sein, dass die Attribute direkt verfügbar werden, wenn "attributes" in der Testversion gesetzt wird (wer allerdings mit dem FILTER-feature arbeiten will, muss das immer - also auch künftig - auf diesem Weg machen).

[zife]

Ok, alles klar - dann lag's doch nicht an mir    Aber in der Tat ein Stolperstein, den man ggf. beim Feintuning in den Erklärtext aufnehmen könnte.

Ebenso aufgefallen ist mir, dass ich in der Dropdown-Liste der Attribute 2x die Überschrift archetype habe, einmal ganz oben mit zahlreichen Attributen, und dann viel weiter unten nochmal, nur mit "actual_userReadings" und "attributesExclude".
Noch dazu hab ich dann NOCH eine Überschrift, nämlich device userattr, und dort steht "actual_event-on-change-reading".
Bissl unübersichtlich 

PS: das sind genau meine beiden Test-Readings - userReadings und event-on-change-reading.

So lange ich also noch nichts zur Logik des Moduls beitragen kann, nörgel ich erstmal am Frontend rum 

Aber die Idee hinter dem Modul ist grandios... nur die Einstiegshürde ist hoch, man muss erstmal den "Hirn-Zugang" bekommen. Ich erklär mich gern bereit, am Ende einen möglichst Anfänger-tauglichen Commandref-Text zu schreiben. Also für das, was ich selbst verstehe 

[Beta-User]

Ok, alles klar - dann lag's doch nicht an mir    Aber in der Tat ein Stolperstein, den man ggf. beim Feintuning in den Erklärtext aufnehmen könnte.

...diese Art Fragen sind schon im "Ur-Thread" zu dem Modul hochgekommen. Die dortige Aufforderung, konkrete Verbesserungsvorschläge für die commandref zu machen, ist leider bis zum heutigen Tag nicht von User-Seite aufgegriffen worden (afaik)...

Ebenso aufgefallen ist mir, dass ich in der Dropdown-Liste der Attribute 2x die Überschrift archetype habe, einmal ganz oben mit zahlreichen Attributen, und dann viel weiter unten nochmal, nur mit "actual_userReadings" und "attributesExclude".

Diese Unterteilung kommt von FHEMWEB: "actual_userReadings" (bzw. was vergleichbares) wird bei mir unter "userattr" angezeigt, und "attributesExclude" ist  ein globales Attribut, das durch archetype als "seines" reklamiert wird (wg. der Doku); das ist bei allen Geräten verfügbar, wenn ich es richtig verstanden habe, kann man damit einzelne Devices von der Vererbung der gelisteten Attribute ausschließen .

Bissl unübersichtlich 
So lange ich also noch nichts zur Logik des Moduls beitragen kann, nörgel ich erstmal am Frontend rum 

Funktional halt leider erforderlich, und es ist mit der dev-Version schon etwas besser als früher (glaube ich zumindest).

Aber die Idee hinter dem Modul ist grandios... nur die Einstiegshürde ist hoch, man muss erstmal den "Hirn-Zugang" bekommen. Ich erklär mich gern bereit, am Ende einen möglichst Anfänger-tauglichen Commandref-Text zu schreiben. Also für das, was ich selbst verstehe 

Mir hat die Idee auch "schon immer" gefallen, allerdings hatte ich früher auch immer das "Problem", dass mir zwar klar war, dass das irgendwie helfen könnte, aber nicht konkret, wie...

Und später, wenn man devspec "kann", ist es nicht mehr in dem Maß hilfreich wie ganz am Anfang (wo man noch nicht weiß, was überhaupt sinnvoll ist). Typisches "Henne-Ei"-Problem...

Hoffe, mit etwas "Werbung" wird das besser, weil auch kaum einer das Modulchen wirklich kennt bzw. im Einsatz hat.

PS: V.A. das feature, dass "Initialwerte" direkt beim Definieren passender Geräte gesetzt werden, ist m.E. richtig cool und der wahre Vorteil gg. anderen Lösungen wie z.B. dem "template"-Kommando.

[Beta-User]

Hallo zusammen,

im Anhang des ersten Posts gibt es ein update, wobei das ausschließlich die commandref betrifft. Ich hoffe sehr, dass die jüngsten Modifikationen dazu beitragen, die Idee hinter dem Modul auch für Einsteiger etwas transparenter zu machen und die Anwendung zu vereinfachen.

Mein Plan wäre, das im Fall, dass die kommenden Tage keine Probleme mehr auftauchen, dann bei Gelegenheit mal einzuchecken.

Wer also Sorgen hat, möge bitte rechtzeitig von der Option Gebrauch machen, das Modul auf "exclude_from_update" zu setzen.

Was den "speziellen Modus" derive attributes angeht, bin ich immer noch nicht komplett dahinter gestiegen, was das (außer der Option, darüber globale user-Attribute zu setzen) für Vorteile hat und finde auch die in der commandref weiter beschriebene "zusätzliche" Option mit den "actual_.*"-Attributen irreführend, weil das auch mit jedem "normalen" archetype ohne weiteres klappt (jetzt sogar mit Filterung). Mal schauen, ob das noch rausfällt, oder mir jemand verklickert, dass und wie ich da falsch liege...

[Beta-User]

Mein Plan wäre, das im Fall, dass die kommenden Tage keine Probleme mehr auftauchen, dann bei Gelegenheit mal einzuchecken.

Done!

[Florian_GT]

Hallo,

leider bin ich eine der Personen, die diese Warnung erst nach dem Update gelesen hat. Jetzt funktioniert bei mir natürlich (aufgrund intensiver Nutzung des Modules) ein Großteil meiner Devices nicht mehr. Ich habe die neue Command Ref überflogen, kann jedoch nicht sehen was sich nun konkret geändert hat, und warum meine Konfiguration nicht mehr funktioniert.

Hier ein Beispiel:

Code Auswählen Erweitern


define dev_tasmota_rgbww_1192 MQTT2_DEVICE
attr dev_tasmota_rgbww_1192 archetypeFilter TASMOTA-RGBWW
attr dev_tasmota_rgbww_1192 alias RGBW - Licht - Wohnzimmer - Fenster - rechts
attr dev_tasmota_rgbww_1192 room Wohnzimmer
attr dev_tasmota_rgbww_1192 group Global-RGB
attr dev_tasmota_rgbww_1192 deviceID 1192

define dev_tasmota_rgbww_0111 MQTT2_DEVICE
attr dev_tasmota_rgbww_0111 archetypeFilter TASMOTA-RGBWW
attr dev_tasmota_rgbww_0111 alias RGBW - Licht - Wohnzimmer - Fenster - links
attr dev_tasmota_rgbww_0111 room Wohnzimmer
attr dev_tasmota_rgbww_0111 group Global-RGB
attr dev_tasmota_rgbww_0111 deviceID 0111


##################
# EXAMPLE - RGBW #
##################
define archetype_tasmota_rgbw archetype TYPE=MQTT2_DEVICE:FILTER=archetypeFilter=TASMOTA-RGBW
attr archetype_tasmota_rgbw userattr userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbw IODev mqtt2server
attr archetype_tasmota_rgbw devStateIcon {\
  if(ReadingsVal("$name","White","error") eq "0"){\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"rgb","RGBColor","Dimmer","state"));;;;\
  }else{\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"dimmer","","White","state"));;;;\
  }\
}
attr archetype_tasmota_rgbw event-min-interval (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result):1800
attr archetype_tasmota_rgbw event-on-change-reading (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result)
attr archetype_tasmota_rgbw DbLogInclude state
attr archetype_tasmota_rgbw group RGB-Einzeln
attr archetype_tasmota_rgbw icon light_led_stripe_rgb
attr archetype_tasmota_rgbw jsonMap POWER:state
attr archetype_tasmota_rgbw lightSceneParamsToSave {if(ReadingsVal($DEVICE,"state","error") eq "ON"){if(ReadingsVal($DEVICE, "White", "error") eq "0"){"RGBColor,Dimmer"}else{"White"}}else{"state"}}
attr archetype_tasmota_rgbw retain 1
attr archetype_tasmota_rgbw actual_setList\
  OFF:noArg /gosund_%deviceID%/cmnd/POWER 0\
  ON:noArg /gosund_%deviceID%/cmnd/POWER 1\
  RGBColor:colorpicker,RGB /gosund_%deviceID%/cmnd/Color2\
  Dimmer:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/Dimmer\
  White:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/White\
  Fade:0 /gosund_%deviceID%/cmnd/Fade 0\
  Fade:1 /gosund_%deviceID%/cmnd/Fade 1\
  Speed:1-10 /gosund_%deviceID%/cmnd/Speed
attr archetype_tasmota_rgbw actual_readingList \
  /gosund_%deviceID%/tele/LWT:.* precence\
  /gosund_%deviceID%/tele/STATUS(2|5|11):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/INFO(1|2|3):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/POWER:.* state
attr archetype_tasmota_rgbw useSetExtensions 1
attr archetype_tasmota_rgbw webCmd RGBColor:Dimmer:White:RGBColor ffffff:RGBColor ff0000:RGBColor 00ff00:RGBColor 0000ff:ON:OFF
attr archetype_tasmota_rgbw widgetOverride Dimmer:colorpicker,BRI,0,1,80 White:colorpicker,BRI,0,1,80 RGBColor:colorpicker,RGB
attr archetype_tasmota_rgbw setStateList ON OFF
attr archetype_tasmota_rgbw userReadings RGBColor {\
  my $color = ReadingsVal($name,"Color","error");;;;\
  $color =~ /([0-9a-fA-F]{6})/;;;;\
  return($1||"error");;;;\
}
attr archetype_tasmota_rgbw stateFormat\
1:precence\
2:state
attr archetype_tasmota_rgbw actual_readingsWatcher 900,,state
#SELF
attr archetype_tasmota_rgbw room System
attr archetype_tasmota_rgbw attributes userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbw attributesExclude attributes attributesExclude room
#attr archetype_tasmota_rgbw delteAttributes 0
#attr archetype_tasmota_rgbw defined_by archetype.archetype_tasmota_rgbw



Daraus entsteht dann normalerweise:

Code Auswählen Erweitern


define dev_tasmota_rgbww_1192 MQTT2_DEVICE
setuuid dev_tasmota_rgbww_1192 629beee5-f33f-1a24-74f1-ad4b7b3e42e427fe
attr dev_tasmota_rgbww_1192 userattr DbLogExclude DbLogInclude IODev actual_readingList actual_setList devStateIcon event-min-interval event-on-change-reading icon jsonMap lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 readingList readingsWatcher retain setList setStateList stateFormat useSetExtensions userReadings webCmd widgetOverride
attr dev_tasmota_rgbww_1192 DbLogInclude state
attr dev_tasmota_rgbww_1192 IODev mqtt2server
attr dev_tasmota_rgbww_1192 alias RGBW - Licht - Wohnzimmer - Fenster - rechts
attr dev_tasmota_rgbww_1192 archetypeFilter TASMOTA-RGBWW
attr dev_tasmota_rgbww_1192 devStateIcon {\
  if(ReadingsVal("$name","White","error") eq "0"){\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"rgb","RGBColor","Dimmer","state"));;\
  }else{\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"dimmer","","White","state"));;\
  }\
}
attr dev_tasmota_rgbww_1192 deviceID 1192
attr dev_tasmota_rgbww_1192 event-min-interval (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result):1800
attr dev_tasmota_rgbww_1192 event-on-change-reading (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result)
attr dev_tasmota_rgbww_1192 group RGB-Einzeln
attr dev_tasmota_rgbww_1192 icon light_led_stripe_rgb
attr dev_tasmota_rgbww_1192 jsonMap POWER:state
attr dev_tasmota_rgbww_1192 lightSceneParamsToSave {if(ReadingsVal($DEVICE,"state","error") eq "ON"){if(ReadingsVal($DEVICE, "White", "error") eq "0"){"RGBColor,Dimmer"}else{"White,CT"}}else{"state"}}
attr dev_tasmota_rgbww_1192 readingList /gosund_1192/tele/LWT:.* precence\
  /gosund_1192/tele/STATUS(2|5|11):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/tele/INFO(1|2|3):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/stat/POWER:.* state
attr dev_tasmota_rgbww_1192 retain 1
attr dev_tasmota_rgbww_1192 room Wohnzimmer
attr dev_tasmota_rgbww_1192 setList OFF:noArg /gosund_1192/cmnd/POWER 0\
  TOGGLE:noArg /gosund_1192/cmnd/TOGGLE\
  ON:noArg /gosund_1192/cmnd/POWER 1\
  RGBColor:colorpicker,RGB /gosund_1192/cmnd/Color2\
  Dimmer:colorpicker,BRI,0,5,80 /gosund_1192/cmnd/Dimmer\
  White:colorpicker,BRI,0,5,80 /gosund_1192/cmnd/White\
  CT:colorpicker,CT /gosund_1192/cmnd/CT\
  Fade:0 /gosund_1192/cmnd/Fade 0\
  Fade:1 /gosund_1192/cmnd/Fade 1\
  Speed:1-10 /gosund_1192/cmnd/Speed
attr dev_tasmota_rgbww_1192 setStateList ON OFF
attr dev_tasmota_rgbww_1192 stateFormat 1:precence\
2:state
attr dev_tasmota_rgbww_1192 useSetExtensions 1
attr dev_tasmota_rgbww_1192 userReadings RGBColor {\
  my $color = ReadingsVal($name,"Color","error");;\
  $color =~ /([0-9a-fA-F]{6})/;;\
  return($1||"error");;\
}
attr dev_tasmota_rgbww_1192 webCmd RGBColor:Dimmer:White:CT:RGBColor ffffff:RGBColor ff0000:RGBColor 00ff00:RGBColor 0000ff:ON:OFF
attr dev_tasmota_rgbww_1192 widgetOverride Dimmer:colorpicker,BRI,0,1,100 White:colorpicker,BRI,0,1,100 RGBColor:colorpicker,RGB CT:colorpicker,CT,153,1,500


[Beta-User]

Moin, ich schau's mir im Lauf der kommenden Woche mal näher an, was da das Problem sein könnte.

[Beta-User]

Eine Frage: Wie "rollst" du das archetype aus? Falls du den "clean"-command (z.B. iVm. einem FHEM-start-Event-Handler) in Verwendung hast: bitte mal in "archetype clean" ändern.

[Florian_GT]

Eine Frage: Wie "rollst" du das archetype aus? Falls du den "clean"-command (z.B. iVm. einem FHEM-start-Event-Handler) in Verwendung hast: bitte mal in "archetype clean" ändern.

ich deploy meine FHEM Instanz mit Chef als Automatisierung, ähnliche Ansible und zukünftig wird es Docker. Das bedeutet, die Archetype wird bei Runtime ausgeführt. Deshalb habe ich bei den RGB Devices auch nur ein paar wenige Zeilen, die dann bei Fhem Start oder Restart ergänzt werden.

Ich habe jetzt gestern natürlich erst einmal ein Roleback gemacht, ich habe aber auch eine Test Instanz, dort werde ich dass dann mal in Ruhe testen...

Im Log beim starten sieht das übrigens so mit dem alten Module aus:

Code Auswählen Erweitern

2022.06.05 01:46:45.357 1: Including ./conf/sub_configuration/fhem.cfg-DEV-TASMOTA
2022.06.05 01:46:45.513 3: archetype (archetype_tasmota_rgbw) - starting inheritance inheritors
2022.06.05 01:46:45.530 3: archetype (archetype_tasmota_rgbw) - inheritance inheritors done
2022.06.05 01:46:45.538 3: archetype (archetype_tasmota_rgbww) - starting inheritance inheritors
2022.06.05 01:46:45.557 3: archetype (archetype_tasmota_rgbww) - inheritance inheritors done
2022.06.05 01:46:45.563 3: archetype (archetype_tasmota_power) - starting inheritance inheritors
2022.06.05 01:46:45.626 3: archetype (archetype_tasmota_power) - inheritance inheritors done
2022.06.05 01:46:45.631 3: archetype (archetype_tasmota_smokedetector) - starting inheritance inheritors
2022.06.05 01:46:45.637 3: archetype (archetype_tasmota_doorswitch) - starting inheritance inheritors
2022.06.05 01:46:45.655 3: archetype (archetype_tasmota_doorswitch) - inheritance inheritors done
2022.06.05 01:46:45.656 1: Including ./conf/sub_configuration/fhem.cfg-DEV-ESPEASY
2022.06.05 01:46:45.676 3: archetype (archetype_espeasy_bme280) - starting inheritance inheritors
2022.06.05 01:46:45.703 3: archetype (archetype_espeasy_bme280) - inheritance inheritors done
2022.06.05 01:46:45.704 1: Including ./conf/sub_configuration/fhem.cfg-LUEFTEN
2022.06.05 01:46:45.790 1: Including ./conf/sub_configuration/fhem.cfg-TELEGRAM


Ach und mir fällt gerade noch ein, ich habe einige Attribute in der Global definiert, wie z.B. DeviceID:

Code Auswählen Erweitern

attr global userattr archetypeFilter readingsWatcher actual_readingList actual_devicetopic actual_setList taupunktlimitdiff deviceID DbLogExclude DbLogInclude DbLogValueFn:textField-long alarmDevice:Actor,Sensor alarmSettings cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue sortby structexclude webCmd webCmdLabel:textField-long widgetOverrid widgetOverride

[Beta-User]

Was steht denn in der

Code Auswählen Erweitern

2022.06.05 01:46:45.357 1: Including ./conf/sub_configuration/fhem.cfg-DEV-TASMOTA
usw.?
Falls da der "clear"-Befehl aufgerufen wird, muss das für die neue Syntax einfach angepaßt werden...

[Florian_GT]

Was steht denn in der

Code Auswählen Erweitern

2022.06.05 01:46:45.357 1: Including ./conf/sub_configuration/fhem.cfg-DEV-TASMOTA
usw.?
Falls da der "clear"-Befehl aufgerufen wird, muss das für die neue Syntax einfach angepaßt werden...

Dort steht kein clear Befehl drin, dort steht nur drin, was ich oben Beispielweise am RGBW auch schon gepostet habe.

[Beta-User]

OK, jetzt bin ich dahintergestiegen, was das Problem ist/war:

So, hier also mal eine erste Lautmeldung und gleich eine Ladung Fragezeichen...

[...]
Hintergrund dazu ist der, dass mir der Gedanke, dass ein "archetype clean" wirklich immer alles "aufräumt", ist mir noch unheimlich; bin am Überlegen, ob es ein Attribut geben sollte, mit dem man selektiv ausschalten kann, ohne ganz gleich "disable" zu verwenden.

Gab es einen Grund, warum beim Setzen der Attribute vor $init_done weiterer Code aufgerufen wurde?

Ich finde es weiterhin ausgesprochen "schräg", Attribute vor Abschluss der FHEM-Initialisierung irgendwas ausführen zu lassen. Das wird also nur dann wiederkommen, wenn es wirklich triftige Gründe dafür gäbe.

Bei der jetzigen Durchsicht sind mir dann aber auch noch ein paar weitere "Problemchen" mit dem (scheinbar von niemandem genutzten!) "clean"-Befehl aufgefallen, anbei daher eine aktualisierte Fassung, ich gedenke die zeitnah einzuchecken.

Mit der Version funktioniert zum einen dann "archetype clean" wieder, zum anderen gibt es ein neues Attribut "autoclean_init", mit dem man zum Abschluss der FHEM-Initialisierung (also bei "global:INITIALIZED") dann selektiv einzelne archetype "anschalten" kann.

@Florian_GT: Deine Problemlage sollte sich durch das pauschale "clean" im Rahmen eines "INITIALIZED"-Eventhandlers lösen lassen.

PS:
In deinem Beispiel sind ein paar Attribute dabei, die noch von MQTT_DEVICE herrühren, und das archetype-devspec paßt nicht 100% auf die beiden Muster-Devices.
Edit: ist im svn.

[Florian_GT]

OK, jetzt bin ich dahintergestiegen, was das Problem ist/war:Ich finde es weiterhin ausgesprochen "schräg", Attribute vor Abschluss der FHEM-Initialisierung irgendwas ausführen zu lassen. Das wird also nur dann wiederkommen, wenn es wirklich triftige Gründe dafür gäbe.

Bei der jetzigen Durchsicht sind mir dann aber auch noch ein paar weitere "Problemchen" mit dem (scheinbar von niemandem genutzten!) "clean"-Befehl aufgefallen, anbei daher eine aktualisierte Fassung, ich gedenke die zeitnah einzuchecken.

Mit der Version funktioniert zum einen dann "archetype clean" wieder, zum anderen gibt es ein neues Attribut "autoclean_init", mit dem man zum Abschluss der FHEM-Initialisierung (also bei "global:INITIALIZED") dann selektiv einzelne archetype "anschalten" kann.

@Florian_GT: Deine Problemlage sollte sich durch das pauschale "clean" im Rahmen eines "INITIALIZED"-Eventhandlers lösen lassen.

PS:
In deinem Beispiel sind ein paar Attribute dabei, die noch von MQTT_DEVICE herrühren, und das archetype-devspec paßt nicht 100% auf die beiden Muster-Devices.
Edit: ist im svn.

Also wann dann etwas ausgeführt wird oder nicht kann ich so nicht einschätzen, dafür bin ich nicht weit genug in FHEM drin. Fakt ist halt, wenn ich ein neues Device so wie oben angegeben konfiguriere, dann soll halt bei start oder neustart von FHEM automatisch alles weitere gesetzt werden. Wenn ich dafür noch ein weiteren Parameter an dem archetype setzen muss, auch ok, aber darüber hinaus sollte alles weitere in Hintergrund automatisch passieren. So war das von dem Module gedacht.

Und ja, sorry, du hast recht, ich habe dir da das falsche Template kopiert:

Code Auswählen Erweitern


###################
# EXAMPLE - RGBWW #
###################
define archetype_tasmota_rgbww archetype TYPE=MQTT2_DEVICE:FILTER=archetypeFilter=TASMOTA-RGBWW
attr archetype_tasmota_rgbww userattr userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbww IODev mqtt2server
attr archetype_tasmota_rgbww devStateIcon {\
  if(ReadingsVal("$name","White","error") eq "0"){\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"rgb","RGBColor","Dimmer","state"));;;;\
  }else{\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"dimmer","","White","state"));;;;\
  }\
}
attr archetype_tasmota_rgbww event-min-interval (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result):1800
attr archetype_tasmota_rgbww event-on-change-reading (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result)
attr archetype_tasmota_rgbww DbLogInclude state
attr archetype_tasmota_rgbww group RGB-Einzeln
attr archetype_tasmota_rgbww icon light_led_stripe_rgb
attr archetype_tasmota_rgbww jsonMap POWER:state
attr archetype_tasmota_rgbww lightSceneParamsToSave {if(ReadingsVal($DEVICE,"state","error") eq "ON"){if(ReadingsVal($DEVICE, "White", "error") eq "0"){"RGBColor,Dimmer"}else{"White,CT"}}else{"state"}}
attr archetype_tasmota_rgbww retain 1
attr archetype_tasmota_rgbww actual_setList\
  OFF:noArg /gosund_%deviceID%/cmnd/POWER 0\
  TOGGLE:noArg /gosund_%deviceID%/cmnd/TOGGLE\
  ON:noArg /gosund_%deviceID%/cmnd/POWER 1\
  RGBColor:colorpicker,RGB /gosund_%deviceID%/cmnd/Color2\
  Dimmer:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/Dimmer\
  White:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/White\
  CT:colorpicker,CT /gosund_%deviceID%/cmnd/CT\
  Fade:0 /gosund_%deviceID%/cmnd/Fade 0\
  Fade:1 /gosund_%deviceID%/cmnd/Fade 1\
  Speed:1-10 /gosund_%deviceID%/cmnd/Speed
attr archetype_tasmota_rgbww actual_readingList \
  /gosund_%deviceID%/tele/LWT:.* precence\
  /gosund_%deviceID%/tele/STATUS(2|5|11):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/INFO(1|2|3):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/POWER:.* state
attr archetype_tasmota_rgbww useSetExtensions 1
attr archetype_tasmota_rgbww webCmd RGBColor:Dimmer:White:CT:RGBColor ffffff:RGBColor ff0000:RGBColor 00ff00:RGBColor 0000ff:ON:OFF
attr archetype_tasmota_rgbww widgetOverride Dimmer:colorpicker,BRI,0,1,100 White:colorpicker,BRI,0,1,100 RGBColor:colorpicker,RGB CT:colorpicker,CT,153,1,500
attr archetype_tasmota_rgbww setStateList ON OFF
attr archetype_tasmota_rgbww userReadings RGBColor {\
  my $color = ReadingsVal($name,"Color","error");;;;\
  $color =~ /([0-9a-fA-F]{6})/;;;;\
  return($1||"error");;;;\
}
attr archetype_tasmota_rgbww stateFormat\
1:precence\
2:state
attr archetype_tasmota_power actual_readingsWatcher 900,,state
#SELF
attr archetype_tasmota_rgbww room System
attr archetype_tasmota_rgbww attributes userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbww attributesExclude attributes attributesExclude room
attr archetype_tasmota_rgbww autoclean_init 1
#attr archetype_tasmota_rgbww delteAttributes 0
#attr archetype_tasmota_rgbww defined_by archetype.archetype_tasmota_rgbww


Was genau muss ich jetzt anpassen damit es wieder wie vorher funktioniert? Muss ich dass autoclean_init im archetype setzen? EDIT: Schon gelesen in der Doku dass es damit dann geht, sehr schön!

EDIT:
Fix einmal getestet und tut auch wieder wie vorher:

Code Auswählen Erweitern

2022.06.09 00:50:21.783 3: archetype (archetype_tasmota_doorswitch) - starting inheritance (initial autoclean )
2022.06.09 00:50:21.826 3: archetype (archetype_tasmota_doorswitch) - inheritance inheritors done
2022.06.09 00:50:21.826 3: archetype (archetype_tasmota_power) - starting inheritance (initial autoclean )
2022.06.09 00:50:21.979 3: archetype (archetype_tasmota_power) - inheritance inheritors done
2022.06.09 00:50:21.979 3: archetype (archetype_tasmota_rgbw) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.017 3: archetype (archetype_tasmota_rgbw) - inheritance inheritors done
2022.06.09 00:50:22.018 3: archetype (archetype_tasmota_rgbww) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.074 3: archetype (archetype_tasmota_rgbww) - inheritance inheritors done
2022.06.09 00:50:22.075 3: archetype (archetype_tasmota_smokedetector) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.077 3: archetype (archetype_zigbee_heating) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.148 3: archetype (archetype_zigbee_heating) - inheritance inheritors done


Danke

[Beta-User]

Was genau muss ich jetzt anpassen damit es wieder wie vorher funktioniert? Muss ich dass autoclean_init im archetype setzen? EDIT: Schon gelesen in der Doku dass es damit dann geht, sehr schön!

Na ja, meine Anregung war eigentlich gewesen, das "pauschal" via global-INITIALIZED-Eventhandler zu machen:

Code Auswählen Erweitern

defmod initialArchetypeClean notify global:INITIALIZED|global:REREADCFG archetype clean

Die andere Variante wäre, das "archetype clean" ans Ende der fhem.cfg zu schreiben (@all: Cool bleiben, s.u.).

Aber natürlich geht es auch, das über die Aktivierung des Attributs im Einzeldevice zu machen. Es gibt aber dennoch ein paar Unterschiede zum vorherigen Verhalten, die ich an der Stelle gerne nochmal erläutere. Dann wird ggf. auch klarer, warum das bisherige Verhalten m.E. zwingend geändert werden musste...

Der eigentliche (früher auch vor $init_done angewendete) trigger, damit das archetype seine Arbeit tut, war/ist das "attributes"-Attribut. Das findet sich bei deinen Definitionen nicht zufällig ziemlich am Ende der Definition (das darauf folgende dürfte übrigens wirkungslos sein!). Das ist aber nicht der Ort, an dem fhem.pl das "freiwillig" abspeichern würde ("list -r archetype_tasmota_rgbw" würde zeigen, wie das "manipulationsfrei" aussähe).
Ergo funktioniert deine ganze Konstruktion nur
- wenn die Reihenfolge der define-Anweisungen "korrekt" ist (erst alle zu ändernden Devices, dann das archetype), und
- die Reihenfolge der Attribute in der cfg bei diesem archetype ebenfalls paßt.
Sowas bekommen nur 100%-cfg-Editierer hin (und selbst die müssen aufpassen, dass das "vercodete Wissen" zu dem Zeitpnkt präsent ist, zu dem sie die nächste Änderung machen, ein "save" ist jedenfalls "nogo-Zone"...)

Jetzt ist es so, dass archetype (unabhängig davon, ob es via Einzel-Attribut oder INITIALIZED-notify erfolgt) erst aktiv ist, wenn $init_done wahr (bzw. korrekt: 1) ist, also:
- die ganze fhem.cfg gelesen ist (alle defines + Attribute sind bekannt), und
- die statefile ist gelesen (alle alten Reading-Werte sind bekannt).

Es gibt dabei aber einen Haken: ab $init_done sind auch alle Dispatch-Funktionen usw. bereits aktiv, es werden also z.B. alle eingehenden MQTT-Nachrichten verteilt. Es könnte also passieren, dass eine eingehende Nachricht auf ein noch nicht "fertig konfiguriertes" Device trifft und dann "falsch" interpretiert wird (also ggf. einfach anders als mit der angepaßten readingList).

Will man das als "echter cfg-Editierer" vermeiden, kann man den "archetype clean"-Befehl eben ans Ende der cfg setzen. Dann wird der "zum richtigen Zeitpunkt" ausgeführt, also _vor $init_done_. Aus dem vorstehenden ergibt sich: sowas macht m.E. nur für "100%-cfg-Editierer" Sinn, der Rest sollte bitte einfach die "notwendigen" Attribute (also in meinem Beispiel v.a. die readingList) so in der cfg anspeichern, dass das paßt und "archetype" dann dazu nutzen, abweichende Konfigurationen "einzufangen" und/oder direkt bei Neudefinition eines Devices "passende" Attribute zu setzen.

Hoffe, das ist jetzt etwas klarer?

[Florian_GT]

Na ja, meine Anregung war eigentlich gewesen, das "pauschal" via global-INITIALIZED-Eventhandler zu machen:

Code Auswählen Erweitern

defmod initialArchetypeClean notify global:INITIALIZED|global:REREADCFG archetype clean

Die andere Variante wäre, das "archetype clean" ans Ende der fhem.cfg zu schreiben (@all: Cool bleiben, s.u.).

Aber natürlich geht es auch, das über die Aktivierung des Attributs im Einzeldevice zu machen. Es gibt aber dennoch ein paar Unterschiede zum vorherigen Verhalten, die ich an der Stelle gerne nochmal erläutere. Dann wird ggf. auch klarer, warum das bisherige Verhalten m.E. zwingend geändert werden musste...

Der eigentliche (früher auch vor $init_done angewendete) trigger, damit das archetype seine Arbeit tut, war/ist das "attributes"-Attribut. Das findet sich bei deinen Definitionen nicht zufällig ziemlich am Ende der Definition (das darauf folgende dürfte übrigens wirkungslos sein!). Das ist aber nicht der Ort, an dem fhem.pl das "freiwillig" abspeichern würde ("list -r archetype_tasmota_rgbw" würde zeigen, wie das "manipulationsfrei" aussähe).
Ergo funktioniert deine ganze Konstruktion nur
- wenn die Reihenfolge der define-Anweisungen "korrekt" ist (erst alle zu ändernden Devices, dann das archetype), und
- die Reihenfolge der Attribute in der cfg bei diesem archetype ebenfalls paßt.
Sowas bekommen nur 100%-cfg-Editierer hin (und selbst die müssen aufpassen, dass das "vercodete Wissen" zu dem Zeitpnkt präsent ist, zu dem sie die nächste Änderung machen, ein "save" ist jedenfalls "nogo-Zone"...)

Jetzt ist es so, dass archetype (unabhängig davon, ob es via Einzel-Attribut oder INITIALIZED-notify erfolgt) erst aktiv ist, wenn $init_done wahr (bzw. korrekt: 1) ist, also:
- die ganze fhem.cfg gelesen ist (alle defines + Attribute sind bekannt), und
- die statefile ist gelesen (alle alten Reading-Werte sind bekannt).

Es gibt dabei aber einen Haken: ab $init_done sind auch alle Dispatch-Funktionen usw. bereits aktiv, es werden also z.B. alle eingehenden MQTT-Nachrichten verteilt. Es könnte also passieren, dass eine eingehende Nachricht auf ein noch nicht "fertig konfiguriertes" Device trifft und dann "falsch" interpretiert wird (also ggf. einfach anders als mit der angepaßten readingList).

Will man das als "echter cfg-Editierer" vermeiden, kann man den "archetype clean"-Befehl eben ans Ende der cfg setzen. Dann wird der "zum richtigen Zeitpunkt" ausgeführt, also _vor $init_done_. Aus dem vorstehenden ergibt sich: sowas macht m.E. nur für "100%-cfg-Editierer" Sinn, der Rest sollte bitte einfach die "notwendigen" Attribute (also in meinem Beispiel v.a. die readingList) so in der cfg anspeichern, dass das paßt und "archetype" dann dazu nutzen, abweichende Konfigurationen "einzufangen" und/oder direkt bei Neudefinition eines Devices "passende" Attribute zu setzen.

Hoffe, das ist jetzt etwas klarer?

Ja jetzt verstehe ich was du meinst. Ein paar Hinweise zum Module und dann sollte das so passen.

[Beta-User]

Ein paar Hinweise zum Module und dann sollte das so passen.

Weiß nicht so recht, was du mir damit sagen willst? Welche Hinweise?

M.E. war das bisherige Verhalten einfach "weird", und bisher bist du der erste, der sich überhaupt dazu gemeldet hat (meine Frage, ob das irgendeinen tieferen Sinn hat, hängt ja schon lange im Raum...).

Da cfg-Editieren eh in die Kategorie "not recommended" (für nicht-Spezialisten) gehört, werde ich nicht hergehen und noch irgendwo sonst erklären, wie man das ggf. hinbiegt...
(mit configDB geht es eh' nicht, Befehle direkt in die cfg zu schreiben, und auch die Reihenfolge der "normalen" Attribute kann man afaik nicht wirklich beeinflussen).

[Florian_GT]

Weiß nicht so recht, was du mir damit sagen willst? Welche Hinweise?

M.E. war das bisherige Verhalten einfach "weird", und bisher bist du der erste, der sich überhaupt dazu gemeldet hat (meine Frage, ob das irgendeinen tieferen Sinn hat, hängt ja schon lange im Raum...).

Da cfg-Editieren eh in die Kategorie "not recommended" (für nicht-Spezialisten) gehört, werde ich nicht hergehen und noch irgendwo sonst erklären, wie man das ggf. hinbiegt...
(mit configDB geht es eh' nicht, Befehle direkt in die cfg zu schreiben, und auch die Reihenfolge der "normalen" Attribute kann man afaik nicht wirklich beeinflussen).

Hm, jetzt weiß ich leider auch nicht mehr, welche Hinweise ich meinte. Möglicherweise deine Erklärung weiter oben im cmdref. Ja, mag wenige geben die dieses Module in Verbindung mit manuellen Editieren an den cfg. nutzen. Ich für meinen Teil mache das aber gerne in vsc. Und habe auch gleich eine Versionierung in Git. Und durch das Module auch weniger Attribute. Die ganzen anderen Attribute werden automatisch vergeben und anders ist es auch nicht notwendig. Zumindest aus meiner Sicht.

Gruß Florian