Define mit parameter? Warum keine Attribute z.b. bei at oder notify

Begonnen von martinp876, 03 November 2021, 17:52:45

Vorheriges Thema - Nächstes Thema

martinp876

Ich habe ein Problem mit dem Aufbau des UserInterface bswp von "at" und "notify".
Wissend, dass sich nichts ändern wird will ich es zumindest einmal zur Diskussion stellen.
Anmerkung vorab: Operationell funktioniert es einwandfrei.

Problematisch sehe ich das Define, dessen Parameter und die nicht vorhandenen Attribute.
"at" und "notify" sind nahezu identisch, nur eben timer oder event getrieben. (schade, dass "at" nicht "timer" heisst - kann man besser suchen. )
Abstrakt ist im Define
   define <name> <type> <trigger> <command>
wobei trigger und command im define nicht notwendig sind. Bestenfalls um es in einer Zeile erzeugen zu können.
Wie man an der Notwendigkeit des draufgebacken WEB interfaces zum editieren der Parameter sieht ist es keine Definition sondern eben ein Attribut.
Wären die beiden Parameter Attribute hätte man sich das komplette Web-Frontend-Add-On sparen können. Alles wäre mit Bordmitteln machbar gewesen.
Den Trigger beim Timer (also "at") hätte man aufteilen können in "time" "relative" und "cyclic". Das spart schon einmal einges an Erklärungen.
Der Trigger bei "notify" könnte in "entity" und "event" getrennt werden. Nur in wenigen sonderfällen sind komplexere Kompinationen  notwendig.

Die grundsätzliche Frage ist also, warum man attribute als parameter im Define hinein presst um sie im nächsten Schritt nicht mehr normal editieren zu können.

Das gebastelte Frontend bietet einiges - aber typisch kann ich bei notify wenig damit anfangen. Bei "at" ist es besser - wäre aber mit Attributen auch nicht schlechter.

Auf der Reading Seite ist notify auch extrem sparsam. Es wird immer ausglöst durch das Event einer Entity. Wäre es nicht sinnvoll, ein Reading "lastEntity" und "lastEvent" per default anzuzeigen?
Das letzte ausgeührte Kommando wäre auch ein Reading wert - evtl auch nur auf Anfrage.
Mit einenem Kommando "simulateEvent" kommte man das notify auch testen oder Auslösen.
natürlich sind kommandos hilfreich um die Readings zu bereinigen - damit veraltete Readings pauschal gelöscht werden können.

Perl bietet hinrechend Optionen, es doch noch passend zu machen. Aber warum ist dies Aufgabe des User?

Eine Umstellung ist technisch möglich. User müssten sich an das neue Interface gewöhnen - das Verhalten wäre aber identisch.
Allerdings mache ich mir keine Illusionen.



rudolfkoenig

ZitatDefine mit parameter? Warum keine Attribute z.b. bei at oder notify
Weil beide aus der Zeit stammen, wo noch kein define oder attr gab (beide waren Befehle), und ich habe bei der Umstellung nicht auch noch diesen Code umgebaut, der Rest war mir schon genug.

Zitatschade, dass "at" nicht "timer" heisst - kann man besser suchen.
Mag sein, ich wollte das Unix at Befehl nachbauen.
Und das Wort timer trifft die Aufgabe auch nicht wirklich.

ZitatDer Trigger bei "notify" könnte in "entity" und "event" getrennt werden. Nur in wenigen sonderfällen sind komplexere Kompinationen  notwendig.
Klar kann man alles anders bauen, und nachher ist man klueger.
Attribute haben auch ihre Probleme (siehe Initialisierung), und bequemer sind sie auch nicht unbedingt.

ZitatWäre es nicht sinnvoll, ein Reading "lastEntity" und "lastEvent" per default anzuzeigen?
Ich habe das noch nie vermisst, und bisher offensichtlich auch sonst keiner, ich habe aber nichts dagegen, sie einzubauen.

ZitatMit einenem Kommando "simulateEvent" kommte man das notify auch testen oder Auslösen.
Meinst du den trigger Befehl? Den gibts es schon seit "immer".

ZitatUser müssten sich an das neue Interface gewöhnen - das Verhalten wäre aber identisch.
Stimmt, aber diese Benutzer wuerden mich zunaechst verfluchen.
Die Frage ist, ob ich die Alten vergraule, nur um die Neuen zu verwirren, da ich die Doku nicht rueckwirkend ueberall aendern kann.

Benni

Zitat von: martinp876 am 03 November 2021, 17:52:45
Wäre es nicht sinnvoll, ein Reading "lastEntity" und "lastEvent" per default anzuzeigen?


Zitat von: rudolfkoenig am 03 November 2021, 19:10:56Ich habe das noch nie vermisst, und bisher offensichtlich auch sonst keiner, ich habe aber nichts dagegen, sie einzubauen.

Vermisst habe ich die bisher auch nicht wirklich, man kann sich bei Bedarf ja mit Log-Ausgaben weiterhelfen.
Aber dennoch finde ich das wäre nützliche Information. Vor allem auch für Anfänger, die sehen dann recht schnell, was sie mit ihrem notify so einfangen, oder eben auch nicht.

Gehört dann analog dazu eigentlich auch an watchdog ;)

gb#

Ellert

Wenn notify die Attribute readingList, setList hätte, könnte man auf die Definition eines dummy verzichten, um den <command> Teil oder vielleicht sogar den <trigger> zu parametrisieren und könnte dann mit webCmd,  webCmdLabel ein eigenes Interface gestalten.


martinp876

ZitatWenn notify die Attribute readingList, setList hätte, könnte man auf die Definition eines dummy verzichten
nun, das mache ich so. Zum Ersten wünsche ich mir aber (es wird Weihnachten - auch hier bekommt man nicht alles), dass die Erstellung eines Notify
Alt
define mytrigger notify entity:event commands
neu
define mytrigger notify
attr mytrigger trigger entity:event
attr mytrigger cmd commands

oder
define mytrigger notify
attr mytrigger trgEvent event
attr mytrigger trgEntits entity
attr mytrigger cmd commands

=> alles muss wie bisher regexp-geeignet sein.

ein "at" wäre dann
define mytimer at
attr mytimer trgTime time
attr mytimer trgRelative <Yes/No>
attr mytimer trgCyclic <Yes/No>
attr mytimer cmd commands


