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

[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]

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

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

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

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

Mit einenem Kommando "simulateEvent" kommte man das notify auch testen oder Auslösen.

Meinst du den trigger Befehl? Den gibts es schon seit "immer".

User 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]

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

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]

Wenn 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

Code Auswählen Erweitern

define mytrigger notify entity:event commands
neu

Code Auswählen Erweitern

define mytrigger notify
attr mytrigger trigger entity:event
attr mytrigger cmd commands
oder

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

 

Readings
     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]

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.

[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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[martinp876]

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

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

Code Auswählen Erweitern

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"

Natü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

FB_.*(Short   removeRegexpPart
Long).1_.*\(to.ccu\).*   removeRegexpPart

Sinnvoll wäre nach entity und event zu splitten:

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

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

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

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?

unklar - was meinst du?

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

Fü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

Vielleicht 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

Code Auswählen Erweitern

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]

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:

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

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

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!

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

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

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.

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.

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

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

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

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

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.

Agreed. "Noch eine Lösung" finde ich auch nicht allzu cool. Eine sinnvolle Evolution wäre im Sinne aller.

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

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

Angekommen.

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

Code Auswählen Erweitern

define <name> notify <pattern> <command>

M.A.n. besser:

Code Auswählen Erweitern


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


Der hier ist noch "grausam"

Code Auswählen Erweitern


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.

[rudolfkoenig]

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

Watchdog hat das schon. Ich habe das jetzt auch bei notify eingebaut, aus Konsistenzgruenden mit dem gleichen Namen wie da (triggeredByDev und triggeredByEvent)

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.

Kannst Du das bitte an einem Beispiel zeigen?
Ich habe Probleme mir den praktischen Nutzen vorzustellen.

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

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?

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.

FHEM sollte "kern-module" definieren, prüfen und "freigeben".

Sehe ich ganz anders.
Selbst FHEMWEB ist kein Kernmodul, von notify ganz zu schweigen.

[Benni]

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]

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

Fü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)

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

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"

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

Code Auswählen Erweitern

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.

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

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.

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

Ob 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!!!

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

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

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

Ad IV) klarer Vorteil! Auch die Option

Für mich alternativlos!

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

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

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.

Klingt 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!

Der hier ist noch "grausam"

nun, es kann einfacher sein. Wenn Notofy seine Arbeit macht sieht es so aus

Code Auswählen Erweitern

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]

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.

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

[rudolfkoenig]

Nun kann ich die regex noch tunen. Dann können wir performance-tests machen... mal sehen, was besser kommt....

Egal wie man optimiert, es wird fuer jedes Event mehr Code ausgefuehrt, als bei den "einfachen" notifies.
Der Unterschied ist vmtl irrelevant, Optimieren hilft nur dann, wenn man (wie oben erwaehnt) Hunderte von notifyFns und Hunderte von Events pro Sekunde hat.

[Ellert]

Kannst Du das bitte an einem Beispiel zeigen?
Ich habe Probleme mir den praktischen Nutzen vorzustellen.

Im einfachsten Fall könnte man die Einschaltdauer einer Lampe im Frontend verändern.

Mit setList und readingList im notify könnte es dann so aussehen:

Code Auswählen Erweitern

define Leuchtdauer notify schalter:on set Licht on-for-timer [$SELF:dauer]

attr Leuchtdauer readingList dauer
attr Leuchtdauer setList dauer:60,120,180
attr Leuchtdauer webCmd dauer
attr Leuchtdauer webCmdLabel Einschaltdauer

Derzeit wäre noch ein Dummy erforderlich

Code Auswählen Erweitern


define Leuchtdauer notify schalter:on set Licht on-for-timer [LeuchtdauerHelfer:dauer]

define LeuchtdauerHelfer dummy
attr LeuchtdauerHelfer readingList dauer
attr LeuchtdauerHelfer setList dauer:60,120,180
attr LeuchtdauerHelfer webCmd dauer
attr LeuchtdauerHelfer webCmdLabel Einschaltdauer

Komplexer könnte es dann mit Eränzungen so aus sehen:
Wenn es  3 zusätzliche Benutzer Funktionen gäbe

ReadingsTrigger(<name>,<reading>) alsTrigger im Notify,
ReadingsExecute(<name>,<reading>) zum Ausführen von Perlbefehlen und
ReadingsCommand(<name>,<reading>) zum Ausführen von FHEM-Befehlen,

dann könnte man die Definition unangetastet lassen, da Kode und Trigger in Readings dargestellt werden kann.

Code Auswählen Erweitern

define MeinNotify notify {ReadingsTrigger("$SELF",'trigger')} {ReadingsCommand("$SELF",'cmd_1');...}

attr MeinNotify readingList cmd_1 trigger
attr MeinNotify setList cmd_1:textField-long trigger:textField-long

[Beta-User]

Na ja, wenn man von "Automatisierung" spricht, sind solche Frontend-Fragen eher nicht so im Vordergrund. Viele User wollen sie aber haben und verstehen auch nicht, dass sie Infos an beliebigen Devices via setreading hinterlegen können...

Also wenn schon, denn schon, wäre es konsequent, ein generischeres "setterList" (Arbeitstitel) einzuführen, mit dem man beliebige Readings an beliebigen Devices mit frei wählbaren widgets setzen kann (also im Hintergrund "setreading" ausführt)...
Sowas ginge space-separiert, und man würde sich den völlig unnötigen Dualismus von setList und readingList sparen.

Solche Readings (bzw. meistens userattr) nutze ich z.B. auch für generische notify (das hat ein NOTIFYDEV):

Code Auswählen Erweitern

defmod n_FK_TK_notify notify Fenster_.*:open|Fenster_.*:closed|Dachfenster_.*:open|Dachfenster_.*:closed|Terrassentuer_.Z:open|Terrassentuer_.Z:closed|Balkontuer:open|Balkontuer:closed|Haustuer:closed|Haustuer:open { myWinContactNotify ($NAME, $EVENT) }
Die Perl-Funktion checkt, ob es um ein Öffnen, oder Schließen-Event geht, und ist dazu da, (verzögert) virtuelle TFK zu setzen, um damit CUL_HM-RT-DN zu steuern. Die Einschaltdauer (und die Info, welche TFK zu welchem RT-DN gehören) kommt dann jeweils aus einem Wert, der am Zielgerät gespeichert ist. Wg. der Array-Suche nicht allzu effizient, aber das sind auch keine Dauer-Events.
Das notify funktioniert übrigens auch mit anderen Sensor-Typen, nicht nur CUL_HM...

Ansonsten: Diese Attribut-Orgien-Vorschläge und Klammerungen finde ich nicht gut. ist m.e. nicht KISS. (Einige wenige: von mir aus...)

[Ellert]

Na ja, wenn man von "Automatisierung" spricht, sind solche Frontend-Fragen eher nicht so im Vordergrund. Viele User wollen sie aber haben und verstehen auch nicht, dass sie Infos an beliebigen Devices via setreading hinterlegen können...

Also wenn schon, denn schon, wäre es konsequent, ein generischeres "setterList" (Arbeitstitel) einzuführen, mit dem man beliebige Readings an beliebigen Devices mit frei wählbaren widgets setzen kann (also im Hintergrund "setreading" ausführt)...
Sowas ginge space-separiert, und man würde sich den völlig unnötigen Dualismus von setList und readingList sparen.

Solche Readings (bzw. meistens userattr) nutze ich z.B. auch für generische notify (das hat ein NOTIFYDEV):

Code Auswählen Erweitern

defmod n_FK_TK_notify notify Fenster_.*:open|Fenster_.*:closed|Dachfenster_.*:open|Dachfenster_.*:closed|Terrassentuer_.Z:open|Terrassentuer_.Z:closed|Balkontuer:open|Balkontuer:closed|Haustuer:closed|Haustuer:open { myWinContactNotify ($NAME, $EVENT) }
Die Perl-Funktion checkt, ob es um ein Öffnen, oder Schließen-Event geht, und ist dazu da, (verzögert) virtuelle TFK zu setzen, um damit CUL_HM-RT-DN zu steuern. Die Einschaltdauer (und die Info, welche TFK zu welchem RT-DN gehören) kommt dann jeweils aus einem Wert, der am Zielgerät gespeichert ist. Wg. der Array-Suche nicht allzu effizient, aber das sind auch keine Dauer-Events.
Das notify funktioniert übrigens auch mit anderen Sensor-Typen, nicht nur CUL_HM...

Ansonsten: Diese Attribut-Orgien-Vorschläge und Klammerungen finde ich nicht gut. ist m.e. nicht KISS. (Einige wenige: von mir aus...)

Ja, man kann natürlich mit setterList etwas Neues einführen, ich bin eher dafür die vorhandenen Mechanismen zu nutzen, die paar Zeilen für setList u. readingsList könnte man in fast jedes Modul integrieren.  Ein einfaches Einschalten ohne das Modul anzufassen, wie bei den setExtensions ist sicherlich nicht so einfach umzusetzen, sonst gäbe es das schon.

Wo die Parameter hinterlegt sind ist letztlich eine Geschmackssache, ich habe sie gern an zentraler Stelle im Eventhandler und nicht verstreut in den Zielgeräten.

Automatisierung ersetzt menschliches Zutun, manchmal ist es aber erforderlich Parameter anzupassen und dann ist es sinnvoll mögliche Parameter in einer Liste Vorweg zu nehmen und über das Frontend einstellbar zu machen, ohne die Befehlszeile zu nutzen oder die Definition zu ändern. Kann man eigentlich Userattribute über webCmd setzen, ich meine nicht.

[Beta-User]

Ja, man kann natürlich mit setterList etwas Neues einführen, ich bin eher dafür die vorhandenen Mechanismen zu nutzen, die paar Zeilen für setList u. readingsList könnte man in fast jedes Modul integrieren.  Ein einfaches Einschalten ohne das Modul anzufassen, wie bei den setExtensions ist sicherlich nicht so einfach umzusetzen, sonst gäbe es das schon.

...manchmal hat einfach auch noch keiner gefragt...?
Und die Argumentation "die paar Zeilen" sind für mich ein "NoGo", weil das wieder dazu führen wird, dass es eben jedes Modul wieder ein klein wenig anders macht, was dann zu solchen "Problemchen" führt wie in https://forum.fhem.de/index.php/topic,123921.msg1184786.html#msg1184786 erläutert.

Und da namensgleich eben nicht funktionsgleich ist (readingList und setList in dummy und MQTT2_DEVICE sind zwei völlig verschiedene Dinge!), muss man das m.E. auch von der Benennung her klarstellen.

Wo die Parameter hinterlegt sind ist letztlich eine Geschmackssache, ich habe sie gern an zentraler Stelle im Eventhandler und nicht verstreut in den Zielgeräten.

Das kommt auf den Anwendungsfall an. Die Frage, wie lange jeweils gewartet werden soll, bis der virtuelle Kontakt den RT runterdreht, ist für mich jedenfalls eine Einstellung, die eine Eigenschaft des Zieldevices darstellt und mit dem eigentlichen Eventhandler nichts zu tun hat.

Kann man eigentlich Userattribute über webCmd setzen, ich meine nicht.

userAttr via webCmd geht nicht, das wäre evtl. was für die Wunschliste.

Wir sind in einer Grundsatz-Diskussion - schon klar. 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.

Es ist für "klassische Einzeiler" komplexer. Einen Zwang, Namen zu vergeben, sehe ich als kontraproduktiv an, und die meisten notify habe ich nach der 3. Optimierungsrunde nicht mehr wirklich angefasst.

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)

Siehe mein vorheriges Beispiel. Einfach. Generisch. Einzeiler. Kein Bedarf für Edits.
Weiteres Beispiel: Haustür geht auf => Klingelsignal am Telefon? => Auflegen. Einzeiler. Kein Bedarf für Attribute, etwas Perl.
Sowas einzelfallbezogenes gibt es bei mir in geringer Anzahl, aber es ist mAn. in jeder Installation vorhanden.

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. unklar. Der Parameter Weg ist in der Wirkung identisch zum Attribut Weg.

