[archetype] - support Thread ab 2022

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

Vorheriges Thema - Nächstes Thema

Benni

Zitat von: Beta-User am 11 Februar 2022, 17:42:04
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...

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

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


prefix[relation]suffix

(Eckige klammern kenn ich doch woher ...  ??? )

oder

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:
Zitat von: Benni am 11 Februar 2022, 20:46:33
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.

Zitat von: Benni am 11 Februar 2022, 21:52:43
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...!

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

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

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

#19
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:
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:
appOptions.*:textField-long

Der archetype:
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:
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...
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

Mist! Mein Produktiv-System ist wohl zu alt! :)

Wollte den Spielplatz dorthin verlagern und habe mein FHEM gekillt

Zitat
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

Zitat von: Benni am 19 Februar 2022, 14:28:00
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...

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

#22
Zitat von: Beta-User am 12 Februar 2022, 17:26:36
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):
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:
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.
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

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...
RolladenArchetype1: bad attribute name 'actual_.+' (allowed chars: A-Za-z/\d_\.-)

;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...
fhem mit EnOcean, Gardena, Vorwerk, Miele und Teufel/Raumfeld-Integration... nur meine Kinder wollen sich damit nicht anständig steuern lassen. Wer weiß Rat?

Beta-User

Zitat von: zife am 25 Februar 2022, 14:38:36
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)

Zitat von: zife am 25 Februar 2022, 14:38:36
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...
RolladenArchetype1: bad attribute name 'actual_.+' (allowed chars: A-Za-z/\d_\.-)

;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: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
attr RolladenArchetype1 attributes userReadings
würde das dann zur Verteilung an die der devspec entsprechenden Geräte vorgesehen.
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

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  8)

fhem mit EnOcean, Gardena, Vorwerk, Miele und Teufel/Raumfeld-Integration... nur meine Kinder wollen sich damit nicht anständig steuern lassen. Wer weiß Rat?

Beta-User

Zitat von: zife am 25 Februar 2022, 14:59:34
Sorry, für den Moment ist das wohl noch keine große Tester-Hilfe, aber kommt schon noch  8)
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.

Zitat von: zife am 25 Februar 2022, 14:59:34
(und es vererbt sich auch hübsch bei "set RolladenArchetype inheritance".
...das ist doch schon mal was. Modul prinzipiell verstanden, alles gut ;D .

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

zife

#27
Ok, alles klar - dann lag's doch nicht an mir  8)  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  :P

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  ;D

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  :o
fhem mit EnOcean, Gardena, Vorwerk, Miele und Teufel/Raumfeld-Integration... nur meine Kinder wollen sich damit nicht anständig steuern lassen. Wer weiß Rat?

Beta-User

Zitat von: zife am 25 Februar 2022, 15:13:49
Ok, alles klar - dann lag's doch nicht an mir  8)  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)...

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

Zitat
Bissl unübersichtlich  :P
So lange ich also noch nichts zur Logik des Moduls beitragen kann, nörgel ich erstmal am Frontend rum  ;D
Funktional halt leider erforderlich, und es ist mit der dev-Version schon etwas besser als früher (glaube ich zumindest).

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

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