Nun meine Implementierung (mit alt und neu möglich), kompakt, smart und einfach zu bedienen, ein notify zu erzeugen welches folgenden genügt
- ein notify welches meine 12 Kanal FB bedient und dabei je kanal kurze und lange trigger unterscheidet
- editierbarkeit der reaktionen am Frontend ohne probleme
- übersicht ober Zustand/letzte Ereignisse, debug Optionen
=>
  define ntfy_FB12   notify  FB_.*(Short|Long).1_.*\(to.ccu\).* {$EVENT=~ m/.*(Short|Long).*/;my $aNm=$NAME.$1; $cmd = AttrVal($SELF,$aNm,"attrUndef");fhem "$cmd;setreading $SELF lastCmd $cmd;setreading $SELF lastTrig $aNm;setreading $SELF lastEvt $NAME: $EVENT;setreading $SELF state $NAME: $EVENT"}
   attr ntfy_FB12   userattr   FB_01Short FB_02Short FB_03Short FB_04Short FB_05Short FB_06Short FB_07Short FB_08Short FB_09Short FB_10Short FB_11Short FB_12Short FB_01Long FB_02Long FB_03Long FB_04Long FB_05Long FB_06Long FB_07Long FB_08Long FB_09Long FB_10Long FB_11Long FB_12Long
   attr ntfy_FB12  FB_01Long  set ScnWohn scene 21_abendLow;set ScnGarden scene 10_lookOut;set ScnFlur scene sleep
   attr ntfy_FB12  FB_01Short set ScnWohn scene 20_abend;set ScnGarden scene 60_sleep
   attr ntfy_FB12  FB_02Long  set ScnGarden scene 21_comeOff
   attr ntfy_FB12  FB_02Short set ScnGarden scene 20_comeIn;set ScnFlur scene party
   attr ntfy_FB12  FB_03Long  set ScnWohn scene 23_wellness;set pa_stereo off
   attr ntfy_FB12  FB_03Short set ScnWohn scene 22_mystic
   attr ntfy_FB12  FB_04Long  set ScnGarden scene 12_party
   attr ntfy_FB12  FB_04Short set ScnGarden scene 10_lookOut
   attr ntfy_FB12  FB_05Long  set ScnWohn scene 10_essen;set pa_stereo favoritePlay DAB_B1;set kuEspresso on-for-timer 3600
   attr ntfy_FB12  FB_05Short set pa_stereo favoritePlay DAB_B1;set kuEspresso on-for-timer 3600
   attr ntfy_FB12  FB_06Long  set ScnGarden scene 60_sleep
   attr ntfy_FB12  FB_06Short set ScnGarden scene 15_hell
   attr ntfy_FB12  FB_07Long  set ScnWohn scene 10_essen;set pa_stereo favoritePlay DAB_B1
   attr ntfy_FB12  FB_07Short set ScnWohn scene 28_hell
   attr ntfy_FB12  FB_08Long  laBusch off
   attr ntfy_FB12  FB_08Short laBusch on
   attr ntfy_FB12  FB_09Long  set comment=.*sleep.*:FILTER=level!=0 off;set pa_stereo off;set lfMuseoTop on-for-timer 240
   attr ntfy_FB12  FB_09Short set comment=.*sleep.*:FILTER=level!=0 off;set pa_stereo off
   attr ntfy_FB12  FB_10Long  laBusch off
   attr ntfy_FB12  FB_10Short laBusch on
   attr ntfy_FB12  FB_11Long  laBusch off
   attr ntfy_FB12  FB_11Short laBusch on
   attr ntfy_FB12  FB_12Long  laBusch off
   attr ntfy_FB12  FB_12Short set group=.*lightChan.*:FILTER=level!=0 off


 
ZitatReadings
     2021-11-03 21:54:47   lastCmd         set comment=.*sleep.*:FILTER=level!=0 off
     2021-11-03 21:54:47   lastEvt         FB_09: Long 1_16 (to ccu)
     2021-11-03 21:54:47   lastTrig        FB_09Long
     2021-11-03 21:54:47   state           FB_09: Long 1_16 (to ccu)

Ich denke das Konzept ist klar, evtl nicht für jedermann einfach. Hier bei den Entwicklern sollte es kein Problem sein.
Vorgehen:
A) der trigger
1) gleichförmige Trigger können zusammengefasst werden
2) entites können per regex oder liste addiert werden (entity1|entity2) oder entity.*
3) filtern der Events - sollte nur ein Event durchkommen. Aufpassen hier
B) trigger gruppieren.
1) Ich filtere short oder long aus dem Event . aNm (actionName) setzt sich zusammen aus den Entity-namen und dem reduzierten Event.
2) jedem actionName muss ein Kommando in den Attributen zugeordnet werden. Wenn nicht, eben nicht.
3) userAttr muss natürlich vorab gesetzt werden - für alle gewünschten Reaktionen.

Zusammen mit Scene ist das für mich die Lösung.
Das Konzept kann man auch für timer (also at) nutzen. Bspw stündliche oder Täglich. So könnten man einen Stündliche Trigger laufen lassen und mit Wochentag und Stunde eine Aktion definieren.
Attr myTime Mo08 <schaltekaffeEin>
Attr myTime So09 <schaltekaffeEin>
Attr myTime Mo23 <schalteLichterAus>



betateilchen

Zitat von: martinp876 am 04 November 2021, 08:28:22
Ich denke das Konzept ist klar, evtl nicht für jedermann einfach. Hier bei den Entwicklern sollte es kein Problem sein.

FHEM existiert aber primär nicht für Entwickler, sondern für Anwender.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

So ganz habe ich noch nicht verstanden, was das "Weihnachtswunschkonzert" alles bringen soll. Grundsätzlich finde ich die "einfache Syntax" von notify einen großen Vorteil gg. anderen Eventhandlern (was leider die wenigsten Einsteiger ähnlich sehen). Natürlich kann man alles auch immer anders machen und die Teile anders verpacken, klar.

Die grundlegenden Probleme düften aber bleiben, und die fangen dann z.B. bei dem Beispielchen schon damit an, dass
{ notifyRegexpCheck('FB_.*(Short|Long).1_.*\(to.ccu\).*') }
"meckert" (selbst, wenn es mind ein Device gibt mit Namen FB_xx).