Du solltest vermutlich mal einen Blick in den RHASSPY-Code werfen (in contrib zu finden). Ist ein "Querschnittsmodul", das Attribute an jedes von ihm zu steuernde Device verteilt. Viele Attribute wären nicht gut, diesen Aspekt hatte ich bei der Diskussion um AutoShuttersControl leider noch nicht so auf dem Schirm. Daher wenige Attribute, viele (mAn. sinnvolle) Defaults, auf die zurückgegriffen wird, wenn der User nichts setzt, und dann "line-by-line" Syntax für die (wenigen) "spezifischen" Attribute, das ganze (eingeschränkt) "parseParams-kompatibel" (was dein Vorschlag nicht ist) - also "immer gleich" aus User-Perspektive (ok: aus Kompabilitätsgründen zu vorhandener Syntax: halbwegs). Das Ergebnis des Parsens findet sich konsolidiert im RHASSPY-Hash, der User kann sehen, ob alles paßt. RHASSPY-Attr werden bei der Eingabe via FHEMWEB (klar - wann sonst) gecheckt, der User erhält eine qualifizierte Rückmeldung, in welcher Zeile er den Fehler suchen muss.

Für Einsteiger welche nur kopieren kann man einen Einzeiler machen. Sie verstehen es eh nicht.

Wenn die Syntax zu komplex ist, verstehen sie sie umso weniger => einfach halten.

Einsteiger mit Verständniss-ambitionen können die entity Schritt für Schritt "hochfahren", testen und abwandeln.
[..]
Hoffentlich verständlich dargestellt.
Zusammenfassend: Es ist nur eine andere Möglichkeit, attribute zu setzen.

Verständlich ja, aber bei einem Einzeiler will ich keine Attribute setzen _müssen_ - wenn die "neu"-DEF und die passenden Attribute dann aus der "einfachen" Syntax abgeleitet werden, wäre das aber ok.

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

Im Prinzip ja, im Detail habe ich eine (mal wieder: historisch gewachsene) Ausnahme im Angebot...

Bedingt korrekt. Niedergeschrieben ist fast nichts.

Jein. Wo es wichtig ist, könnte man das nachziehen, korrekt. Das "verständlich" zu schreiben ist leider fast unmöglich, da endlos und für verschiedene Zielgruppen auch kaum "in one" zu machen. Zu viel Doku hilft auch nur bedingt, weil man sich damit teilweise auch nur einmauert. Und das dauernde allgemeine darauf hinweisen macht es nicht besser.

Verhalten und Einstellungen einerEntity wird über Attribute gemacht.

Würde das so formulieren: Verhalten und Einstellungen einer _komplexen_ Entity sollte über Attribute gemacht werden können. Für einfache Fälle ist eine "one-liner"-DEF mAn. die bessere Variante. Speichern muss man beides.

Parameter wie "native Adresse" gehören in das Define. Danach wird es dünn.

Bei RHASSPY ist es neben einer IP auch eine Tonne von Optionen, die in der Regel keiner braucht und die teils nur zu Testzwecken da ist. Dafür Attribute zu generieren wäre nicht einfacher, sondern erhöht nur den Erklärungsbedarf. Teile dieses Dogma daher nicht.

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)

Über die "Erfordelichkeit" des Change Wizzard kann man lange streiten. Fakt ist: Wer ihn benutzt, bekommt funktionierende NOTIFYDEF (aka effizientere Vorabauswahl der dem notify zu zeigenden Events).
Er bekommt auch "ersetzte Leerzeichen", was eine Sache ist, die jeder User sowieso lernen muss.

Schade, dass hier die User nicht zu Wort kommen.

[marvin78]

Du nennst AutoShuttersControl @Beta-User. Das Modul macht es mEn genau falsch. Es gibt viele Attribute und viel zu konfigurieren. Daher sind viele Attribute ok. Aber die Dafaults sind versteckt in der (nachzubessernden) Doku und offenbar im Code. Sie sollten direkt in vorhandenen Attributen stehen. Das wäre userfreundlich und da kommt man an den Punkt, dass man mit vielen Attributen leben kann. Alternative wäre, die Doku zu verbessern, was offenbar schwer ist.

mEn sollte Konfiguration in den Attributen stattfinden, was aber, aus meiner Sicht voraussetzt, dass die Defaults auch als Attribut vom Start an vorhanden sind. Anderfalls ist es kaum zu durchschauen.

[Beta-User]

Du nennst AutoShuttersControl @Beta-User. Das Modul macht es mEn genau falsch. Es gibt viele Attribute und viel zu konfigurieren. Daher sind viele Attribute ok.

Vorab: Ich bin nicht in allen Punkten einig, wie es in ASC gelöst ist, und manches würde man/CoolTux heute vermutlich anders machen als früher.
Da ist das Problem, dass die Wechselwirkungen nicht immer einleuchtend sind. Es wäre m.E. in vielen Fällen einfacher, wenn alle Angaben in einem Attribut stehen könnten. Beispiel:

Code Auswählen Erweitern

attr <shutter> ASC_Morning mode=astro early=6:30 late=7:30 earlyWE=7:30 lateWE=9:00 pos=99 posSlat=99
Da gibt es "nur" das Problem, dass es kein User-Interface dafür gibt (aber zwischenzeitlich eine Tonne von get-Anfragen)...

Aber die Dafaults sind versteckt in der (nachzubessernden) Doku und offenbar im Code. Sie sollten direkt in vorhandenen Attributen stehen. Das wäre userfreundlich und da kommt man an den Punkt, dass man mit vielen Attributen leben kann. Alternative wäre, die Doku zu verbessern, was offenbar schwer ist.

