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

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