Und mit etwas Übung ist es doch auch für "leicht Fortgeschrittene" ein leichtes, sowas wie ein "eine FB, viele Raktionen"-notify zu basteln:
define n_Taster_Schlafzimmer_Fenster_dispatch notify Taster_Schlafzimmer_Fenster:.00. {\
if ($EVENT == 2002) {\
return CommandSet(undef, 'Fake_Fenster_SZ2_Btn1 press short');;}\
if ($EVENT == 2004) {\
return AnalyzeCommandChain(undef, 'set Rollladen_SZ_Nord 35.5;; set Rollladen_SZ_West 60.5');;}\
if ($EVENT == 2005) {\
return AnalyzeCommandChain(undef, 'set Rollladen_SZ_Nord 0;; set Rollladen_SZ_West 0');;}\
if ($EVENT == 4002) {\
return AnalyzeCommandChain(undef, "set Licht_SZ 0;; set Rollladen_SZ.* off;; {easy_HM_TC_Holiday('Thermostat_Schlafzimmer','21','stop') if ReadingsVal('Heizperiode','state','on') eq 'on'}");;}\
if ($EVENT == 4004) {\
my $cmd = ReadingsNum('Bewegungsmelder_1','brightness','100') < 100 \
? 'set Rollladen_SZ.* off,set Licht_SZ 20'\
: 'set Rollladen_SZ.* 30';;\
return AnalyzeCommandChain(undef,"$cmd;; {easy_HM_TC_Holiday('Thermostat_Schlafzimmer','23') if ReadingsVal('Heizperiode','state','on') eq 'on'}");;}\
if ($EVENT == 5004) {\
return CommandSet(undef, 'set Licht_Flur off') if lc ReadingsVal('Licht_Flur','state','off') eq 'on';; \
return CommandSet(undef, 'set Licht_Flur brightness 200');;}\
}

(kann man auch in myUtils verlegen, klar, und man kann es - wenn es unbedingt sein muss - auch für mehrere FB's erweitern, auch klar. Genauso klar: die Haken an den obigen "Abkürzungen" gg. "fhem" sollte man kennen).

Ab irgendeinem Punkt ist es halt als FHEM-User erforderlich, die grundlegenden Mechanismen verinnerlicht zu haben, und der Weg vom Event zur "passenden" Reaktion läßt sich doch kaum irgendwie allgemeingültig beschreiben, oder?

Es ist andererseits doch auch keiner gehingert, "notify2" zu bauen, bei dem dann _ein_ Attribut mit einer "Eventmatch->Reaktion"-Liste hinterlegt werden könnte...? (Ich sehe schon User meckern, dass da keine multiline-Commands vorgesehen sind...)

Für "at2" gibt es ggf. schon eine Lösung namens "Timer" (für die, die das nicht in DOIF lösen wollen, dass das m.E. auch kann; es mag weitere Lösungen geben wie MSwitch, die das auch noch können, mehrere parallel laufende InternalTimer zu verwalten).

Vielleicht kann mich jemand aufklären, wo der Vorteil der Attributlösung liegen soll, (außer, dass man nicht offensichtlich Perl braucht, um auf unterschiedliche Events unterschiedliche Kommandos folgen zu lassen).
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

martinp876

ZitatSo ganz habe ich noch nicht verstanden, was das "Weihnachtswunschkonzert" alles bringen soll
ich habe keine Hoffnung, da ich meine Erfahrungen ahben und nicht an das Christkind glaube.
Zitat. Grundsätzlich finde ich die "einfache Syntax" von notify einen großen Vorteil
1) die Sytax ist nicht einfach oder einfacher. Nur eben in einer Zeile
2)den Vorteil eines Einzeilers sehe ich sehr wohl - das lässt sich aber auf vielfältige weise lösen.
ein Beispiel wäre eine Syntax, attribute schlicht beim Aufruf mitzugeben.
define n_Taster notify attr:name=<name>;event=<event>;command=<cmd>
nur eine Option - könnte man generell zulassen. Die "Attr:.*" sind nicht Teil der Definition und würden dort nicht auftauchen
Wenn man wollte, könnte man an einer Lösung arbeiten - wie ich erwartet habe sucht man nur nach"das geht sowieso nicht"
ZitatNatürlich kann man alles auch immer anders
klar. Unklar ist mir, warum man zu gunsten von Einzeilern regelmäßig das "normale" Vorgehen von Attributen - war es nun einmal eigentlich ist.

notifyRegexpCheck
habe ich bislang nicht gekannt oder getestet. Das Notify meckert nicht und funktioniert einwandfrei.
a) warum wird nicht gemeckert? Muss ich das nun im nofity-code suche? ich sehe keine User-Info - schade
b) mit regexp zu arbeiten ist im Notify explizit beschrieben und wird auch praktiziert. Warum also das notifyRegexpCheck meckert ist fraglich - ein Fehler in der Prüfung? Muss ich einmal experimentieren
c)das aus meiner Sicht mislungene Frontend "Change wizard" zerlegt mein zulässiges trigger-filter inkorrekt. Es versicht, die regex zu splitten, was quatsch ist
ZitatFB_.*(Short   removeRegexpPart
Long).1_.*\(to.ccu\).*   removeRegexpPart
Sinnvoll wäre nach entity und event zu splitten:
ZitatFB_.*   removeRegexpPart
.*(Short|Long).1_.*\(to.ccu\).*   removeRegexpPart
- das '|' wird falsch interpretiert - und nicht wir operationell genutzt
- in attributen könnte ich das sauber lösen

ZitatUnd mit etwas Übung ist es doch auch für "leicht Fortgeschrittene" ein leichtes
Das ist für mich indiskutabel. Offensichtlich hast du die Anforderungen nicht verstanden.
I) dass die Definition mehr als unübesichtlich ist - und hässlich obenderin lassen wir einmal durchgehen
II) dass du nur eine entity bearbeitest lasse ich dir durchgehen, mit gesteigerter unüersichtlichkeit des Define lässt ich alles lösen
III) dass du programmer-kommandos nutzt anstatt user kommandos "AnalyzeCommandChain" anstelle von "set" und "fhem" ist deinem Programmer-hintergrund geschuldet. Du solltest kommados nutzen, welche auch im commandref  ausgewiesen sind. User/admin, nicht pogrammer level ist hier gefragt. oder ist FHEM nur für programmer?
IV) ein no-go ist die Editierbarkeit. Ein klares und unumstössliches requirement für mich ist die "Sofa-Administrierbarkeit".
   will ich nun in deinem Beispiel die Reaktion auf "$EVENT == 4004 " ändern muss ich ein defmod machen. Dann das ganze lange define ändern, die nicht zu ändernden Settings entfernen. Bei einem Tipfehler geht nix mehr. ==> NO-GO

Meine Lösung funktioniert aus dem Sofa - und dort habe ich sie adminitriert!
Um Reaktion auf FB_03Long zu ändern klicke ich auf FB_03Long und editiere diess
wenn ich eine fehler mache klappt das nicht mehr - aber alle anderen Buttons sind nicht beeinflusst.