Zwischenzeitlich (EDIT: genauer gesagt seit 4 Wochen: https://svn.fhem.de/trac/changeset/25056/trunk/fhem/FHEM/73_AutoShuttersControl.pm) kann man die Attributbeschreibung zumindest im shutter selbst sichtbar haben, von daher ist man jetzt an einem Punkt, an dem man den User besser leiten kann, was wie funktioniert und zusammenhängt und wie die defaults sind. Verbesserungsvorschläge sind bei CoolTux sicher willkommen, und wir sollten die Diskussion an der Stelle nicht vertiefen.

mEn sollte Konfiguration in den Attributen stattfinden, was aber, aus meiner Sicht voraussetzt, dass die Defaults auch als Attribut vom Start an vorhanden sind. Anderfalls ist es kaum zu durchschauen.

Für RHASSPY ist es in der Regel völlig überflüssig, irgendwelche defaults auch am "Zielgerät" sichtbar zu machen und als Attribut zu setzen. MAn. kommt es darauf an, was das jeweilige Modul daraus macht (und wieder ist ASC m.E. ein schlechtes Beispiel, weil manche defaults nicht "anwenderfreundlich" gewählt wurden, und man die im Prinzip immer ändern muss => falscher Ort).

Es sollte am Ende für den User transparent sein, und deswegen zeigt RHASSPY auch an, welche Einstellungen am Ende zum Tragen kommen. Aber zentral und nicht am Zielgerät. Würde ich heute für ASC auch so vorschlagen, ist übersichtlicher. Wie war hier zu lesen: hinterher ist man immer schlauer...

[marvin78]

Vorab: Ich bin nicht in allen Punkten einig, wie es in ASC gelöst ist, und manches würde man/CoolTux heute vermutlich anders machen als früher.
Da ist das Problem, dass die Wechselwirkungen nicht immer einleuchtend sind. Es wäre m.E. in vielen Fällen einfacher, wenn alle Angaben in einem Attribut stehen könnten. Beispiel:

Code Auswählen Erweitern

attr <shutter> ASC_Morning mode=astro early=6:30 late=7:30 earlyWE=7:30 lateWE=9:00 pos=99 posSlat=99

Das sieht gruselig aus. ABER es würde zumindest die Zahl der Attribute und auch den Dokumentationsaufwand deutlich verringern. Aktuell ist die größte Schwäche solcher Module, dass die Doku in den Attributen verstreut ist (sie sich aber nur im Kontext miteinander erklären), Verweise von einem auf das andere falsch, veraltet oder nicht vorhanden sind. Die direkte Anzeige hilft da dann nur bedingt bzw. kann sie sogar störend sein. Meine Sicht: bspw. ASC kann man aktuell nicht nur mit Doku einrichten. Man muss die Forenthreads und das Wiki zu Hilfe nehmen, wenn es komplexer wird. Es würde sich einfacher Dokumentieren lassen, wenn man schon bei der Einrichtung der Konfiguratrion an die Doku denken würde (ich verstehe aber, dass das schwer bis unmöglich ist). Aber du hast recht, das gehört nur bedingt hier her. Auch wenn ich meine, dass man schon erstmal an solchen Stellen ansetzen sollte. Die Beispiele in diesem Thread (auch zu notify und Co.) zeigen, dass vieles an der Dokumentation hängt. Aus meiner Sicht zumindest.

[Beta-User]

Das sieht gruselig aus.

Da bin ich übrigens völlig bei dir - und auch bei Martin: Es ist nicht "Couch"-tauglich, und damit als Userinterface komplett untauglich. Es gibt daher diverse Würgarounds über readingsGroup, um die Einstellungen irgendwie handhabbarer zu machen...

Wollte ja nur klarstellen: "DAS" Optimum gibt es nicht...

(die Lösung in diesem Fall wäre vermutlich wirklich, wenn sich jemand die Mühe machen würde, ein UI dafür zu schreiben, dass dann die Werte an passender Stelle in die Attribute schreibt...).

EDIT: Da ich hier immer ein Modul zitiert habe, das nur wenige in Einsatz haben, zwei screenshots zur Verdeutlichung, was mit "Tonnen von Optionen" im DEF gemeint ist, und wie die Attributhilfe in etwa aussieht (und die Syntax).

EDIT2 - und noch ein list von RHASSPY nach Auswertung der Attribute, defaults, ... an den untergeordneten Devices (Achtung - Testgerät, daher "nicht schön"):

Code Auswählen Erweitern

Internals:
   CONFIGFILE ./rhasspy-de.cfg
   DEF        devspec=room=Rhasspy,devstrich0 baseUrl=http://192.168.33.1:12101 defaultRoom="cuarto de estar" language=de
   FUUID      6047564b-f33f-b0ff-76fc-f00e32724eb1a76a
   IODev      m2client
   LANGUAGE   de
   MODULE_VERSION 0.4.41a
   NAME       RHASSPY
   NR         25
   STATE      connect to http://192.168.33.1:12101 timed out
   TYPE       RHASSPY
   baseUrl    http://192.168.33.1:12101
   defaultRoom cuarto de estar
   devspec    room=Rhasspy,devstrich0
   encoding   utf8
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1
   .asyncQueue:
   .attraggr:
   .attrminint:
   READINGS:
     2021-11-05 12:22:15   IODev           m2client
     2021-05-25 13:10:42   lastIntentPayload {"Channel":"YouTube","customData":null,"input":"schalte um auf YouTube","intent":"MediaChannels","probability":1,"rawInput":"schalte um auf youtube","requestType":"voice","sessionId":"2e6c60a7-2a81-43f2-a3bc-cad755c10359","siteId":"default"}
     2021-05-25 13:10:42   lastIntentTopic hermes/intent/de.fhem_MediaChannels
     2021-03-10 10:23:50   listening_Wohnzimmer 1
     2021-05-25 13:10:42   responseType    voice
     2021-06-10 08:42:15   siteIds         base,satellite
     2021-11-05 12:24:15   state           connect to http://192.168.33.1:12101 timed out
     2021-04-15 13:56:38   timer_bad       14:06:38
     2021-05-25 13:10:42   voiceResponse   OK
   TIMER:
   helper:
     custom:
       Respeak:
         function   Respeak
         args:
           NAME
       SetAllOn:
         function   SetAllOn
         args:
           Room
           Type
       SetCustomIntentsBasicTest:
         function   RHASSPY::Demo::BasicTest
         args:
           siteId
           Type
       SetCustomIntentsDataTest:
         function   RHASSPY::Demo::DataTest
         args:
           NAME
           DATA
       SetCustomIntentsDialogueTest:
         function   RHASSPY::Demo::DialogueTest
         args:
           NAME
           DATA
     devicemap:
       Channels:
         rhasspy:
           Netflix:
             Sonos
           SkyOnline:
             Sonos
           YouTube:
             Sonos
           orf drei:
             lampe1
           orf eins:
             lampe1
           orf zwei:
             lampe1
         wohnzimmer:
           Netflix:
             Sonos
           SkyOnline:
             Sonos
           YouTube:
             Sonos
       devices:
         Sonos:
           alias      sonos
           confirmIntents SetScene,SetOnOff
           groups     multimedia
           names      sonos
           rooms      rhasspy,wohnzimmer
           Channels:
             Netflix    launchApp Netflix
             SkyOnline  set Fernseher launchApp SkyOnline
             YouTube    setreading Sonos open plugin://plugin.video.twitch/?channel_id=CHANNEL_ID&mode=play
           confirmIntentResponses:
             SetOnOff   wirklich $target $Value
           confirmValueMap:
             off        ausfahren
             on         ein fahren
           intents:
             GetNumeric:
               volume:
                 currentVal volume
                 type       volume
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             SetNumeric:
               volume:
                 cmd        volume
                 currentVal volume
                 maxVal     100
                 minVal     0
                 step       2
                 type       volume
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
             SetScene:
               SetScene:
                 scene1     scene1
                 scene2     scene2
                 scene3     scene3
                 scene4     scene4
         Stimmungsleuchte:
           alias      stimmungsleuchte
           groups     lampen
           names      stimmungsleuchte
           rooms      rhasspy,wohnzimmer
           intents:
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             SetColorParms:
               color:
                 cmd        color
                 currentVal color
                 map        percent
                 maxVal     6500
                 minVal     2000
                 step       1
                 type       color
               ct:
                 cmd        ct
                 currentVal ct
                 map        percent
                 maxVal     500
                 minVal     154
                 step       1
                 type       ct
             SetNumeric:
               brightness:
                 cmd        pct
                 currentVal pct
                 maxVal     100
                 minVal     0
                 step       5
                 type       brightness
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
             SetScene:
               SetScene:
                 id=0F5VwJFcHpymkm2 Nachtlicht
                 id=1N0Ow9IjFvwJWOb Energie tanken
                 id=1a6rDrpjg-i33u8 Tropendämmerung
                 id=7r1VzbwX5H5VVqW Gedimmt
                 id=968VgE7b29JysiY Sonnenuntergang Savanne
                 id=IYY-Qkhs6577mil Lesen
                 id=J88yqZyARhlQh4q Sonnenuntergang Savanne
                 id=Kd35TY8qIb6pTax Hell
                 id=Ke4VCTMCsSNaIli Nachtlicht
                 id=Li5XQV2Ckvcl9ac Tropendämmerung
                 id=MkBqmt1iphIRayB Entspannen
                 id=QszaD6316SsOGNX Hell
                 id=SOcyx8ZWLqI73MR Sonnenuntergang Savanne
                 id=UloxktBtdsVJEUg Nordlichter
                 id=WGjGSBvWPfW0JH0 Konzentrieren
                 id=amg18-TICTPiayR Frühlingsblüten
                 id=fmsyN3Ve4fYGqhG Frühlingsblüten
                 id=g9hPzEGZkAR2g5j Entspannen
                 id=gbca4wF9Vni8oSb Entspannen
                 id=iJiMFXkE57qvCJ7 Energie tanken
                 id=ig9Hb2jZ6iP9X0E Konzentrieren
                 id=jJAU3n8QlDZI4Zh Hell
                 id=kcz2eYl2goK91Hz Konzentrieren
                 id=l9gNnheN-NwDIgY Nordlichter
                 id=lk39fWLRdxjTqVl Nordlichter
                 id=nEY-TZ2qVEx6WpP Gedimmt
                 id=oZRhLrscoEgC7Xu Gedimmt
                 id=qk7qNpKVeugEugh Lesen
                 id=s-co9adxMQsAsEz Lesen
                 id=wZdk5cpy35oldlw Frühlingsblüten
                 id=yJ0tWdBhE-emL3q Nachtlicht
                 id=ykGAH5vm9qguUhm Energie tanken
                 id=yzMdTFOtJPAIVel Tropendämmerung
         blind1:
           alias      blind1
           names      blind1
           rooms      rhasspy
           intents:
             GetNumeric:
               dim:
                 currentVal state
                 type       setTarget
             GetOnOff:
               GetOnOff:
                 currentVal dim
                 valueOn    100
             SetNumeric:
               setTarget:
                 cmd        dim
                 currentVal state
                 maxVal     100
                 minVal     0
                 step       11
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     dim 0
                 cmdOn      dim 100
                 type       SetOnOff
         devstrich0:
           alias      mülleimer
           groups     global_test,
           names      mülleimer
           rooms      h harmony
           intents:
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             MediaControls:
               MediaControls:
                 cmdStop    stop
             SetColorParms:
               color:
                 cmd        color
                 currentVal color
                 map        percent
                 maxVal     6500
                 minVal     2000
                 step       1
                 type       color
               ct:
                 cmd        ct
                 currentVal ct
                 map        percent
                 maxVal     500
                 minVal     154
                 step       1
                 type       ct
               hue:
                 cmd        hue
                 currentVal hue
                 map        percent
                 maxVal     65535
                 minVal     0
                 step       1
                 type       hue
               rgb:
                 cmd        RGB
                 currentVal RGB
                 type       rgb
               sat:
                 cmd        sat
                 currentVal sat
                 map        percent
                 maxVal     254
                 minVal     0
                 step       1
                 type       sat
             SetNumeric:
               brightness:
                 cmd        pct
                 currentVal pct
                 maxVal     100
                 minVal     0
                 step       5
                 type       brightness
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         lampe1:
           alias      lampe1
           groups     licht
           names      lampe1
           rooms      rhasspy
           Channels:
             orf drei   set lampe1 on
             orf eins   set lampe1 on
             orf zwei   set lampe1 off
           intents:
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             MediaControls:
               MediaControls:
                 cmdBack    previous
                 cmdFwd     next
                 cmdPause   pause
                 cmdPlay    play
                 cmdStop    stop
             SetColorParms:
               rgb:
                 cmd        rgb
                 currentVal rgb
                 type       rgb
             SetNumeric:
               brightness:
                 cmd        brightness
                 currentVal brightness
                 map        percent
                 maxVal     255
                 minVal     0
                 step       10
                 type       brightness
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
       rhasspyRooms:
         h harmony:
           mülleimer devstrich0
         rhasspy:
           blind1     blind1
           lampe1     lampe1
           sonos      Sonos
           stimmungsleuchte Stimmungsleuchte
         wohnzimmer:
           sonos      Sonos
           stimmungsleuchte Stimmungsleuchte
[...]
  shortcuts:
       Witze:
         NAME       RHASSPY
         perl       Witze()
       du bist cool:
         fhem       set $NAME speak siteId='wohnzimmer' text='Danke du auch'
       ton an:
         NAME       lampe1
         conf_req   Bitte bestätigen!
         conf_timeout 15
         perl       {fhem ("set $NAME on")}
       ton aus:
         NAME       RHASSPY
         perl       {fhem ("set lampe1 off")}
     tweaks:
       confirmIntentResponses:
         SetOnOff   Gerät $target $Value schalten
         SetOnOffGroup $target $Value schalten
       confirmIntents:
         SetOnOff   .*
         SetOnOffGroup licht|rollläden
       timerSounds:
         Eier       3:20:./flasche1.wav
         Kartoffeln 5:./flasche2.wav
         default    ./flasche.wav
Attributes:
   IODev      m2client
   languageFile ./rhasspy-de.cfg
   rhasspyIntents Respeak=Respeak(NAME)
SetAllOn=SetAllOn(Room,Type)
SetCustomIntentsBasicTest=RHASSPY::Demo::BasicTest(siteId,Type)
SetCustomIntentsDataTest=RHASSPY::Demo::DataTest(NAME, DATA)
SetCustomIntentsDialogueTest=RHASSPY::Demo::DialogueTest(NAME,DATA)
   rhasspyShortcuts ton aus={fhem ("set lampe1 off")}
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"
i="ton an" p={fhem ("set $NAME on")} d=lampe1 c="Bitte bestätigen!"
Witze=Witze()
   rhasspyTweaks timerSounds= default=./flasche.wav Eier=3:20:./flasche1.wav Kartoffeln=5:./flasche2.wav
genericDeviceType=noSlots=1
confirmIntents=SetOnOffGroup=licht|rollläden SetOnOff=.*
confirmIntentResponses=SetOnOffGroup="$target $Value schalten" SetOnOff="Gerät $target $Value schalten"
   verbose    5

[martinp876]

Egal wie man optimiert, es wird fuer jedes Event mehr Code ausgefuehrt, als bei den "einfachen" notifies.
Der Unterschied ist vmtl irrelevant, Optimieren hilft nur dann, wenn man (wie oben erwaehnt) Hunderte von notifyFns und Hunderte von Events pro Sekunde hat.

du bist bei der Trigger-regex? Ich hatte über die cmd-regex gesprochen.
Um die Notify-performance zu tunen kann man erst einmal sauber in <name> und <event> trennen. Das sollte viel bringen. Das Format des aktuellen "notify-define" ist nicht zwingend, hier zu trennen. Schon einmal der erste Fehler. Auch für den User schwieriger!

[martinp876]

nun, wie erwartet haben wir ein unterschiedliches Verständniss. Die Bedienung wie von euch favorisiert ist für mich gruselig. Automatisierung hat etwas mit Vereinfachung zu tun - auf allen Ebenen.
1) Die Hierarchie der Kunden( User)
  a) der Konfigurator
       Definitert die Entites, erstellt die primären Verknüpfungen, legt die Konventionen fest (namen, Attribute) um seine Verknüpfungen "automatisieren" zu können.
       Erstellt automatismen, nach welchen sich entites in seine Konfig einordnen
       Der Config muss viel nachdenken und Grundsätze festlegen - für SEIN system
       Sollte sich mit Regex auskennen
  b) der Administrator
       Verlinkt Aktionen, eher soft-links und Reaktionen. Nutzt einfache Kommandos, typisch set,... (kein setReading, das macht ggf der Config)
  c) der Maintainer
      wertet das Systemverhalten aus. Typisch stellt der Config hier Auswertungen zu Verfügung. Keine besonderen Kenntnisse über Regex oder Perl. Schwierigkeinte werden an Admin oder Config "gemeldet".
  d) der User
      will nur "gnöbbsch drügge" - im besten Fall noch nicht einmal das
2) der Skill-level
  Der Admin wird vom Konfigurator in das System eingeführt. Der Konfigurator kennt den Skill-level des Admin und muss die Config entsprechend aufbereiten.
  Der Konfigurator und dessen Skills sind also der Schlüssel
  a) newby
      Def: Kein programming Hintergrund, kein Verständniss für Regex vorhanden.
      Fähigkeiten: Das ganze System wird eher schlicht aufgebaut sein. Es stehen nur einfache Methoden zu Verfügung. Alles, was nicht einfach durch ein Sammel-Modul machbar ist, ist ausser reicheweite. "Queries" sind nich tmöglich
      => ich sehe nicht, wie ich hier helfen könnte. Wenn sich der Config technisch weiter entwickelt wird es besser.
      => FHEM bietet hier die "einfachen"  und "dummen" Optionen.
  b) Advanced
     Def: Programmiererfahrung vorhanden, kann Systemaitken begreifen, ist in der Lage zu strukturieren, hat Grundverständniss für regex und Mehoden
     Fähigkeiten: Kann Vorlagen nutzen. "Templates" ist hier ein Schlüssenwort. Man kann ein (sortiertes) Repository zur Anwendung geben. Er kann diese  nutzen und ggf auch anpassen
     => Konfigurationen können semi-automatisch erstellt werden. Er hat das im Griff und kann es kontorllieren - in Grenzen.
   c) Professional
     Def: kennt sich mit Regex aus, kann Perl, kann FHEM -interne Funktionen nutzen und weiss, was er tut
     Fähigkeiten: Baut sein System systematisch und weitgehend selbst-konfigurierend auf (das ist dann echt cool, verlangt aber können!). Generiert Templates und, wenn er es wirklich kann, stellt es anderen zu Verfügung (als Advanced können es nutzen)

Wer bin nun ich? Nun alles. Ich Konfiguriere das System und erarbeite mir gerade eine Auto-config Methode.
Ich konfiguriere mein System am Schreibtisch, so dass ich es vom Sofa aus administrieren kann. Ich erwarte von meinem Konfigurator-Ich dass alles in "Templates" easy zu Verfügung steht.

Unter diesem Hintergrund ist mein Notify zu verstehen. Das "Define" wird vom Config erstellt. Die Attribute kann der admin ausführen. Der User drückt nur die Gnöbbsche.

