[archetype] - support Thread ab 2022

Begonnen von Beta-User, 02 Februar 2022, 04:36:36

Vorheriges Thema - Nächstes Thema

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#1
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:
define archHM1 archetype TYPE=CUL_HM:FILTER=DEF=.{6}
Als erstes sollen zwei Attribute überwacht werden, "commStInCh" und "IOgrp" - also
attr archHM1 attributes commStInCh IOgrpUm die zu setzen, muss die archetype-Instanz ggf. diese Attribute erst lernen, daher:
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
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
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  :) ;D 8) :) . (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:
Zitat von: igami am 18 Juni 2016, 14:06:11
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:
ZitatVorab 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):
attr ac2 attributes actual_temp
ergibt
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!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Zitat von: Beta-User am 04 Februar 2022, 14:06:10
CUL_HM wirft (mir) zu viele Events

Hallo Beta-User

Genau da bin ich gerade auch dran!  :D

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

#3
Zitat von: Benni am 04 Februar 2022, 16:01:17
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 :P ).

Zitat von: Benni am 04 Februar 2022, 16:01:17
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:
$msgCommand = eval($msgCommand);
fhem($msgCommand);

wird dann sowas:
  $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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#4
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 ::) ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#5
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":
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:
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 :P .

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)


Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Hallo Beta-User,

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

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.


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

Zitat von: Benni am 09 Februar 2022, 16:29:39
Das mit der Import-Funktion ist nett: Damit wird ein existierendes device quasi zum Archetyp für den archetype :D
:) 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...

Zitat
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.

Zitatderive 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?

Zitat
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?
setList="on off foo" s:state=off r:foo="das ist ein Test"

(Erst müßte man aber den Mechanismus verstehen :-[ ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#8
...es schien doch mal ein paar Beispieldefinitionen aus der dummy+code-Ära zu geben. Hier mal ein Beispiel-Satz für den RT-DN:
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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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" ;D .
- 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:
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


define dmTst1 dummy
define dmTst2 dummy
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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!


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":


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

Zitat von: Benni am 10 Februar 2022, 21:28:45
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...

Zitat
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Zitat von: Beta-User am 11 Februar 2022, 17:00:45
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 :)

Zitat
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.

Zitat
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:


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
$relation_Proxy
oder
${relation}_Proxy
statt des backslash-escape.
Also falls du eine Idee hast...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files