==> die Implementierungen spielen in unterschiedlichen Liegen.

Zitat(kann man auch in myUtils verlegen
klar - ich kann auch das ganze Notify selbst kodieren. Geht nicht vom Sofa. Oder ich schreibe es eben gleich komplett selbst.
Mir ist in der Tat nicht klar, ob du mein Ziel verstanden hast.

ZitatAb irgendeinem Punkt ist es halt als FHEM-User erforderlich, die grundlegenden Mechanismen verinnerlicht zu haben, und der Weg vom Event zur "passenden" Reaktion läßt sich doch kaum irgendwie allgemeingültig beschreiben, oder?
unklar - was meinst du?

ZitatEs ist andererseits doch auch keiner gehingert, "notify2"
das einfachste ist, wenn ich 24 notifies gebaut hätte. Das Editieren des Commands wäre dann im Change Wizzard möglich. Ich könnte eine Group erstellen für diese Gruppe.... ich müsste 24 mal das Event eingeben - wenn ich einen fehler im Filter haben muss ich diesen 24 mal korrigieren, schon bin ich fertig.
==> für mich ist das nicht akzeptabel.
ZitatFür "at2" gibt es ggf. schon eine Lösung namens "Timer"
auch das liebe ich an fhem - diese vielfalt. einem gefällt das at nicht, da macht  eine Timer und einen RandomTimer,...  Es gibt für alles 2-3 Lösungen. Aus meiner Sicht wäre es hilfreich, einen Timer mit allen notwendigen Optionen zu haben. So suche ich mich zu tode und muss danach experimentell die Unterschiede ermitteln. Cool und Übersichtlich ist etwas anderes.
=> herzu hätte ich eine anderes Thema. FHEM sollte "kern-module" definieren, prüfen und "freigeben". User können hinzubasteln was sie wollen. Anwender können nutzen was sie wollen. Wird ein Kernmodul ausgephast oder ersetzt kommt es in die Kategorie "phase-out".  Wäre aus meiner Sicht hilfreich für Anwender, welche nicht 24/7 an fhem arbeiten

ZitatVielleicht kann mich jemand aufklären, wo der Vorteil der Attributlösung liegen soll,
Sofa-fähigkeit
entzerren/separieren der parameter.
eine Probleme mit spaces
Sicherheit in der Eingabe

Also einmal Einzeiligkeit bei Eeite beschoben - eine Lösung ist easy und verständlich, wenn man will.

Ein Notify besteht aus
define <name> notify <pattern> <command>
#besser
define <name> notify <entity><event> <command>
aus dem Commandref
define b3lampV1 notify btn3 set lamp $EVENT
#==>
define b3lampV1 notify
attr b3lampV1 trgName btn3
attr b3lampV1 trgEvent .* # kann auch eggelassen werden
attr b3lampV1 trgCmd set lamp $EVENT
#shortForm - onliner:
define b3lampV1 notify attr:trgName=btn3;trgCmd=""set lamp $EVENT""

define wzMessLg notify wz:measured.* "/usr/local/bin/logfht $NAME "$EVENT""
#==>
define wzMessLg notify
attr wzMessLg trgName wz
attr wzMessLg trgEvent measured.*
attr wzMessLg trgCmd /usr/local/bin/logfht $NAME "$EVENT"
#shortForm - onliner:
define wzMessLg notify attr:trgName=wz;trgEvent=measured.*;trgCmd="/usr/local/bin/logfht $NAME "$EVENT""
# meines
define n_FB12   notify 
attr n_FB12 trgName  FB_.*
attr n_FB12 trgEvent .*(Short|Long).1_.*\(to.ccu\).*
attr n_FB12 trgCmd {$EVENT=~ m/.*(Short|Long).*/;my $aNm=$NAME.$1; $cmd = AttrVal($SELF,$aNm,"attrUndef");fhem "$cmd;setreading $SELF lastCmd $cmd;setreading $SELF lastTrig $aNm;setreading $SELF lastEvt $NAME: $EVENT;setreading $SELF state $NAME: $EVENT"}


changeWizard wäre obsolet. Das Define ist definitiv übersichtlicher. Es ist definitiv vom Anwender einfacher zu verstehe und zu pflegen.

Mein Cmd ist etwas lang, da das orginal-notify einfach sehr unangenehm schweigsam ist Reading "lastEvent" und "lastName" ist m.E. sowieso unerlässlich. LastCmd wäre hilfreich, da man sehen kann, was der Trigger nun eigentlich ausgelöst hat. Ist aber mit unter komplex und somit fraglich

Aber zurück zum Anfang - da ich  mich den Leuten rede, welche den StatusQuo definiert und  implementiert habe, ihn für gut hielten und halten und sich die User an das aktuelel gewöhne haben und meist sowieso als gegeben hinnehmen gehe ich davon aus, dass weihnachten wieder einmal ausfällt.

P.S.: Ich halte den StatusQuo nicht für gut. Ich werde mich nicht daran abarbeiten und mit einfach ggf eine eigene Lösung bauen. Das Verständniss ist wie zu erwarten exterm gering.

martinp876

Zitat von: betateilchen am 04 November 2021, 12:48:28
FHEM existiert aber primär nicht für Entwickler, sondern für Anwender.
schon klar. Wenn ich es für wasserdicht beschreiben will werde ich ein Wiki schreiben. Dann muss ich einschränken und vereinfachen.
Und wer es nicht versteht sollte sich an den allgemeine, unkomfortable standartlösung halten. Besser als etwas unverstandenes zu impementieren

Beta-User

Vorab: Dein Strauß ist bunt, und mein Ziel war ausdrücklich nicht, einen Grund zu finden, warum es keine Neuerungen braucht!

Da es einfacher ist, das der Rehe nach zu kommentieren:

Zitat von: martinp876 am 04 November 2021, 15:45:40
1) die Sytax ist nicht einfach oder einfacher. Nur eben in einer Zeile
Für wirklich einfache Fälle ist der Einzeiler einfach. Die commandref ist leider "historisch", da sehr auf state-Events bezogen (also nur "entity", nicht auch "reading" im trigger).