FHEM ist meine Wahl WEIL ich mit Queries arbeiten kann. Das Notify performant zu machen, auf mit regex im Trigger, ist kein Problem sondern eine Herausforderung - und lösbar. Aber wen sage ich das. Ohne
Defines und die meisten Attribute sind "config-level". Es ist die Aufgabe der Programmierer, bei allen Config-Massnahmen die Daten für den operational Level so vorzubereinte, dass performant gearbeitet werden kann.
Wenn ich euch nun erkläre, wir man das erreichen kann, ist das natürlich anmassend - und ich glaube gesehen zu haben, dass es schon erledigt ist.
Kurz:
- Ein Notify sollte den Trigger nach "Name" und "event" zwingend splitten (warum das implizt gelöst ist, erschiesst sich mir nicht)
- Wird "trgName" geändert muss der notify-hash-tree korrigiert werden
- wird ein Define/modDef ausgelöst, wird der notify-hash-tree korrigiert
- wird ein delete ausgelöst, wird der notify-hash-tree korrigiert
=> das kann im Notify oder im Notify-hash des Kernal gelöst werden
=> Operational Performance kostet das nicht!
=> Es ist alles Lösbar wenn man will
=> wenn es keine Glaubt setze ich mich hin, und baue ein Performantes UND felxibles Notify.

Next: neue Module und Funktionen
- Ich schliesse mich der Aussage eindeutig an, dass KEINE neuen Methoden oder Module notwendig sind, alles auf die Reihe zu bekommen. Man muss erst einmal die Vorhandenen renovieren. Wie Rudi schon gesagt hat, hatte er vor Jahren keine Zeit, das Notify auf Attribut-Level zu bringen (verstehe ich) - aber nun wird es Zeit.

Es gibt etliche Anmerkungen welche ich kommentieren möchte. FHEM macht Automatisierung. Das muss sich auf im Front-end wiederspiegeln!

Notify ist ein Kern-Modul. Nicht Kernal, das ist das "OS". Aber in einem zentralisierten System ist Notify neben "at"  DAS Schlüsselmodul. Hierüber sollten in der Theorie ALLE Connections von Sensoren zu Aktoren geroutet werden. Praktisch eher nicht, da die Performance zu gering ist.

Mir würde es erst einmal reichen, ein Notify auf Stand zu bringen - und das unter klaren Regeln, wie ein Modul gestaltet werden soll. Evtl mache ich das Parallel - und man kann es diskutieren.

[martinp876]

ich habe mir  sub notifyRegexpCheck($) { angesehen - und hier liegt wie erwartet schon das erste Problem. Es wird nach "|" gesplittet was schlicht zu kurz gesprungen ist.

Mein "trg" "FB_.*(Short|Long).1_.*\(to.ccu\).*"
kann ich in "trg" "FB_.*:.*(Short|Long).1_.*\(to.ccu\).*"
aufteilen. Der Check prüft falsch und erkennt

FB_.*:.*(Short: devspec FB_01,FB_02,FB_03,FB_04,FB_05,FB_06,FB_07,FB_08,FB_09,FB_10,FB_11,FB_12 (OK)
Long).1_.*(to.ccu).*: no match (ignored)

Man man kann es nicht verdenken. Wieder ist der Grund die lasche und faule Spec (sorry) des Trigger.

Würde ich (schon wieder) den "trg" einfach in "trgName" und "trgEvent"spalten könnte Rudi es auch ordentlich parsen und einsortieren.
trgName FB_.*
trgEvent .*(Short|Long).1_.*\(to.ccu\).*

Was dann nicht mehr klappt ist ein Trigger wie "name1:event1|name2:event2". Das schein hier die vorherrschend "einfache" definition zu sein. Für mich ist das eine Option für Skill level "advanced newby".
In diesem Fall handelt es sich um 2 Trigger, welche in der Eingabe typisch mit ";" getrennt werden. Das Oder einzubauen ist sache des Moduls.
=> ich brauche diesen Mix nicht. Wenn notwendig lasst es sich auch lösen.
=>"name1:event1|name1:event2" ist eine Option.

Wenn man es schön einfach machen will kann man diese Optionen für trgName zulassen
trgName FB_.*
trgName FB_01|FB_02|FB_03
trgName FB_.*|RB_3
trgName FB_.*;RB_3
trgName FB_.*|xx_.*;RB_3

all das ist einfach zu "compilieren"
split(";",$trgName) => search per regex thru defines
=> create unique list

Ich gehe davon aus, dass hier in der Developer-Ecke das Konzept verstanden ist.

Man kann eine Übergangszeit machen, in welcher auch "Trg" als kombined zugelassen ist.
FHEM würde gut daran tun, einen "komplianze-check" vorzuhalten. Sollte nun ein aktuellen define "name1:event1|name2:event2" vorliegen welches nicht automatisch konvertiert werden kann kann man den Configutaror eine Liste "this entry is not complient - please correct or contact sys-admin - it may not be supported after update"
=> dies sollte Systemweit geschehen  - damit hat man den ersten Anker, Änderungen durchzuführen.

[rudolfkoenig]

Komplexer könnte es dann mit Eränzungen so aus sehen:

Danke fuer die Erklaerung. Ich bin nicht abgeneigt, setList in notify einzubauen, falls auch Andere dafuer sind.
readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

setList als Framework Funktion ist mir zu aufwendig, und geht mMn in die falsche Richtung, genauso wie die vorgeschlagenenen Readings* Funktionen.

[martinp876]

Noch ein Nachtrag, auch wenn ich erkenne, dass Weihnachten wohl ausfällt

1) das Notify "smart" anzulegen, (notifyRegexpCheck ist ein guter check) ist nicht unterstützt, kann nicht wirklich geprüft werden und ist somit unsichtbar. Nach Funktionen im fhem.pl sourcecode zu suchen kann noch nicht einmal einem professional skill Level configurator zugemutzt werden. Das ist des Verfassers Geheimwaffe.
2) wenn man Name und Event trennt ist obiges nicht mehr notwendig. Der einzig akzeptable Weg für mich. Schade, das sich das nun manuell erstellen muss.
3) mein "trigger"-Template habe ich angepasst , s.u. .Wenn ich die Regeln kenne ist das einfach. => auch mit Regex kann man konform sein. Die Struktur des Kernal ist aus meiner Sicht sehr gut - nur die Implementierung in Notify unterstützt dies sehr schwach
4) ein Notify, oder besser jede entity, sollte prüfen können
    a) wen es triggert
    b) von wem es Trigger bekommen kann.
    ==> ein Get notify-Info wäre sinnvoll
    {join("\n",sort map{$_=~s/^(.*)\:.*/$1/;;$_} grep/ntfy_FB12/,map{$_.":".join(',',@{$ntfyHash{$_}})}keys %ntfyHash)}
5) das Get sollte auf Basis des %ntfyHash erstellt werden (klar, denke ich)
6) für den professional Configurator sollte ein
    {join("\n",map{$_.":".join(',',@{$ntfyHash{$_}})}keys %ntfyHash)}
    zu Verfügung stehen, damit er prüfen kann, was zu optimieren ist. So etwas muss man doch nicht immer wieder aus dem Code ziehen.
    Ich denke mangels Alternative wäre es in "global" gut aufgehoben.
Erschreckend, dass Module wie LightScene ihren NOTIFYDEF nicht setzen. Hier ist ja nun wirklich einfach, die relevanten trgNames zu definieren. Da werde ich wohl in die Rolle des Freaky-Configurators schlüpfen mussen und die Notifies der Nachzügler manuell korrigieren müssen. Performace ist mir wichtig.
   
Die nach aktueller Syntax korrekte schreibweise meines triggers wäre
"FB_.*:.*Short.1_.*\(to.ccu\).*|FB_.*:.*Long.1_.*\(to.ccu\).*"
Lieber wäre mir immer noch
attr trgName FB_.*
attr TrgEvent .*(Short|Long).1_.*\(to.ccu\).*

Schade eigentlich, dass aufräumen so unpopulär ist.

[Beta-User]

Danke fuer die Erklaerung. Ich bin nicht abgeneigt, setList in notify einzubauen, falls auch Andere dafuer sind.

Funktional wäre ich dafür, aber mit dem Namen hadere ich etwas, weil funktional ja nicht das notify irgendwie betätigt wird, sondern nur eben ein Reading gesetzt wird - was dann schon Auswirkungen haben kann, die aber in der Regel nicht direkt was mit dem Device zu tun haben.

Bei dummy ist klar, dass das keine funktionale Auswirkung hat, weil das "nur ein Speicher" ist. Bei notify fürchte ich Verwirrung bei den Usern.

Just my2ct.

[Ellert]

readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

Aktuell funktioniert  im Dummy nur die Kombination readingList und seLlist, ohne readingList wäre es dann eine neue Funktionalität.

[justme1968]

Erschreckend, dass Module wie LightScene ihren NOTIFYDEF nicht setzen

nein. ich finde es nicht erschreckend. zum einen ist LightScene sehr viel älter als NOTIFYDEF und zum anderen hat LightScene einige eigene Optimierungen eingebaut die nicht unbedingt schlechter als NOTIFYDEF sind. wenn z.b. kein browser offen ist wird die NotifyFn sehr früh direkt wieder verlassen.

im übrigen waren für NOTIFYDEF auch einige runden nötig weil die ersten versionen ohne cache zu langsam waren.

das heisst nicht das sich das ganze nicht noch optimieren lässt, aber zumindest habe ich bisher noch keine meldung gesehen das LightScene tatsächliche performance probleme hat. ganz so schlimm ist es also wohl nicht.

ich glaube es gibt stellen in fhem an denen eine optimierung deutlich mehr bringt. by the way: hast du mal gemessen wie die performance unterschiede zwischen vielen kleinen notifys für jede der 12 tasten im vergleich zu einer version mit einem notify für alle tasten und anschließendervVerzweigung sind?

[rudolfkoenig]

readingList ist in dummy notwendig, damit die set Argumente nicht im state landen.
Da ich nicht vorhabe, im notify state zu aendern, ist es da nicht notwendig.

[martinp876]

 nun - nachdem mein Threat gekapert wurde mache ich noch einen Versuch.

Angesprochen hatte ich eigentlich die (natürlich aus meiner Sicht) unpassende Defintion bspw von Notify. Weiter sehe ich nicht, dass dies für den User - insbesondere bei der aktuellen Doku-Lage wirklich einfacher ist. Es ist möglich, das aktuelle notify auch clever zu nutzen. Unterstützt wird es nicht, im Gegenteil.
Schade, dass sich schon alle arrangiert haben und somit zufrieden sind.
Stattdessen wird über readingList diskutiert oder setList. Konkret habe ich hierzu keine Meinung, da mich er Konkrekte Implementierungsplan, Syntax uns Semantik interessert. Scheinen alle zu wissen, ok - aber schon wieder ein abdriften.

Wie ich mit ein Notify vorstelle kann man im Anhang sehen. Es ist noch tuning notwendig....
Den WebInterface Wizzard müsste ich noch löschen. Doku ist auch noch nicht enthalten...
Ich werden das nicht veröffentlichen... Wäre aber schön, wenn das Ürsprüngliche Thema wieder betrachtet wird.
Erinnerung: keine parameter sondern Attribute
Bewertung unter ignorieren der aktuellen Implementierung - wie würde man es jetzt erstellen (grüne Wiese!). Erst danach: Wie kommt man da hin.

Btw: Mehrere Readings im Bulk zu setzen ist nicht meine Problem. Mache ich regelmäßig mit Userreadings.

Wäre schön, wenn wenigstens käme: das wollen wir nicht, weil inkonsistent.
Aber wer glaubt schon an den Weihnachtsmann

[rudolfkoenig]

Wäre schön, wenn wenigstens käme: das wollen wir nicht, weil inkonsistent.

Ich will das nicht, weil mAn der Nutzen in keinen sinvollen Verhaeltnis zum Aufwand ist.

[Benni]

Ich bin nicht abgeneigt, setList in notify einzubauen, falls auch Andere dafuer sind.
readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

Hallo Rudi,

Ich würde gerne nochmal auf diesen "Nebenkriegsschauplatz" aus der vorangegangenen Diskussion zurückkommen.

Das würde u.a. den Umweg über sertreading, sowie wahrscheinlich diverse userattr ersparen und natürlich die Eingabe vereinfachen

Was mir dabei allerdings zum Glück noch fehlen würde wäre, dass notify auch stateFormat unterstützt. Bisher ist zwar devStateIcon vorhanden, aber der Vollständigkeit halber sollte m.E. auch stateFormat dabei sein.

Mit dieser Kombination könnte ich zumindest bei mir eine ganze Menge dummy-Devices und teilw. readingsProxy los werden.