Zitat
2)den Vorteil eines Einzeilers sehe ich sehr wohl - das lässt sich aber auf vielfältige weise lösen.
ein Beispiel wäre eine Syntax, attribute schlicht beim Aufruf mitzugeben.
Der parseParams-Ansatz ist gut und wird von mir an diversen Stellen auch aktiv propagiert (wer Belege braucht: RHASSPY und UBUS-Diskussion, bzw. Twilight verfrachtet Teile der Ausgangs-DEF direkt in den Orkus, wenn man sie nicht braucht (Klärung von historisch "erforderlichen" Daten)).

Kann man machen, die DEF komplex zu liefern, wenn man das auch über Attribute machen kann. Das Vorgehen ist aber für die meisten Einsteiger eher nicht verständlich und auch nicht einfacher einzugeben als der "Attribut-Weg".

Zitat
Unklar ist mir, warum man zu gunsten von Einzeilern regelmäßig das "normale" Vorgehen von Attributen - war es nun einmal eigentlich ist.
Na ja, was "normal" ist, wird irgendwo festgelegt. Ich gebe dir recht, dass vieles unübersichtlich ist, wenn man der Neigung nachgibt, alles mögliche in der DEF abzuarbeiten, das man auch woanders unterbringen könnte und oft nicht braucht. Unschön, könnte man dran arbeiten. Einig!

Zitat
notifyRegexpCheck
habe ich bislang nicht gekannt oder getestet. Das Notify meckert nicht und funktioniert einwandfrei.
Der Punkt ist: Das notify ist funktional, es gibt keinen Grund zu meckern, wenn man nicht auf der Suche nach dem Optimum ist. Ob man das ist, zeigt einem das notify im Internal NOTIFYDEF (schon immer). Steht auch nirgends, agreed. Könnte man dran arbeiten. notifyRegexpCheck() zeigt einem "nur" an, warum NOTIFYDEF ggf. nicht gesetzt ist. (Doku? Einig...)

Zitatc)das aus meiner Sicht mislungene Frontend "Change wizard" zerlegt mein zulässiges trigger-filter inkorrekt. Es versicht, die regex zu splitten, was quatsch ist
Bei der Diskussion über meine ehemals auch "tiefergelegten" trigger-Filter hatte jemand Wissendes erläutert, dass es extrem schwierig ist, ein rückwärtskompatibles Parsing für die vorhandenen trigger-Filter zu bauen. U.a. daraus ist die o.g. Funktion entstanden. Es geht darum, dass der eigentliche splitter der Doppelpunkt ist, der "entity" und "event" trennt, und das notify eben effizienter abgearbeitet wird (bzw. schon nicht aufgerufen, wenn nicht passend), wenn NOTIFYDEV erkannt werden kann.

Zitat
Sinnvoll wäre nach entity und event zu splitten:- das '|' wird falsch interpretiert - und nicht wir operationell genutzt
- in attributen könnte ich das sauber lösen
Gründe: s.o.. Attribute könnte man leichter zur Laufzeit checken, was aber prinzipiell auch mit der DEF selbst ginge. Vorteil für Attr: man verliert nicht gleich das ganze Device wieder.

Zitat
Das ist für mich indiskutabel. Offensichtlich hast du die Anforderungen nicht verstanden.
I) dass die Definition mehr als unübesichtlich ist - und hässlich obenderin lassen wir einmal durchgehen
II) dass du nur eine entity bearbeitest lasse ich dir durchgehen, mit gesteigerter unüersichtlichkeit des Define lässt ich alles lösen
III) dass du programmer-kommandos nutzt anstatt user kommandos "AnalyzeCommandChain" anstelle von "set" und "fhem" ist deinem Programmer-hintergrund geschuldet. Du solltest kommados nutzen, welche auch im commandref  ausgewiesen sind. User/admin, nicht pogrammer level ist hier gefragt. oder ist FHEM nur für programmer?
IV) ein no-go ist die Editierbarkeit. Ein klares und unumstössliches requirement für mich ist die "Sofa-Administrierbarkeit".
   will ich nun in deinem Beispiel die Reaktion auf "$EVENT == 4004 " ändern muss ich ein defmod machen. Dann das ganze lange define ändern, die nicht zu ändernden Settings entfernen. Bei einem Tipfehler geht nix mehr. ==> NO-GO
Ad I) Ich bin schlimmeres gewohnt, aber klar: wenn wir es am Ende übersichtlicher hinbekommen: auch gut!
Ad II) Das war in deinem Beispiel nur theoretisch anders, und wenn man die device:entity-Trennung sauber macht, gibt es m.E. keinen wirklichen Grund, nicht ein 2. Notify für eine andere FB aufzumachen. Eventuell wäre der einzige Vorteil, wenn es in deiner Lösung möglich wäre wildcards einzusetzen, also bestimmte (alle geht auch mit meiner Lösung) Tasten einem identischen Attribut zuzuweisen.
Ad III) dass man (fast) dasselbe Coding benutzen kann, wenn man die Anweisungen in "fhem" einzupacken, hatte ich ausdrücklich erwähnt. Ich ändere aber doch nicht zu Demo-Zwecken eine funktionale Definition...

Ad IV) klarer Vorteil! Auch die Option, einzelne Kommandos einem Vorab-Check auf prinzipielle Validität unterziehen zu können, ist ein großer Vorteil. (Macht btw. z.B. der RHASSPY-Code für User-Kommandos auch so).

ZitatMir ist in der Tat nicht klar, ob du mein Ziel verstanden hast.
Ganz vermutlich noch nicht, aber es ist (vermutlich nicht nur mir) jetzt sehr viel deutlicher, in welche Richtung du Vorstellungen hast.

Zitatunklar - was meinst du?
Nach meiner bisherigen Erfahrung sind viele User schon mit einfachen notify überfordert. Sowas wie "Taste wurde kurz gedrückt => mache das Licht xy an".  Wenn man das jetzt noch auf Attribute verteilt, könnte es sein, dass am Ende noch weniger Durchblick herrscht, wie was zusammengehört, weil "Attribut_1_regexp" mit "Attribut_1_exec" verbunden werden muss...
Viele sind dann dazu noch völlig verstöhrt, wenn sie drei Zeilen Perl ("Pearl") vercoden müssen und sich entscheiden, ob sie if jetzt klein, groß oder gemischt schreiben... "Leider" führt erfahrungsgemäß früher oder später sowieso kein Weg daran vorbei, dazu ein paar Grundlagen zu erlernen, sonst wir das einfach nix. Also lieber gleich ein kleines "if" (im doppelten Sinn: funktional und Perl), dann klappt das auch in den meisten Fällen früher oder später.

Zitatdas einfachste ist, wenn ich 24 notifies gebaut hätte.
"notify2" (und "at2") war eher im Sinne je eines weiteren Moduls gemeint gewesen.