Vielleicht magst du deiner Unabgeneigtheit bei Gelegenheit noch nachgeben?

Eventuell fände das auch noch der eine oder andere gut, dann kann er das ja gerne noch kund tun.
(Müsste man ggf. mal noch außerhalb des Developer-Bereichs abfragen?)

gb#

[rudolfkoenig]

Ich warte nur auf Meldungen, hier: https://forum.fhem.de/index.php/topic,123956 gibt es schon eine Umfrage, bisher ohne Feedback.
Diese Diskussion sollte auch da weitergefuehrt werden.
Bei zwei Leuten bin ich ja schon fast soweit, was zu tun

[martinp876]

Ich habe notify nun einmal nach meinem dafürhalten umgebaut. Ist aktuell nicht aufwärts kompatibel - kann man aber machen. Dennoch sehe ich hier einige dinge realisiert welche Rudi sowieso wieder ablehnen wird . Alles in allem sind hier m.E. einige Aspekte realisiert welche ich mir wünschen würden - unabhängig von notify. JEDES! module sollte nach diesen Grundsätzen arbeiten - oder abgewandelt, klar. Aber Grundsätze eben.
Das schränkt die Freiheit der Programmierer ein - was m.E. kein Schaden sein muss.
Und eigentlich ist es nicht so weit weg von allem - nur eben STRICT! Wird nicht gerne gesehen hier.
Grundsätze sein
1) CPU performance @ operations
2) memory performance
3) CPU performance @ config
4) WISIWIG

Die Kommandos werden definiert auf Module ebene und/oder auf entity Ebene. Vielen Modulen wird die Modulebene reichen (notify bspw) - einigen nicht (CUL_HM,...).
Jedes Kommando wird spezifiziert - möglichst komplett mit Parametern.
Der Parser "ntf_cmdParser" prüft die Kommandos und deren Parameter nach Anzahl und Inhalt gemäß Spec. Default Parameter werden automatich eingefügt.
=> beim Abarbeiten der Kommandos kann sich der Programierer darauf verlassen, dass mandatory params auch vorhanden sind
=> der User kann mit "get cmdList" sehen, was programmiert ist - direkt. Nicht von einer Kopie sondern im Orginal
=> Defaults werden gesetzt - automatisch
=> die replies bei fehleingabe sind standartisiert
>>> die Funktion ntf_cmdParser ist generisch und kann so für jedes Modul eingesetzt werden. Eigentlich sollte es eine kernal funktion sein. Eigentlich sollte sie automatisch ausgeführt werden.

Ein starres System? nein.
- Kommandos können auf Modul-ebene on-the-fly nachgereicht/modufiziert werden - ok. der Programmer muss ein re-eval starten.
  eingebaut haben ich zum testen alle Kommandos mit "tst.*". Hier kann der geneigte Programmer einmal neue Kommandos einpflegen und löschen. Diese Funktionen sind natürlich nicht relevant für notify, nur zur Evaluierung.
- Parameter mit "Dynamic Option List" werden automatisch gearbeitet. Sowohl in drop-down listen alsauch im parser

=> der Anwender bekommt nun konsistente Eingabe - bspw wenn ein Kommando keinen Parameter hat wird auch KONSEQUENT! noArg eingetragen. Eine Schlamperei welche ich schon häufig gesehen habe.

=> die Performance  des beliebten und wichtigen Kommandos "set xx ?" und "get xx ?" liegt deutlich unter 1ms!

Eingebaut sind set, get und auch attr. Leider ist das Handling bei attr abweichend - nun ja. Dennoch habe ich den selben Algorithmus eingebaut.
Die Funktion "ntf_AttrCheck" ist hier notwendig - siehe Implementierung. Hier wird auch konsequent durchgesetzt, dass nur gültige Attribute zugelassen sind. Der User muss also erst UserAttribute definieren bevor er sie nutzen kann. Wenn er UserAttribute löscht mussen auch die Attribute gelöscht werden. Eine hässliche Lücke in fhem welche schon seit beginn besteht. Das handling der userAttr habe ich noch nicht drin werde ich in ntf aber noch machen.
==> es kann nicht sein, dass attribute eingetragen werden können welche eine Reboot nach Save nicht überleben!


So - nun noch eine etwas weichere Forderung - notification/rename/define/... . Notifications von "global" sind - im Gegensatz zu allen anderen  - Config-notifications. Alle anderen sind "operational-notifications".
Jedes Modul  - übergreifend - Konfigurationsänderungen berücksichtigen. Das ist eigentlich standard. fhem hinkt hier weit hinterher.
Beispiel: Ich habe ein Notify welches auf  die Entity "LichtWohnLinks" triggert. Mache ich ein Rename von LichtWohnLinks nach LichtWohnraumLinks muss das notify automatisch! angepasst werden. Das trifft natürlich nicht auf "LichtWohn.*" zu. Alle nicht-unique entites werden nicht angefasst.


Fürs erste einmal gut. Zum Eigentlichen Notify nehme ich getrennt Stellung, kommt noch.

=> ich werde nur noch so arbeiten, auch wenn das Konzept -  wie vorhersehbar - abgelehnt wird.

[martinp876]

so, nun abgegrenzt die (einseitige) Diskussion zum Notify.
das "ntf" Spielzeug zeigt, wie es bei mir aussehen würde. Wenn "notify" nicht auf einen angemessenen Stand gebracht wird werde ich wohl mit meiner Version arbeiten. Natürlich ungefährlich - sieht ja keiner.
Was macht den Unterschied:

Pseudo -attribute in der Kommandozeile sind ein no-go. Nicht diskutable und nur durch historische Hintergründe zu rechtfertigen. Dieser Tage geht es garnicht.
Aus meiner Sicht schwierige Trennung des "trigger-Filter" nach trigger-device und trigger-event. Das kann man deutlich sauberer machen - für mich ist das ein schwer zu behandender Klumpen.
Wenn man es stringent macht kann man auch das enrolen beim Notify-filter wasserdicht UND flexibel gestalten. Einfaches Beispiel ist:
- triggerDevice ist ein regex (oder device-spec) wie la.* oder "attr room schlafzimmer"
- die betreffenden Devices werden identifizert und angemeldet
- bei einer config-Änderung (rename, define, delete, attr) werden die Devices neu gesucht und enroled
=> eigentlich nichts besonderes, so muss das.

ich habe 2 Optionen zur Trigger-erkennung vorgesehen - combined und getrennt nach triggerName und triggerEvent

Bei Trigger-combined kann man über ein Kommando neue trigger addieren oder alte entfernen. Es ist KEIN fancy web-interface notwendig.
=> man sollte erst versuchen, die Funktionen mit Bordmitteln zu lösen bevor man extra-frontends einbaut. Aus meiner Sicht ist das frontend-addon schlicht unnötig.

Falls Rudi mit den Argument kommt, attribute darf man nicht verändern müsste ich die Augen verdrehen. Das Define wird aktuell manipuliert - auf seltsame weise. Bei mit klappt es nicht, da es nur bei einigen wenigen Formen der Trigger-filter klappt.
Nein, die aktuelle Implementierung halte ich für kompliziert, unfelxibel und auch noch unschön.

Selbstverständlich werden in den Readings wesentliche daten automaisch angezeigt (eigentlich eine Selbstverständlichkeit). So ist das letzte triggernde Device als auch das event zu sehen. m.E. immer sinnvoll und auch extrem hilfreich beim Einrichten und Testen.

Gets waren bisher wohl auch verpönt. Ein get trgFilter zeigt mir, welche events von welchem Device mir dieses Notify auslösen.
"shEnroled" könnte man weglassen, bei mir bleibt es noch.

Was ich noch nicht bearbeitet habe ist, die probably assiciated list auf Stand zu bingen. Warum ich das internal "NOTIFYDEV" permannent brauche ist mir unklar - insbesonderen wenn die Liste lang wird stört mich der Eintrag mehr , als er nutzt. Hier könnte man zumindest smart abkürzen.
=> ein standard-get ala shEnroled ist deutlich besser, da sortiert und formatiert

Ach ja, neben den gets sind die "get list" und "get cmdList" eigentlich kernal-kommandos. Die sollten immer da sein. "get  notifyEnroled"  würde dazu passen.

Alles zusammen ist das meine beta-Version. Sicher nicht bug-frei und es werden mir noch Verbesserungen einfallen.

Das bestehende Notify auf einen "Modernen" Stand zu konvertieren ist mit Sicherheit möglich - wenn man will

Ich gehe davon aus, dass der Vorschlag den üblichen Weg meiner Vorschläge folgt. Damit werde ich mich wohl alles auf meine "ntf" umstellen. Notify ist machbar aber nicht tragbar für mich.

Und noch einmal - die seltsamen sonder-kommandos "tst.*" sind nur zum Ausprobieren für programmierer - mit notify habe sie nichts zu tun.
Frohe Weihnachten.

[martinp876]

scheint keinen mehr zu interessieren - verstanden.
Hier nun eine schon recht gute Version.
Die generische Prüfung von get/set ist lauffähig - parameter-check operational, dynamic-options funktioniert. Default-options klappt
get cmds und get list sollten generisch sein

zum eigentliche Notify
mit trgDevice kann man devspec nutzen. Wie es der Anwender erwaren kann wird die devspec ständig überwacht und angepasst. Renames werden erfasst genau wie definitionen.
Natürlich werden Attribute nur zugelassen, wenn sie definiert sind (sollte selbstverständlich sein)
Initialize wird berücksichtigt und attribute erst danach kontrolliert (selbstverständlich?!)

ntf_cmdParser werden ich ein
myKernal_cmdParser
umsetzen, da es auch vom "at" modul und allen anderen meinen Module genutzt werden wird.

Keine Angst, ich werde das nicht einchecken - das werde ich privat nutzen.
Und jetzt lasse ich euch in ruhe - mit dem Gefühl, dass Innovation und Struktur nicht wirklich ein Thema hier ist -noch nicht einmal diskutiert wird. Schade

[martinp876]

so, zumindest einer hat sich noch interessiert, daher poste ich meine aktuelle Version - und erkläre sie.
Hier beschreibe ich jetzt einmal das API für den Sys-Configurator und wo ich die Vorteile sehe
1) die attribtue werden, wie schon beschrieben, in attributen, nicht im define abgebildet. Selbsterklärend.

2) trigger-namen
- werden sauber im Kernal notify-hash angemeldet
- können als "devspec" mit regex eingetragen werden - oder auch nicht. Natürlich auch regex für namen
- kernal-notify wird auf Stand gehalten bei allen Config Änderungen (rename, define,ignore,...)
- devspec auswertungen sind eingeschränkt. Es werden nur "config" relevante elemente betrachtet. D.h. Readings werden ausgeklammtert. Internals sind eingeschränkt, da diese nicht sauber unterschieden werden. Attribute sind Konfigurationen.

3) Der User hat mittlerweise 3 Möglichkeiten, den trigger-filter zu gestalten. Ihm muss bewusst sein, das ein trigger-filter besteht aus
<device>:<reading>: <value>
wobei er ":" und ": " beachten muss. Sicher ein lustige Falle... naja
a) explizit: attribute "tgrDevice", "trgReading","trgReadValue" können eingetragen werden. ALLE mit regex. Diese Optionwäre wohl für Anfänger passend.
Vorteil: Der User kann sich seine Readings ansehen und entscheiden: Diesen will ich haben. Die ":" werden automatisch gesetzt
b) readingPacked:"tgrDevice", "trgEvent"
Als trgEvent ist "<reading>:  <readingValue>" einzutragen. Den ": " muss er selbst setzen.
Vorteil: man kann lustige Kompinationen aus reading und value gestalten.
trgEvent wird kumulativ zu "trgReading","trgReadValue" eingebaut.
c) allIn: "tgrCombined".
Der Konfigurator erstellt eine komma-separierte Liste aus Filtern. Sehr mächtig - für Fortgeschrittene. Das Format ist wie bisher. Evtl muss beim "Komma" nachgebessert werden.
Das Modul erkennt automatisch die hier enthaltenen "trgNames" und meldet sie an.
Auch dieses attr wird kumulativ eingebaut.