24 Mal dasselbe eingeben finde ich auch nicht akzeptabel, Ergebnis s.o.

Zitatauch das liebe ich an fhem - diese vielfalt. einem gefällt das at nicht, da macht  eine Timer und einen RandomTimer,...  Es gibt für alles 2-3 Lösungen. Aus meiner Sicht wäre es hilfreich, einen Timer mit allen notwendigen Optionen zu haben. So suche ich mich zu tode und muss danach experimentell die Unterschiede ermitteln. Cool und Übersichtlich ist etwas anderes.
Agreed. "Noch eine Lösung" finde ich auch nicht allzu cool. Eine sinnvolle Evolution wäre im Sinne aller.

Zitat=> herzu hätte ich eine anderes Thema. FHEM sollte "kern-module" definieren, prüfen und "freigeben". User können hinzubasteln was sie wollen. Anwender können nutzen was sie wollen. Wird ein Kernmodul ausgephast oder ersetzt kommt es in die Kategorie "phase-out".  Wäre aus meiner Sicht hilfreich für Anwender, welche nicht 24/7 an fhem arbeiten
Klingt in der Theorie gut, meine praktischen Erfahrungen mit "Phase-outs" (wieso diese Redundanz zwischen WeekdayTimer und Heating_Control?) zeigt allerdings, dass das in der Praxis viel schwieriger ist, weil die Mehrzahl der User Schwierigkeiten damit hat, selbst einfachste Dinge anzupassen und viele Installationen auch unverändert über Jahre laufen, und dann eine (meist ungeplante!) Anpassung an "neue Gegebenheiten" in der Regel extremes Frustpotential hat.
Meine Meinung daher: lieber Vielfalt und Kompromisse im Hinblick auf Kompabilität mit dem, was wir kennen.

ZitatSofa-fähigkeit
entzerren/separieren der parameter.
eine Probleme mit spaces
Sicherheit in der Eingabe
Angekommen.

Zitat
Also einmal Einzeiligkeit bei Eeite beschoben - eine Lösung ist easy und verständlich, wenn man will.
Ein Notify besteht aus
define <name> notify <pattern> <command>

M.A.n. besser:

define <name> notify <entity>:<event> <command>


Der hier ist noch "grausam"

attr n_FB12 trgCmd {$EVENT=~ m/.*(Short|Long).*/;my $aNm=$NAME.$1; $cmd = AttrVal($SELF,$aNm,"attrUndef");fhem "$cmd;setreading $SELF lastCmd $cmd;setreading $SELF lastTrig $aNm;setreading $SELF lastEvt $NAME: $EVENT;setreading $SELF state $NAME: $EVENT"}

aber die Konstruktion an sich klingt interessant!

Hoffe, meine vorherigen Ausführungen damit etwas klarer gemacht zu haben, und will ausdrücklich klarstellen: Das sind nur meine persönlichen 2ct.
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

rudolfkoenig

ZitatAber dennoch finde ich das wäre nützliche Information. Vor allem auch für Anfänger, die sehen dann recht schnell, was sie mit ihrem notify so einfangen, oder eben auch nicht.

Gehört dann analog dazu eigentlich auch an watchdog ;)
Watchdog hat das schon. Ich habe das jetzt auch bei notify eingebaut, aus Konsistenzgruenden mit dem gleichen Namen wie da (triggeredByDev und triggeredByEvent)

ZitatWenn notify die Attribute readingList, setList hätte, könnte man auf die Definition eines dummy verzichten, um den <command> Teil oder vielleicht sogar den <trigger> zu parametrisieren und könnte dann mit webCmd,  webCmdLabel ein eigenes Interface gestalten.
Kannst Du das bitte an einem Beispiel zeigen?
Ich habe Probleme mir den praktischen Nutzen vorzustellen.

ZitatZum Ersten wünsche ich mir aber (es wird Weihnachten - auch hier bekommt man nicht alles), [...]
Ich habe kein Probem mit Aenderungen (das kann betateilchen vmtl. bestaetigen), aber ich muss schon halbwegs vom Vorteil (im Sinne von Aufwand/Nutzen) ueberzeugt sein.
Bei dem Beispiel mit dem komplizierten notify und den 24+1 Attributen frage ich mich, warum das besser sein soll, als 24 einfache notifies.
Diese koennen aus dem Event-Monitor erstellt, und mit dem Wizard mit dem passenden Befehl bestueckt werden.
Sofatauglich.

Zitatmit regexp zu arbeiten ist im Notify explizit beschrieben und wird auch praktiziert. Warum also das notifyRegexpCheck meckert ist fraglich - ein Fehler in der Prüfung?
FHEM versucht das Verteilen der Events zu optimieren. Das funktioniert nicht immer, und notifyRegexpCheck meldet, ob es funktioniert.
Diese Optimierung hilft falls viele Instanzen mit notifyFn auf viele Events treffen.

ZitatFHEM sollte "kern-module" definieren, prüfen und "freigeben".
Sehe ich ganz anders.
Selbst FHEMWEB ist kein Kernmodul, von notify ganz zu schweigen.

Benni

Zitat von: rudolfkoenig am 04 November 2021, 18:57:22
Watchdog hat das schon. Ich habe das jetzt auch bei notify eingebaut, aus Konsistenzgruenden mit dem gleichen Namen wie da (triggeredByDev und triggeredByEvent)

Das kann ich bei meinen watchdogs leider nirgends sehen!

Muss das erst irgendwie aktiviert werden (Featurelevel ist bei mir auf 99.99)?


Edit: Habe gerade auch mal noch einen Blick in den code von watchdog geworfen, und gesehen, dass die beim reset des watchdog wieder gelöscht werden. Könnte man die nicht stehen lassen? Das Triggered-Reading bleibt ja schließlich auch erhalten.



rudolfkoenig

ZitatKönnte man die nicht stehen lassen? Das Triggered-Reading bleibt ja schließlich auch erhalten.
Da ist ein Argument, was ich nachvollziehen kann.
Habe das Loeschen entfernt.

martinp876

Wir sind in einer Grundsatz-Diskussion - schon klar.
ZitatFür wirklich einfache Fälle ist der Einzeiler einfach
Veto: mein Vorschlag ist nicht wirklich komplexer, attribute in einer Zeile beim Define mitzugeben. Nur dass man den Parametern Namen geben muss und sie dann im Attribut zu finden sind.
Veto2: Wirklich einfache Fälle habe ich nicht. Automatisierung lebt von Notifies. Alles in einem einzelnen zu machen ist nicht ökonimisch oder ergonomisch (meine Sicht)