4) entity Info
der User kann nun seltsame konfiguraionen erstellen und fragt sich, was nun eigentlich Sache ist. Es ist natürlich PFLICHT!!! ihn hier zu unterstützen.
a) get trgFilter
gibt eine Aufstellung zurück, welche entites nur gefiltert werden und welche Readings/values hier relevant sind
(ich sollte noch einbauen, dass Readings und values deutlich unterschieden werden in der Anzeige - gute Idee)
b) get shEnrolled
zeigt hart an, welche entites von Kernal nun durchgereicht werden.
Vorteil zu "NOTIFYDEV": die Liste könnte länger werden. NOTIFYDEV kann hier den gesamten Bildschirm versauen
NOTIFYDEV ist nicht vorhanden wenn .* eingetragen wird. Das ist sowieso irreführend.
NOTIFYDEV brauche ich eigentlich nicht. Geschmackssache

5)Readings
es ist eigentlich selbstredend, dass die letzten Trigger als Reading  erscheinen.

6) Aufräumen
ein "set clear" sollte immer zu verfügung stehen, alte Readings zu entfernen. Ein cleansweep erleichtert das debuggen.

7)logTrgNames
nun, hilfreiche für eine Übersicht.

Defizite:
- ntf ist nicht eingebunden in "events" und den autmatischen update. Eine kleinigkeit, es zu machen. Für mich persönlich irrelevant - so arbeite ich nicht.
- tgdCmds muss man manuell eintagen. Da "set" recht schmall ist könnte hier ein wizzard helfen. Allerdings sind meine Kommandos typisch nicht durch einen wizzard zu lösen. Dennoch eine Option.
- ein paar kleinigkeiten welche ich nachbessern werden.

[martinp876]

bugfix ( noch nicht bug-free - sorry)

[martinp876]

noch ein Nachtrag:
alle trigger sind gleich - nur einige sind gleicher.
"Global" ist eine andere Kategorie von triggern. Die sind hier reingewurstet... macht es nicht einfacher, aber möglich.
Global bietet alle Sys-Kommandos sowie die eigenen Readings. Da der Kernal hier nicht unterscheidet muss es der Anwender. Glücklicherweise kommt es nur selten vor.
Programmer allerdings mussen es berücksichtigen.

[Beta-User]

Also, ich würde das gerne mal aus User-Perspektive verstehen wollen. Daher hier der Versuch, mit der letzten ntf-Version folgende Aufgabe zu lösen:

Die Fritzbox meldet regelmäßig, welche mac-Adressen noch da sind bzw. wer ggf. dann inaktiv geworden ist. Die mac-Adressen sind - soweit interessant - einzelnen RESIDENTS-Instanzen zugeordnet, anderer Code ist dann dafür zuständig festzustellen, ob daraus ein "present" gebastelt werden soll usw..

Meine aktuelle Lösung:

Code Auswählen Erweitern

define rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {\
  chop($EVTPART0);;\
  my $target = getKeyValue($EVTPART0);;\
  return if !$target;;\
  $EVTPART1 eq "inactive" \
  ? fhem("setreading $target smartphone absent")\
  : fhem("setreading $target smartphone present");;\
}
Die Zuordnung von mac-Adresse erfolgt also derzeit (zugegebenermaßen: etwas überkompliziert) über das Auslesen der Werte aus uniqueId (früher mal mit 'fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");;\'). Nachdem ich gestern erst darüber nachdenken mußte, wie man die Zuordnung aktualisiert, wenn mal wieder jemand das Smartphone getauscht hat, stellt sich die Frage, wie man sowas mit ntf so löst, dass der "user" das unfallfrei hinbekommt.

Also mutig ans Werk.

1. define ohne Parameter ist nett. Keine Vorüberlegungen dazu, auf was eigentlich reagiert werden soll oder "gib-Ruhe"-Klammern erforderlich. Soweit angenehm.

2. Unter ntf (also leider: sehr weit hinten...) finden sich dann einige Attribute, deren Namen einigermaßen selbsterklärend sind.
- trgDevice (Fritzbox) mit einfachem Klick ausgewählt => angenehm!
- trgReading mit regex ist auch noch selbsterklärend.

3. und nun...? Jetzt habe ich zwar diese "event-to-action"-Tabelle via Attributen vor meinem geistigen Auge, bin aber im Prinzip bei "Defizit #2" angelangt:

tgdCmds muss man manuell eintagen. Da "set" recht schmall ist könnte hier ein wizzard helfen. Allerdings sind meine Kommandos typisch nicht durch einen wizzard zu lösen. Dennoch eine Option.

Eventuell könnte es helfen, eine Art "devspec-to-action"-Attributliste generieren zu können, aber für meine Aufgabe bräuchte es dann vermutlich ein Attribut pro mac-Adresse und Richtung. Auch nicht unbedingt selbsterklärend aus reiner User-Sicht.
Aus "Konfigurator"-Warte fehlen mir vermutlich noch ein paar Beispiele, wie man sowas zweckmäßigerweise löst, aus heutiger Sicht werde ich wohl das notify-Perl so erweitern, dass die mac-Adressen per Hash einem RESIDENT zugewiesen werden, dann ist der Teil an einem Ort vereint.


Bilanz aus meiner Sicht zu einigen anderen angerissenen Punkte bis hierher:
- wie NOTIFYDEV ermittelt wird, ist für viele User (nicht nur bei notify, auch bei ähnlichen Modlen wie FileLog, DbLog und watchdog) unverständlich. Ein besserer Parser wäre super, ist aber vermutlich nicht "günstig" zu bekommen (meine eigenen Versuche, dazu einen Vorschlag zu machen, habe ich irgendwann mangels Erfolg eingestellt, immerhin kann man als "Wissender" mit der dafür vorgesehenen Funktion feststellen, an welcher Stelle es hakt).
- den "wizzard" (für notify und at) habe ich in der Vergangenheit wenn, dann nur versehentlich "genutzt", den Drang, diese Funktion auszuschalten (siehe z.B. https://forum.fhem.de/index.php/topic,123819.msg1185275.html#msg1185275), kann ich daher durchaus nachvollziehen...

Der Strauß ist also groß, und ich würde jetzt gerne erst mal wissen, wie die "Muster"-Lösung zu meinem obigen Problem ggf. aussehen könnte.

[martinp876]

1) meine FB Implementierung funktioniert wieder einmal nicht. Somit kann ich es nicht nachstellen - also alles "Trocken"

2) dass Modul-specific attr alphabetisch einsortiert werden habe ich bereits angemerkt und es sollte nach etwas hin und her nun so eingebaut sein. Grundsätzlich kann ich das  nicht beeinflussen.

3) zu 2.: nun könntest du das reading-value eingeben, wenn du willst. Default ist "alles", also ".*"
  -> eine Einbindung in den Event-Monitor ist jederzeit möglich - da ich es nicht brauche habe ich es noch nicht realisiert. Hier ist auch jede Menge Luft nach oben...

4) das Kommando
   hier hast du tatsächlich recht, es gibt keine Unterstützung. Ist aber kein Konzept-problem und ich kann es auf unterscheidliche Arten lösen.
   a) notify unterstützt dies mit der web-application. Diesen Teil könnte man einbauen... Das unterstützt "einfache" Kommandos (welche auch gebraucht werden)
   b) Die Implementierung wie bei "registern" in CUL_HM - also ein pop-up. Ist deutlich schöner finden ich. Die Funktion ist erst einmal identisch. Allerdings kann man die Liste VIEL! schöner machen
   c) Komplexe Kommandos kann man nur schwer unterstützen. Hier hat der konfigurator explizit die Freiheit, coole Sachen zu machen. Das ist ein Grund, warum ich fhem gewählt haben.

Also: du kannst dein Kommando wie bisher in

Code Auswählen Erweitern

attr rr_xn_MAC_Check trgCmd {\
  chop($EVTPART0);;\
  my $target = getKeyValue($EVTPART0);;\
  return if !$target;;\
  $EVTPART1 eq "inactive" \
  ? fhem("setreading $target smartphone absent")\
  : fhem("setreading $target smartphone present");;\
}

eingeben.
=> schlechter ist das nicht - besser auch nicht.

Um für dein Anliegen nun einen Vorschlag zu machen (ich suche auch hier nach einer Lösung) müsste ich die Readings sehen. Du musst das Event in den Namen in FHEM übersetzen.

Code Auswählen Erweitern

{fhem ("setreading $EVTPART0 smartphone ".($EVTPART1 eq "inactive"?"absent":"present"))}
sollte hinreichend sein. Wenn es das target nicht gibt, wird nichts gemacht - das Kommando prüft es sowieso - musst du nicht.
Das mit "getKeyValue" kenne ich nicht, wäre aber

Code Auswählen Erweitern

{fhem ("setreading ".getKeyValue($EVTPART0)." smartphone ".($EVTPART1 eq "inactive"?"absent":"present"))}
Eine Zeile, alles drin.
Wenn meine FB wieder einmal antwortet werde ich es noch einmal ansehen. Allerding ist das auch ein modul, mit dem ich überhaupt nicht zufrieden bin. Ich würde sagen, man hat wert auf user-feindliche Darstellung gewählt.
btw: ist das Attribut "trgCmd" nicht verständlich? Welcher Name wäre besser, um zu erfassen, dass hier das "Commando" hinterlegt werden soll, welches bei erfolgreichem Trigger ausgeführt werden soll.

Zum ntf:
Ich werden "state" immer explizit eingeben - das ist in deiner Version  noch nicht enthalten. Grundsätzlich sollte man beim Erstellen eines API prüfen, ob es komplitzert ist. Wenn man das beschreibt und ma viel schreiben muss um es zu erklären, ist es komplex.
ntf besteht im Wesentlichen aus dem Event-Filter und sekundär aus den Kommando.
Ich beschreiben einmal, wie ich "ntf" dokumentieren würde (also mal schnell so runter...)

ntf is a module to execute commands dependant on events. I.e. the event triggers the command defined by ntf "trgCmd".
An event raised when a reading of a device is set or changed. See also "event-on-change-reading" and "event-on-update-reading". An event ist assembled as
       <deviceName>:<readingName>: <readingValue>

Da wäre nun einfache - anzumerke ist, um komplett zu sein
- der Programmierer kann das Triggern von Events unterbinden. da wartet man nun lange.
- das "state" reading wird ausgeblendet - was das erstellen und parsen des strings absolut unnötig verkompliziert. Ich bin schon oft hierrüber gestolpert - und nutze nun das Reading "state" grundlätzlich nicht für filter. In ntf habe ich nun umgeschaltet auf "state" einblenden - immer.
- konfigurationen sind zu erklären. Also alle events von "global". auch auf diese kann man triggern. Allerding ist das Format unterschiedliche. Auch ist keine Liste dokumentiert, was hier alles kommen kann (und wann)

So, jetzt FB reparieren

[martinp876]

So, FB operational.
Ich kann die readings zu inactive nicht finden. Somit ist es schwer zu helfen oder grundsätzliche Empfehlungen zu geben.

[Beta-User]

So, FB operational.
Ich kann die readings zu inactive nicht finden. Somit ist es schwer zu helfen oder grundsätzliche Empfehlungen zu geben.

Das ist ein Event, der nur genau einmal kommt, wenn ein Gerät sich "abgemeldet" hat:

Code Auswählen Erweitern

2021-12-12 07:07:58 FRITZBOX Fritzbox mac_24_6F_28_A2_76_B0: OMGBuero (WLAN, 0 / 0 Mbit/s, 0)
2021-12-12 07:07:58 FRITZBOX Fritzbox mac_00_80_41_E1_31_E9: WIZnet-1
2021-12-12 07:07:58 FRITZBOX Fritzbox mac_84_F3_EB_EF_FB_7F: inactive


Das Problem mit meinem notify ist aber noch ein ganz anderes: die Ergebnisse waren bei mehreren Geräten zunehmend zufällig...
Um das Problem mit einem notify zu lösen, muss man tiefer graben:

Code Auswählen Erweitern

defmod rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {\
  my $targets = {\
    "mac_A1_99_75_5E_7A_BB:" => "rr_Mann",\
    "mac_E1_DC_FF_EE_62_C3:" => "rr_Frau"\
  };;\
  for my $evt ( deviceEvents($defs{Fritzbox},0) ) {\
    my $target = $targets->{$EVTPART0} // next;;\
    $evt =~ m{inactive\z}xms \
    ? fhem("setreading $target smartphone absent")\
    : fhem("setreading $target smartphone present");;\
  }\
}

....(aus mehreren Gründen) unschön...

PS: Bandwurm-concats finde ich nicht gut, dann um der Leserlichkeit willen lieber eine Zeile mehr. (zugegeben: Geschmackssache).