ZitatDer parseParams-Ansatz ist gut und wird von mir an diversen Stellen auch aktiv propagiert
Super - die Module nutze ich nicht, kenne ich also nicht. Wichtig ist, dass man die Parameter dann in Attributen wiederfindet. Sonst kann man nicht editieren.
ZitatKann man machen, die DEF komplex zu liefern, wenn man das auch über Attribute machen kann. Das Vorgehen ist aber für die meisten Einsteiger eher nicht verständlich und auch nicht einfacher einzugeben als der "Attribut-Weg"
unklar. Der Parameter Weg ist in der Wirkung identisch zum Attribut Weg.
Für Einsteiger welche nur kopieren kann man einen Einzeiler machen. Sie verstehen es eh nicht.
Einsteiger mit Verständniss-ambitionen können die entity Schritt für Schritt "hochfahren", testen und abwandeln.
Wichtig ist, sehr deutlich klarzustellen, dass Parameter in der Form wie ich es beschrieben habe, in Attributen zu liegen kommen. Oh - Evlt habe ich das nicht deutlich gemacht Also ein
define <name> <type> attr:<attr1>=<attrVal1>;<attr2>=<attrVal2>;<attr3>=<attrVal3>;
erzeugt ein
Internals
  DEF ""
  NAME <name>
Attribute
    <attr1> <attrVal1>
    <attr2> <attrVal2>
    <attr3> <attrVal3>

Hoffentlich verständlich dargestellt.
Zusammenfassend: Es ist nur eine andere Möglichkeit, attribute zu setzen.
Weiter: Das DEF im Internal spiegelt das nicht wieder

Grundsatz: Eine "Option" entweder im Attribut ODER im Define darzustellen ist ein NoGo - sind wir uns sicher einig.

ZitatNa ja, was "normal" ist, wird irgendwo festgelegt
Bedingt korrekt. Niedergeschrieben ist fast nichts.
Verhalten und Einstellungen einerEntity wird über Attribute gemacht.
Parameter wie "native Adresse" gehören in das Define. Danach wird es dünn.
Wie man deutlich sehen kann sind die Parameter bei einem Notify Attribute. Wäre es eine Definition müsste es nicht geändert werden. Dass es aber häufig geändert werden muss zeigt die tatsache, dass ein Change Wizzard gebaut werden musste (welcher hinfällig ist, wenn man hier Attribute hätte - diese habe ein natives Edit-Interface)

ZitatIch gebe dir recht, dass vieles unübersichtlich ist, wenn man der Neigung nachgibt, alles mögliche in der DEF abzuarbeiten, das man auch woanders unterbringen könnte und oft nicht braucht.
Es sollte eins Desing guidline sein, in einem Define nur das einzutragen, was die entity definiert (nicht dessen Verhalten). Es ist daher nicht notwendig, ein Define zu editieren (seltene Ausnehmen...)
ZitatOb man das ist, zeigt einem das notify im Internal NOTIFYDEF (schon immer). Steht auch nirgends, agreed. Könnte man dran arbeiten.
blos nicht andern . beschreiben gerne. 
NOTIFYDEFwird bei mir nicht angezeigt.
Ich werden mir den code einmal ansehen und auf sinnhaltigkeit prüfen (aus meiner sicht).
Aktuell ist es schwierig für den Parser, da nur der Parameter "trigger" definiert ist. Würde man es "richtig" machen würde man es splitten (wie nun schon mehrfach dargestellt) in TrgName und TrgEvent. TrgName könnte man dann über alle entits filtern lassen und eine Liste aller potentiellen Entites anzeigen, welche zutreffen könnten.TrgEvent könnte man dann auch Filtern... wird aber teurer (zeitlich).
In jedem Fall muss es möglich sein, regex für beide eingeben zu können.
Als ich notify das erste man genutzt habe war das Problem, trigger richtig zu filtern. Mit dem Split ist es einfacher. Ein Interface mit einer Auswahliste ist bei Attriut auch kein Problem. Incl Multiple!!!
ZitatBei der Diskussion über meine ehemals auch "tiefergelegten"...
alles klar. Genau das ist eines der Probleme. All die anderen Dinge, welche du ansprichst, wiedersprechen nicht meinem Ansatz.

ZitatGründe: s.o.. Attribute könnte man leichter zur Laufzeit checken, was aber prinzipiell auch mit der DEF selb...
Attribute zur LAufzeit checken? Nicht wirklich, oder?  Attribute sollte man zur Edit-Zeit parsen und in optimal verarbeitbare "helper" wandeln. Die eingabe eines Attributs darf nicht am Modul vorbei gehen.

ZitatAd I) Ich bin schlimmeres gewohnt, aber klar: wenn wir es am Ende übersichtlicher hinbekommen: auch gut!
"Es geht auch schlechter" ist wohl kaum der Anspruch.

ZitatAd IV) klarer Vorteil! Auch die Option
Für mich alternativlos!

ZitatNach meiner bisherigen Erfahrung sind viele User schon mit einfachen notify überfordert.
kein Wunder. Schlecht getrennt. Es hat mich anfänglich einiges gekostet, den ersten Trigger mit regex hinzubekommen. Insbeondere der : und die führenden Leerzeichen, an welche man denken muss sind eine Kathastrophe.

ZitatSowas wie "Taste wurde kurz gedrückt => mache das Licht xy an".  Wenn man das jetzt noch auf Attribute verteilt, könnte es sein, dass am Ende noch weniger Durchblick herrscht, wie was zusammengehört, weil "Attribut_1_regexp" mit "Attribut_1_exec" verbunden werden muss...
keine Zustimmung. Für alle CUL_HM Tasten kann ich eine klare Anleitung schreiben - einfach und einleuchend. Das gilt aber nicht für andere Tasten, hier muss man selektiv sein.
Die Anleitung für CUL_HM ist einfach und heisst abstrakt:
- peeren aller Tasten mit vccu channel
- trgName: alle entites in eine Liste packen  wie folgt (<ent1>|<ent2>|...) oder mit regex filtern. (ersteres für anfänger)
- trgEvent: gebe ich vor, muss man nichts machen.
- userAttr anlegen mit ent1Short ent1Long ent2Short ent2Long ...
- attr ntfy ent1Short  <commando>

Das ist, meine ich,  deutlich einfacher als das bisherige vorgehen. Je nach Reaktion kann man noch feilen und Beispiele hinterlegen.
Non-fhem Kommandos für Fortgeschrittene jederzeit möglich
additional readings sollten eigentlich im Standart notify sein. Leider musste ich diese selbst einbauen.