[martinp876]

Ich denke ich habe dich falsch abgeholt. Zur Bewertung von ntf betrachten wir, was du bislang hast:
   trgDevice ist auf eine einzige Entity gesetzt
   trgReading is gesetzt auf einen Filter. Da mehrere Readings ausgewertet werden sollen sieht es aus wie "mac.*"
                     zu beachten: alle Eingaben sind "umfassend". Es muss der komplette String definiert werden. ggf eben mit .* abschliessen
   trgReadValue: muss nicht gesetzt werden - steht per default auf ".*", also alles.
==> nun ist ntf scharf. Device UND reading sind angegeben. Sollte ein Event eintreten werden die Readings hierzu erzeugt.
ntf debug support
  - get trgFilter: zeigt, welcher Filter real aktiv ist. Hier ist auch zu sehen, dass "^.*$" gefiltert wird. Kann evtl nicht jeder lesen, sollte aber doch vielen helfen. Bei mit ist es

trigger:
   myFritz -> ^(mac_.*: .*)$

Reading list
lastTrgDevice  myFritz
lastTrgEvent   mac_00_A0_DE_A8_39_3F: stereo
lastTrgReadVal   stereo
lastTrgReading   mac_00_A0_DE_A8_39_3F
log_myFritz   mac_00_A0_DE_A8_39_3F: stereo

==> noch vor der Definition des Kommandos kann man prüfen, dass der Filter sitzt.
+++ Ich gebe ntf hier 0.5 Punkte vorsprung auf notify wegen (deutlich) besserer debug Optionen built in
set clear readings macht einen cleansweep und ist ebenfalls hilfreich die Übersicht zu behalten.

-----------------------------------------
so nun mal zu den interessanten Dingen - langsam steigernd:
hast du mehrere FBs (ok, nicht realistisch, aber für die Erklärung hinreichend).
a) attr trgDevice einfach um die 2. Instanz erweitern (Hacken setzen). Die Readings sind identisch. Das ist einfacher als notify
+++ Ich geben ntf noch einmal 0.3 Punkte für selektive editierbarkeit

b) wir sind fortgeschrittene Configuratoren (oder kopieren eine Vorlage). Ziel ist es, alle FBs aus unserem System AUTOMATISCH!!! in das notify einzubinden. Alle FBs haben "TYPE=FRITZBOX". Wir können also devspec nutzen. Jetzt muss man tippen... keine hacken setzen

Code Auswählen Erweitern

attr trgDevice TYPE=FRITZBOX
Jetzt kommen wir in den wirklich coolen Bereich. Ich behaupte, der service ist full-featured (irgend eine Lücke wird man noch finden)
b1) mit "get shEnrolled" kannst du sofort kontrollieren, welche entites für das notify zugelassen sind.
b2) get trgFilter zeigt dir, welche realen Filter aktiv sind.
*** test: mache ein "define AA FRITZBOX". Schon hast du ein weiteres test-device.
b3) full featured: ntf evaluiert die settings @entry, nicht @operation. Notifies werden nur zugelassen, wenn entites auch spezifiziert sind. ok, ".*" geht auch... wenn der Anwender es herausfordert. ntf hält die Liste über die gesamte Systemlaufzeit aktuell. D.h. alle define/delete/rename/ignore werden berücksichtigt - übrigens auch alle attribute. Änderungen werden umgehend eingearbeitet.
+++ Hierfür geben ich ntf 2 dicke Punkte - mindestens.

###> am Ende ist ntf eigetnlich nur auch einem Stand, den man erwarten kann. Kein gebastel, keine unleserlichen String-schlangen welche auch noch gemicht ein müssen, kein attribut im Define. Ganz wichtig: Performance - alles wird zur Config-Zeit vorgearbeitet und AUF STAND GEHALTEN! in FHEM leider nicht üblich.

Praktische Anwendung: ich habe ein notify welches die Ventilstellung der Heizkörper zusammenfasst (und eines welches die Anzahl der eingeschlateten Lichter auswertet).
Um die HKs zu erfassen kann man

Code Auswählen Erweitern

trgDevice model=HM-CC-RT-DN:FILTER=i:DEF=......04
trgEvent ValvePosition.*
filtert mir alle RTs aus CUL_HM und das Reading ValvePosition.
Bei anderen Familien muss man natürlich anders filtern.

Nachsatz:
ich habe noch 2 Bugs entdeckt  beim Setzen von trgDevice ist trgReading nicht betrachet worden - und get trgFilter sollte schöner werden. Reading und value separieren.

[martinp876]

Zu deinem letzten Post:
FRITZBOX ist .... nun hier ist room-for-improvement.
ich werde damit nicht arbeiten - macht einen Sinn. De-Factor habe ich bereits eine private Version. Ich habe gerade auf die offizielle zurück gestellt - nur um zu testen.

Für die Verifikation von ntf sollte es aber reichen, erst einmal auf "mac_.*" zu filtern.

Ach ja, wer wert auf performance legt sollte
attr .* event-on-change-reading .*
setzen. zumindest für CUL_HM ist das praktikabel
attr TYPE=CUL_HM event-on-change-reading .*

[martinp876]

ok, have it.
Also 1) bitte ntf weiter prüfen. Ich habe neben den angegebenen Vorteilen noch einige grundsätzliche Verbesserungen welche ich schritt für schritt erkläre. Nicht alle sind User-sichtbar.
2) FRITZBOX ist .... non-of-my-style. De-facto kann ich es nicht nutzen. daher habe ich vor einiger Zeit einmal begonnen, es umzuschreiben. Es ist nicht auf meinem aktuellen Standard von einem "system-konformen" modul - aber für mich schon deutlich besser.

a) Im Anhang eine neue Version von ntf mit i) korrigiertem Verhalten beim trgDevice setzen und ii) verbesserte Darstellung von get trgFilter
b)im Anhang meine unfertige Version von FRITZBOX. Du solltest vorher eine Sicherungskopie machen. Die Implementierung ersetzt FRITZBOX und ist nicht parallel zu installieren wie etwa ntf. Es reicht allerdings, die Einstellungen deiner FB zu kopieren und bei Rückbau wieder auszuführen.


Solltest du beides aktiv haben kannst du

Code Auswählen Erweitern

define a ntf
attr a trgDevice TYPE=FRITZBOX
attr a trgReading IP_.*active
attr a trgCmd {$EVENT=~ m/IP_(.*)_active: (.)/;fhem ("setreading $SELF $1 active:$2")}

attr TYPE=FRITZBOX readingOn IPState

wenn du dann durch bist mit pre-test kannst du live gehen

Code Auswählen Erweitern

attr a trgCmd {$EVENT=~ m/IP_(.*)_active: (.)/;fhem ("setreading $1 smartphone ".($2?"active":"inactive")}
set a clear readings


So einfach könnte es sein, wenn module ein sinnvolles API haben

[martinp876]

So, und nun side-topic. Sync von FB zu presence.
1) ich nutze meine Version von FRITZBOX. Die allgemein-gültige ist nicht nutzbar für mich
2) ich nutze meine Version von Presence. Die allgemeingültige ist nicht nur nicht nutzbar sondern schlicht gefährlich. Primär unkontrolliertes Nutzen von BlockingCall

Um Presence mit FB zu kopplen und die Namen zu synchronisieren bin ich über die IP adresse gegangen.

damit (mein) Fritzbox das passende Reading ausspuckt ist

Code Auswählen Erweitern

attr TYPE=FRITZBOX readingOn IPName
zu setzen.

Code Auswählen Erweitern

attr myNtf   trgCmd     {$EVENT =~ m/IP_(.*?):.*active:(.).*ip:(.*)/;
my($pr)=devspec2array("TYPE=PRESENCE:FILTER=ADDRESS=$3");
fhem ("setreading $pr FBname $1;setreading $pr FBstate ".($2?"active":"off"))}

attr myNtf    trgDevice  TYPE=FRITZBOX
attr myNtf   trgReadValue active:.*
attr myNtf   trgReading IP_.*

Das Command muss natürlich komplett in das attr trgCmd gepastet werden.

Im Presence-modul erscheint dann der FB-name des Geräts so wieder der Zustand.

FRITZBOX ist wie gesagt nicht fertig..... das genügt  nicht meinen Ansprüchen. Anregungen gerne.

Aber bitte erst ntf!

[Beta-User]

Ich denke ich habe dich falsch abgeholt.

Weiß nicht.

Folgendes war bei mir aus dem Ausgangspost hängen geblieben:
- Die funktionalen Teile je in ein eigenes Attribut packen wäre für's Editieren einfacher (Zustimmung)
- Das einzelne notify (ohne "globales" trigger-Kommando) testen zu können wäre nett (verhaltene Zustimmung)
- notify ist schweigsam (erledigt)

Dazu kam der "teaser" mit der universellen Fernbedienungslösung. Klang erst mal unübersichtlich, war ja aber auch auf der "alten" Basis gestrickt. Wenn es irgendwas (aus User-Sicht) einfacher gemacht hätte, wäre das ein echter Fortschritt. Das hat mich ermutigt zu dem Experiment mit der Fritte, da ähnlich, aber nicht gleich.

Mein Feedback zu den originalen Themen:

1. define ohne Parameter ist nett. Keine Vorüberlegungen dazu, auf was eigentlich reagiert werden soll oder "gib-Ruhe"-Klammern erforderlich. Soweit angenehm.

2. Unter ntf (also leider: sehr weit hinten...) finden sich dann einige Attribute, deren Namen einigermaßen selbsterklärend sind.
- trgDevice (Fritzbox) mit einfachem Klick ausgewählt => angenehm!
- trgReading mit regex ist auch noch selbsterklärend.

3. und nun...?

Im Prinzip hat sich durch den Exkurs jetzt relativ wenig geändert, außer, dass mir in dem Zuge noch ein paar andere Probleme ins Bewußtsein gekommen sind (dazu weiter unten).

Weiterer Aspekt war, insbesondere auch auf rename-Events zu reagieren. An sich finde ich den Gedanken charmant, es hapert in meiner persönlichen Bewertung dabei aber auch wieder an einer Stelle: Manchmal muss/will ich Geräte tauschen - und da geht es mir z.B. auch bei LightScene gegen den Strich, dass das das rename des alten Devices nachführt. Ich will nämlich das neue erst mal 1:1 dort haben, was nicht geht, wenn man es nicht über die DEF lösen kann (also namentlich bei Wechsel des TYPE (ich nutze configDB, der Taschenspieler-Trick cfg-Edit geht daher nicht!))...

Soweit also erst mal zu den Kernaspekten - ich hoffe, die soweit vollständig erfasst zu haben.

Jetzt kommen hier aber am konkreten Beispiel weitere Aspekte auf den Tisch, deren Beurteilung mal wieder im oberen Bereich (oder oberhalb) meines Gesamtverständnisses liegen. Jetzt müssen plötzlich noch andere Module (unabhängig von der Berechtigung mancher Kritikpunkte!) mitspielen, damit alles wieder zusammenpaßt. Grundsätzlich bin ich ja für eine gewisse Einheitlichkeit, aber ab dem Punkt glaube ich nicht, dass genügend Leute mitziehen werden, um FHEM an so vielen Punkten umzugestalten - so das im Einzelfall überhaupt möglich ist.

Meine aktuelle Gemütslage ist:
- Das Ganze ist mir jetzt zu groß, ich will eigentlich nach Möglichkeit nur Module nutzen, die im svn verfügbar sind und mir nicht an jeder Ecke eine Sonderlocke reinziehen. Ganz blöd ist es, wenn ich im Forum ggf. irgendeinen Thread beobachten muss, ob's was neues gibt, wenn der Code nicht von mir selber ist. Wenn's was zu kritisieren gibt, ist es erlaubt, den betreffenden Maintainer (möglichst mit "F"-Ton) zu kontaktieren und darum zu bitten, Mißsstände zu beseitigen (das betrifft namentlich das PRESENCE-Ding, über das viele User stolpern!). Wenn das nicht klappt, wäre es besser, direkt "PRESENCE2" im svn anzubieten, oder die alternative Version nach contrib zu packen.
- Den "Wizzard" finde ich übrigens auch nicht besonders gelungen, und würde mir wünschen, den ohne "Startnotify" abschalten zu können.