ZitatKlingt in der Theorie gut, meine praktischen ...
Meine Meinung daher: lieber Vielfalt und Kompromisse im Hinblick auf Kompabilität mit dem, was wir kennen.
Entscheidungen fordern Mut.
Wenn ich ein Modul nutze frage ich  mich immer, ob es "standard" ist oder ein Exote. Natürlich müsste jemand die kernmodule identifizieren.
Phase-out bedeutet erst einmal "out-of-maintenance". Da liegen sie dann so rum... werden irgendwann ins archieve verschoben... man kann es noch nutzen, auf eigene Gefahr. Das Zentralmodul (leider haben wir das nicht) würden anzeigen: Achtung: Diese Module sind End-Of-Live - kein Support. Suche eine andre Lösung oder betreibe es auf eigene Gefahr.
=> muss man nur entscheiden. Nicht machen ist auch eine Entscheidung. Nicht immer die Beste... Zu viel Maintenance kostet!

ZitatDer hier ist noch "grausam"
nun, es kann einfacher sein. Wenn Notofy seine Arbeit macht sieht es so aus
attr n_FB12 trgCmd {my $aNm=$NAME.($EVENT=~ m/Short/?'Short':'Long'); $cmd = AttrVal($SELF,$aNm,"attrUndef");fhem "$cmd"}
Aber bei der Definition des Kommandos kann man behilflich sein. Es ist so ausgelegt, dass ich das Identische Koooamdo für alle (ALLE!) CUL_HM Buttons nutzen kann.
Bei Motion müsste ich nachsehen,... usw.

Ich fasse einmal zusammen, wo ich Handlungsbdarf sehe (also ich persönlich - es gibt sicher andere Meinungen)
Design Guideline "Define"
- ein Define sollte nur wirklich notwendige Parameter beinhalten. Der Selbsttest: Wenn ich etwas zur Laufzeit verändern oder anpassen will ist es eher kein Define-parameter sondern ein Attribut. Beispiel für parameter sind typisch Adressen. Möglicherweise ein grundsätzlicher Modus. That's it.
Option "fast Entry" (one-liner)
- das ist nur eine Schreibweise, attribute beim Define mitzugeben. Dies zuzulassen ist kein Schaden und hat keinen Einfluss auf das Verhalten. Die Attribute werden wir üblich über die bekannten Funktionen eingespeisst. Es gibt keine Begrenzung der Anzahl und obligt dem User,es zu nutzen. Die konkrete Syntax kann einfach definiert werden, einen Vorschlag habe ich gemacht. Das Verhalten im Fehlerfall ist zu klären, wird am Ende aber einfach festgelegt.
Migration z.B. Notify von Param auf Attr
das kann on-the-fly gemacht werden. Das Zerlegen in trgName und trgEvent ist nicht möglich - daher ist ein trgCombined alternatig zulässig. Die beiden Optionen sind mutual exclusiv
Sinnvolle Readings
Module wie Notify sollten einmal überlegen, welche Readings allgemein "freundliche" wären. Wenn ein Notify auslöst  kam von einer Entity ein Event. Liegt es dann nicht nahe, 2 Readings zu erzeugen: lastName und lastEvent? Das ist schon einmal zum Testen ungemein hilfreich.
Weiterführende Readings sind möglich und optional: "trackName": jede Entity wird mit dem letzte Trigger in den Readings vermerkt (auch hilfreich beim Debuggen)
Daraus ergeben sich dann standard Kommandos, set und get
set clear (triggerEvents|Readings)
set simulateTrigger <trigger>

Eigentlich sollte jede Entity standard-Kommandos haben
set renameMe
get list (normal|full) # wie in CUL_HM
get cmdList (mit kurzer Beschreibung und Optionen)











martinp876

ZitatIch habe kein Probem mit Aenderungen (das kann betateilchen vmtl. bestaetigen), aber ich muss schon halbwegs vom Vorteil (im Sinne von Aufwand/Nutzen) ueberzeugt sein.
Bei dem Beispiel mit dem komplizierten notify und den 24+1 Attributen frage ich mich, warum das besser sein soll, als 24 einfache notifies.
Ich weiss nicht, ob ich dir das klar machen kann. Es liegt eigentlich alles auf dem Tisch. Und falls du dir das Command angesehen hättest, hättest gerade du gesehen, dass es nicht weiter komplex ist.

1) der unschlagbare Komfort ist nicht im Anlegen des  - immer identischen und unbesehen kopierbaren - Kommmandos im Notify-Define-Parameter-Command
2) der mir wichtige Komfort liegt in der Administration.
=> für CUL_HM Nutzer von Buttons ist das Kommando immer Identisch. Wenn das kein Komfort für den Admin ist.
=> das Trigger Event ist  immer Identisch.
=> Der Filter der Entites ist zu setzen - das kann man dem User nicht abnehmen
=> Die Reaktion auf eine Trigger ist zudefinieren. Einfach über Attribut.

Achtung!!!!!! Ich erwarte NICHT!!, dass dieses Kommando in Notify realisiert wird. falls das verstandenwurde habe ich mich gründlich falsch ausgedrückt oder es wurde oberflächlich gelesen
Wünsche an das Notify
1) auf der Hand liegende Readings doch selbst erzeugen. Ist das nun gerade passiert? Dann kann ich das Kommando schon einmal um diesen Teil verkleinern.
2) auf der Hand liegende Kommandos implementieren (löschen der Trigger Readings). Das will ich manuell machen können - zum testen. Frist kein Brot! Gehört sich einfach.
3) der schwierige Teil: Die im Define versteckten Attribute aus dem Define dahinzu packen, wo sie sein sollten: in den Attributen


Das Beispiel der 12 Kanal FB und der Quantensprung, wenn man es so realisiert ist eine Beispiel-implementierung, welche durch die obigen Massnahmen leicht unterstützt wird, mehr nicht. Wer es einmal auf diese Weise realisiert wird es nie mehr anders machen.
Die vereinfachte Form wäre: eine Entiy, ein Trigger, ein Kommando. Alles in nativen Notify Attributen

Das streamlined verschicken von Notifies ist sicher sinnvoll. In meinem Fall habe ich nun 24 Notifies mit einfachen Filter gegen eines mit etwas komplexerem Filter ersetzt.
Nun kann ich die regex noch tunen. Dann können wir performance-tests machen... mal sehen, was besser kommt....