Der eigentliche Haken ist m.E. folgender:
Völlig egal, wie man das im Detail aufdröselt, es kommen sehr schnell viele Aspekte zusammen, bei denen man als "Konfigurator"/"Administrator" oder "User" schlicht und ergreifend wissen muss, wie die interne Abarbeitungs-Logik ist. Das meiste ist dabei weitaus anspruchsvoller, wie durch passende <trigger>-Angaben dafür zu sorgen, dass NOTIFYDEV erzeugt wird (was ja auch "nur" ca. 30% Performancegewinn ist). Da ich meine notify (etc.) eher selten ändere, ist der Aspekt der leichteren Editierbarkeit für mich sekundär.

Dennoch finde ich weiter den Gedanken erwägenswert, insbesondere den <command> in ein Attribut auszulagern (gilt für notify, at und watchdog).

Die weiteren Probleme im Detail:
- Durch das Trennen von Device und weiterem Event ergeben sich neue, ggf. unbeabsichtigte Kombinationsmöglichkeiten. Ich fürchte, viele werden das nicht verstehen (nicht immer liegen bei mir identische Kommandos auf derselben Taste verschiedener Taster!);
- <trigger> ist in der "notify"-Schreibweise in einigen Modulen (z.B. auch FileLog und DbLog) zu finden. Wenn man es neu macht, müßte das für alle gelten, sonst muss man wieder zusätzliche Syntax lernen. Wenn also Attribut, kommt m.E. bestenfalls die "trgCombined"-Variante in Betracht;
- Die Abarbeitungsreihenfolge wird (im praktischen Leben fast ausschließlich) durch den Device-Namen bestimmt. Steht nirgends, aber bei verketteten Eventhandlern (z.B. infolge der setreading-Kommandos) muss man das beachten;
- "rename" ist von Übel, und egal, ob man es durch "Nachführen" löst, oder durch "User muss wissen, was er tut" (und überall manuell nacharbeiten), die gefundene Lösung wird nicht alle Probleme beseitigen. Als "Admin" sollte man sich einmalig eingehend damit befassen, wie Devices zu benennen sind, und damit sollte es dann "gut sein". Beim Tauschen hat man so oder so diverse Problemchen;
- bei Bulk-Events (oder zusätzlichen, zwischenzeitlichen setreading-Kommandos) muss der Eventhandler das berücksichtigen, wenn ggf. auch mehrere Events gleichzeitig passen können und jedes eine andere Aktion auslösen soll. Auch das steht vermutlich - wenn überhaupt - eher versteckt in der Doku.

Kurz meine Schlussfolgerung bis hierher: Man muss so oder so für komplexere Setups soviel wissen, dass es nur ein kleiner Schitt vorwärts wäre, die Syntax in Attribute zu verpacken. Von mir aus gerne, aber das weitere Aufdröseln schafft neue Probleme und macht es insgesamt auch nicht signifikant übersichtlicher, eher im Gegenteil, sobald es komplexer wird.

(EDIT: Formatierung)

[martinp876]

Ich sehe die Schlacht als verloren.  Übringen finde auch ich es schade, dass ich mir so viele Module umschreiben muss. Aber Fritzbox ist schlicht unbrauchbar, wenn ich das "acticve von IP Adressen tracken will, Presence schiesst gleich dsa System ab (keine Übertreibung),...
Notify ist teil-funktional.
Aber der ganze Threat ist nur in Development weil ich versuchte, ein paar coading - nein besser Architecture, API und handling-guidelines zur Diskussion zu stellen. Am Beispiel notify.

Ich halte meine Version an verscheidenen Stellen immer noch für deutlich Überlegen. Am Ende aber ist klar, dass beide Versionen Events filtern und darauf hin Kommandos ausführen.
Da ich keine Beschreibung geliefert habe wurde es evlt nicht verstanden (ich dachte in diesem Forumteil wird das erkannt).
Am Ende werden ich das API einmal an beispielen Erklären - dann habt ihr Ruhe von mir

Weiterer Aspekt war, insbesondere auch auf rename-Events zu reagieren.

Das ist nicht ein Aspekt sondern vielen.
1) ich triggere auf "room=Wohn" (devspec versteht sich). ein Modul IST VERPFLICHTET, alle Renames und Attr room änderungen zu folgen
2) rename eines CUL_HM device wird dessen assitiation (peerings) mitnehmen. das MUSS ich mitnehmen.
=> faktisch denke ich, dass alle HW entites durch umbenennen nicht zu resetzen sind.
=> wenn ich also bei rename NICHT alle mitziehe geht es halbe-halbe aus. Jeder Profi würde das nicht gelten lassen
=> wenn du eine entity "tauschen" willst sollte man eine entsprechende Funktion bauen. "replace" bspw.
##> Ich betrachte es als schlicht schlchter Stil, wenn man Funktionen "missbraucht" - nur weil keine Systemfunktion gebaut ist.
##> eine Dokumentation wäre notwendig (mehr als commandref!) welche die Semantik beschreibt. "Was soll rename erreichen". Daran kann sich dann jeder halten.
Beispiel: Ein notify auf entity "dev1" - dev1 ist angemeldet. Nun ein Rename "dev1" nach "dev2". def1 ist angemeldet , gibt es nicht mehr. ganz schlechter Stil. def2 ist abgekoppelt, kein notify... geht für mich garnicht. Nach save/reboot könnte sich dann auch noch alles ändern. NO!

Jetzt müssen plötzlich noch andere Module (unabhängig von der Berechtigung mancher Kritikpunkte!) mitspielen

das ist keineswegs der Fall. ntf ist selfcontained.
ok, ich hätte gerne 2 Funktionen in der Kernal - oder besser die Platform-utilitits verschoben. Aber das ist eine 2. Sache.
Was ich dir empfohlen habe ist eine Presence-Lösung welche meine (nutzbare) FB-Lösung nutzt und meine (low-perfornamce, stable) presence lösung nutzt und über notify kopplet. ntf ist hier m.E. die bessere, aber nicht die einzige Lösung.
==> ich habe den Yamaha networkplayer auf Stand gebracht... der Entwickler hat dies dankbarerweise übernommen und auf der Basis weiter gemacht. Das war super - eine Zusammenarbeit.
-- ich finde es  nicht cool, die Module anfassen zu müssen, aber wenn ich die ergebnisse schlicht für unbrauchbar halten bleibt mir nichts anderes übrig. Fix it or leave it.
Bei Presence gab es übrigens zuspruch - eingecheckt habe ich nichts- alles privat.

Das Ganze ist mir jetzt zu groß, ich will eigentlich nach Möglich.....

hier hast du mich abgehängt. Du musst nur ntf einspielen und es funktioniert. - kann hier und da noch getunt werden, sicher. ntf liefert alleine keine Lösung zut IP-Addressen Überwachung. war klar - oder?

Wenn das nicht klappt, wäre es besser, direkt "PRESENCE2" im svn anzubieten, oder die alternative Version nach contrib zu packen.

so etwas hasse ich. dem Anwender x optionen presence anzubieten und er muss raten, was der Unterschied ist. Ich biete etwas an - im Forum. Wenn der Entwickler nicht einsteigt und es keine höhere Instanz gibt ist es eben nur privat. Sieht keine mehr der nicht nachfragt. Ich stelle es gerne zu Verfügung, zur Diskussion. Aber fhem vernichten mit tausend varianten zum gleichen Thema - ich nicht.
==> das genau sind aber Themen für dieses Forum hier. Es gibt aber - ausser von dir - keine inhaltliche Diskussion. Also Ende Gelände.

als "Konfigurator"/"Administrator" oder "User" schlicht und ergreifend wissen muss, wie die interne Abarbeitungs-Logik ist

Logisch - imme. Notify genauso wie ntf. Commandref noch nicht geschrieben. Ein Versuch siehe unten.

Durch das Trennen von Device und weiterem Event ergeben sich neue, ggf. unbeabsichtigte Kombinationsmöglichkeiten.

saubere Konfigurationsmöglichkeinte!

<trigger> ist in der "notify"-Schreibweise i

Also über Namen der Attribute kann man reden - das ist nicht der Kern hier - oder? Event ist ein Ereignis. Trigger der Auslöser. Notify ... nn ja. Defacto ist es ein Event-FILTER welcher ddas kommado tieggert (eher nicht notifiziert). Aber das ist nicht das kernthema.

Die Abarbeitungsreihenfolge wird (im praktischen Leben fast ausschließlich) durch den Device-Namen bestimmt

Es gibt keine reihenfolge. Siehe unten.

bei Bulk-Events (oder zusät

Hier mus sich in der Tat nacharbeiten. das kann komplex werden - aber ich denke anders als du gerade denkst. Erst einmal wird ein Kommando ausgelöst, wenn der ... filter... passt. Nur über "$NAME, $EVENT" könnten es mehrer kommandos werden. Das werde ich noch bedenken... gute Tip.
#######################

So jetzt das versprochene commandref-quicky
ntf filters events which are issued by READINGS setting for devices. ntf will filter the events. Once the filter is passed the command is executed.
An Event is defined as
"<device>:<readingName>: <readingvalue>"
Filter can be assigned to ntf in multiple ways.
1) trgDevice matches <device> AND trgReading matches <readingName> AND tgrReadvalue matches <readingvalue>
OR
2) trgDevice matches <device> AND trgEvent matches "<readingName>: <readingvalue>"
OR
3) trgCombined matches "<device>:<readingName>: <readingvalue>"

examples
trgDevice="basementLight";trgReading="level";tgrReadvalue=".*";
==> filter passed any time, level is set for basementLight

trgDevice="b.*";trgReading="level";tgrReadvalue=".*";
==> filter passed any time, level is set for any device named b.*

trgDevice="room=living";trgReading="level";tgrReadvalue=".*";
==> filter passed any time, level is set for any device with the attribut "room" = living

trgDevice="basementLight";trgReading="level";tgrReadvalue="100";
==> filter passed any time, level is set to 100  for basementLight

trgDevice="(basementLight|level1.*)";trgReading="level";tgrReadvalue="100";
==> filter passed any time, level is set to 100  for devices basementLight and any device named level1.*

trgDevice="basementLight";trgEvent="lev.*x.*7"
==> filter passed any time, "readingName. readingvalue" matches "lev.*x.*7"  basementLight

ntf willkeep the trgDevice up to date for any configuration changes. I.e. if the filter is type=CUL_HM an da new device is defined NTF will immediately consider this. This is appliable for all device-spec definitions.
trgDevice assignements comply to devspec but will not consider filtering on readings. Just attributs, NAME and TYPE are valid.

trgCombined allowes very deticated filtering - howver it is recommended for experts only.  Example
trgCombined=".*light.*100.*" will trigger if just the string is matched - no matter whether is applies tothe device, the reading or teh value.
It can be use e.g. like
trgCombined="(light1:level:.100|light2:level:.50)" will tigger if light1 is on 100 or light2 is on level 50.

Anmerkung:
ntf ist m.E. deutlich effizienter im Assignment der deivces zu den notifications. Das ist ewenig sichtbar aber für mich sehr wichtig. a) dass es nicht sichtbar ist (so etwas läuftin Hintergrund) und b) dass es effizient ist.
Beschreibung ist (wäre) nicht final. Mir muss ich es nicht erklären - also wird es nie geschrieben.

Set/Get Parser ist ein anderes thema - genauso spannend - zu viel hier. Zu viel für das auditorium hier.
Frohe weihnachten, da wars wohl

[Damian]

Wenn FHEM-User ntf nutzen sollen, dann musst du es in einem anderen Board publizieren, hier wird sich keiner von denen verlaufen

[martinp876]

wie ich sagte- werde ich nicht.
Es gibt ausreichend Optionen für Event->notify->trigger. Noch ein weiteres verwirrt - der Anwender muss sich erst einmal klar werden, was der Unterschied ist. Manche Unterschiede sind sichtbar, andere habe eine andere Ablauf/Config systematik welche für den Anwender unsichtbar, aber optimal sein soll. Am Ende hängt dies zusammen, ist ein Gesamtkonzept. Das klar zu machen ist ... geradezu unfair dem Anwender gegenüber.
Ich habe es hier gepostet da ich die "Technologie" - oder Methodik präsentieren/Diskutieren/darstellen wollte. Eine wirkliche Diskussion über das "Angebot" hätte ich mir von Programmierern gewünscht, daher auch dieses Forum.
Leider hat es nicht stattgefunden.
=> eine Abstimmung mit den Füssen ist möglicherweise üblich, aber ich werden mich daran nicht beteiligen.
Wie gesagt, keine Diskussion, Ziel nicht erreicht, Thema beendet.