HM Geräte schalten doppelt/willkürlich

[maxritti]

Moin,

seit gestern bin ich mit meinem HM Rauchmeldern unterwegs und scheinbar ist das Problem gelöst.

https://forum.fhem.de/index.php/topic,124429.0.html

Allerdings hat sich seit dem ein neues Kuriosum eingeschlichen.
Ich habe u.a. einen HM-RC-2-PBU-FM, mit dem ich mehrere Lampen schalte.
Betätige ich den Tastater, reagiert ein DOIF und schaltet mehrere Lampen ein oder aus.

Funktioniert auch, nur seitdem ich wie im o.a. Post angegeben eine Aktualisierung meines FHEMs gemacht habe, gehen die Lampen beim einschalten an, aus und wieder an. Also doppelt gemoppelt.

Ich habe dann noch ein paar HM-LC-SW1-PL-DN-R1 im Haus verteilt, wo u.a. Fernseher und noch andere Lampen dran hängen.
Die sind wie von Geisterhand auf einmal an. Eben kam ich ins Schlafzimmer und dort war der Fernseher an.

Kann das an der Aktualisierung des 10_CUL_HM.pm liegen?

Seit gestern habe ich auch HMInfo im Einsatz. Und da fällt mir auf, wenn ich bei dem HMInfo "configCheck" nutze, gehen ein paar Devices an und wieder aus.

Ganz komisch...

Bin dankbar für jeden Tip.

[Beta-User]

...mehr Events.... Gerne gefragtes Thema...

[maxritti]

Na dann werde ich ich mal auf die Suche machen und hoffe dass ich was finde.

[Beta-User]

Du wirst einiges finden, hier mal ein Beispiel: https://forum.fhem.de/index.php/topic,112804.0.html. Allerdings hatte ich auch grade Mühe, passende Suchworte zu finden...

Allerdings wird dich das was du findest vermutlich nicht wirklich weiterbringen, weil es im Detail einfach immer von deinen Event-Handlern abhängt. Die sind in der Regel zu unscharf, wenn sowas passiert...

EDIT2: Wer von sehr CUL_HM-Versionen kommt, die etwas älter sind (>6 Monate) hat uU. das Problem, dass sehr viel mehr Events kommen als früher und manche Eventhandler dann zu "unscharf" sind. In der Folge werden dann uU. viel zu viele Aktionen ausgelöst. Bitte daher ggf. auch die Event-Handler mal kritisch ansehen (die Foren-Suche sollte viele derartige Fälle bringen).
EDIT3: Spezielles Suchwort für EDIT2 noch: "commStInCh off" (ist aber nur eine Teilabhilfe!).

[maxritti]

Ich bin am überlegen, dass ich mir eine zweite neue FHEM Instanz aufbaue und dann mal sukzessive migrieren.
Es scheint sich einiges getan zu haben.  Und so kann man auch mal aufräumen.

Habe im grossen und ganzen eigentlich "nur" diverse Zwischenstecker, Schalter, Rolladenaktoren, Temperaturfühler, Remote controls und zwei drei svgs. Eine eigene Rolladensteuerung hatte ich mal implementiert.

Aber wie das manchmal so ist mit "never touch a running system". 

[Beta-User]

Aber wie das manchmal so ist mit "never touch a running system". 

Das ist zum einen eine faule Ausrede und ein no-go, und zum anderen ist es so, dass sich jetzt eben die Auswirkungen zeigen, die letztlich darauf zurückzuführen sind, dass die Eventhandler schon immer "unscharf" formuliert waren. Hättest du gleich "sauber" gearbeitet, gäbe es keine Auswirkungen.

Erfahrungsgemäß ist es aber kein übermäßig großer Aufwand, das zu fixen, ich würde daher nicht gleich das Kind mit dem Bade auskippen. Ausmisten geht später dann immer noch...

[maxritti]

Okay, da magst du recht haben.

Aber ich vermute, dass meine Events doch schon recht scharf definiert sind.
Das DOIF sieht wie folgt aus:

Code Auswählen Erweitern

Internals:
   DEF        ([EG_wz_Licht_1] =~ /Short/) (set EG_wz_4K_Switch_4 on, set EG_wz_SD_LichtSofa on, set EG_wz_4K_Switch_2 on) DOELSEIF ([EG_wz_Licht_2] =~ /Short/) (set EG_wz_4K_Switch_4 off, set EG_wz_SD_LichtSofa off, set EG_wz_4K_Switch_2 off)
   FUUID      5c549a8a-f33f-b047-ffe4-1e40416b1225f4ee
   MODEL      FHEM
   NAME       di_EG_wz_Licht
   NOTIFYDEV  EG_wz_Licht_2,global,EG_wz_Licht_1
   NR         187
   NTFY_ORDER 50-di_EG_wz_Licht
   STATE      cmd_1
   TYPE       DOIF
   VERSION    24905 2021-09-01 18:35:54
   READINGS:
     2021-11-30 15:46:42   Device          EG_wz_Licht_1
     2021-11-30 15:46:42   cmd             1
     2021-11-30 15:46:42   cmd_event       EG_wz_Licht_1
     2021-11-30 15:46:42   cmd_nr          1
     2021-11-30 15:46:42   e_EG_wz_Licht_1_STATE Short 1_72 (to myVCCU)
     2021-11-30 15:46:42   e_EG_wz_Licht_2_STATE Short 1_109 (to myVCCU)
     2021-11-30 16:40:59   mode            enabled
     2021-11-30 16:40:59   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       EG_wz_Licht_1:
         0:
           &STATE     ^EG_wz_Licht_1$
       EG_wz_Licht_2:
         0:
         1:
           &STATE     ^EG_wz_Licht_2$
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          ::InternalDoIf($hash,'EG_wz_Licht_1','STATE') =~ /Short/
     1          ::InternalDoIf($hash,'EG_wz_Licht_2','STATE') =~ /Short/
   do:
     0:
       0          set EG_wz_4K_Switch_4 on, set EG_wz_SD_LichtSofa on, set EG_wz_4K_Switch_2 on
     1:
       0          set EG_wz_4K_Switch_4 off, set EG_wz_SD_LichtSofa off, set EG_wz_4K_Switch_2 off
     2:
   helper:
     DEVFILTER  ^global$|^EG_wz_Licht_2$|^EG_wz_Licht_1$
     NOTIFYDEV  global|EG_wz_Licht_2|EG_wz_Licht_1
     event      triggerTo_myVCCU: Short_72_ack
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   EG_wz_Licht_1
     timerevent triggerTo_myVCCU: Short_72_ack
     triggerDev EG_wz_Licht_1
     timerevents:
       triggerTo_myVCCU: Short_72_ack
     timereventsState:
       triggerTo_myVCCU: Short_72_ack
     triggerEvents:
       triggerTo_myVCCU: Short_72_ack
     triggerEventsState:
       triggerTo_myVCCU: Short_72_ack
   internals:
     all         EG_wz_Licht_1:STATE EG_wz_Licht_2:STATE
   readings:
   trigger:
   uiState:
   uiTable:
Attributes:
   do         always

Und das Interessante ist, dass zu dem Zeitpunkt wo ich an dem Schalter rumspiele um Events zu verifizieren u.U. andere Zwischenschalter, die so rein gar nichts mit dem Schalter und den zu schaltenden Lampen zu tun haben ihren Status ändern.

Hier wurde zum Beispiel der Fernseher im Schlafzimmer, das Licht im Schlafzimmer und ein Licht im Flur mit einem toggle befeuert.

2021.11.30 15:42:23 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 9863.
2021.11.30 15:42:23 3: CUL_HM set EG_wz_4K_Switch_4 on noArg
2021.11.30 15:42:23 3: CUL_HM set EG_wz_SD_LichtSofa on noArg
2021.11.30 15:42:23 3: CUL_HM set EG_wz_4K_Switch_2 on noArg
2021.11.30 15:42:23 3: CUL_HM set EG_wz_4K_Switch_4 off noArg
2021.11.30 15:42:23 3: CUL_HM set EG_wz_SD_LichtSofa off noArg
2021.11.30 15:42:23 3: CUL_HM set EG_wz_4K_Switch_2 off noArg
2021.11.30 15:42:23 3: CUL_HM set OG_el_SD_TV toggle noArg
2021.11.30 15:42:23 3: CUL_HM set OG_el_SD_Bett toggle noArg
2021.11.30 15:42:23 3: CUL_HM set EG_fl_SD_Licht toggle noArg
2021.11.30 15:42:23 3: CUL_HM EG_wz_4K_Switch_4 repeat, level C8 instead of 00
2021.11.30 15:42:23 3: CUL_HM EG_wz_SD_LichtSofa repeat, level C8 instead of 00
2021.11.30 15:42:24 3: CUL_HM EG_wz_4K_Switch_2 repeat, level C8 instead of 00

[Otto123]

Benutze doch den Eventmonitor! Du hast Mehrfachtaster? Jeder Tastendruck liefert wahrscheinlich dreimal short!?
Du fragst STATE im Device ab, das ist praktisch ein noGo. Da kann alles mögliche durchlaufen.

siehe auch diese Diskussion https://forum.fhem.de/index.php?topic=120179.0

Die Taster sind gepeert?

Für CUL_HM ist praktisch kein Trigger scharf genug. alles ist im Fluss

andere Zwischenschalter, die so rein gar nichts mit dem Schalter und den zu schaltenden Lampen zu tun haben ihren Status ändern.

Das ist leider vom Maintainer explizit so gewünscht. Alle Kanäle eines HM Elements bekommen fast alle Events der anderen Kanäle im gleichen Masterdevice.
https://forum.fhem.de/index.php/topic,120240.0.html

Gruß Otto

[maxritti]

Benutze doch den Eventmonitor! Du hast Mehrfachtaster? Jeder Tastendruck liefert wahrscheinlich dreimal short!?

Hier mal eine Sequenz vom einschalten:
Ich werde da nicht schlau raus, wobei für EG_EZ_Licht_1 in der Tat 3 x Short mit irgendwas dahinter kommt.

Code Auswählen Erweitern


2021.11.30 17:41:33 3 : CUL_HM set EG_wz_4K_Switch_4 on noArg
2021.11.30 17:41:33 3 : CUL_HM set EG_wz_SD_LichtSofa on noArg
2021.11.30 17:41:33 3 : CUL_HM set EG_wz_4K_Switch_2 on noArg
2021.11.30 17:41:33 3 : CUL_HM set EG_wz_4K_Switch_4 off noArg
2021.11.30 17:41:33 3 : CUL_HM set EG_wz_SD_LichtSofa off noArg
2021.11.30 17:41:33 3 : CUL_HM set EG_wz_4K_Switch_2 off noArg
2021-11-30 17:41:33 DOIF di_EG_wz_Licht cmd_event: EG_wz_Licht_1
2021-11-30 17:41:33 CUL_HM EG_wz_Licht_1 commState: CMDs_done
2021-11-30 17:41:33 CUL_HM EG_wz_Licht_1 Short 1_134 (to myVCCU)
2021-11-30 17:41:33 CUL_HM EG_wz_Licht_1 trigger: Short_134
2021-11-30 17:41:33 CUL_HM EG_wz_Licht_1 triggerTo_myVCCU: Short_134
2021-11-30 17:41:33 CUL_HM EG_wz_Licht_1 trigger_cnt: 134
2021-11-30 17:41:33 CUL_HM EG_wz_SD_Licht EG_wz_Licht_1 Short
2021.11.30 17:41:34 3 : CUL_HM set EG_wz_4K_Switch_4 on noArg
2021.11.30 17:41:34 3 : CUL_HM set EG_wz_SD_LichtSofa on noArg
2021.11.30 17:41:34 3 : CUL_HM set EG_wz_4K_Switch_2 on noArg
2021-11-30 17:41:34 DOIF di_EG_wz_Licht cmd_event: EG_wz_Licht_1
2021-11-30 17:41:34 CUL_HM EG_wz_Licht_1 triggerTo_myVCCU: Short_134_ack

Du fragst STATE im Device ab, das ist praktisch ein noGo. Da kann alles mögliche durchlaufen.

Was heisst STATE im Device abfragen? In welchem Device?
Ich meine ich habe einen Taster, der 2 Kanäle hat. Und dabei möchte ich die Kanäle abfragen und entsprechend Licht ein oder aus von mehreren Lampen.

siehe auch diese Diskussion https://forum.fhem.de/index.php?topic=120179.0

Die Taster sind gepeert?

Mit was soll ich die pairen?
Siehe oben. Möchte die 2 Kanäle auswerten und entsprechend Lampen schalten.

Für CUL_HM ist praktisch kein Trigger scharf genug. alles ist im Fluss
Das ist leider vom Maintainer explizit so gewünscht. Alle Kanäle eines HM Elements bekommen fast alle Events der anderen Kanäle im gleichen Masterdevice.
https://forum.fhem.de/index.php/topic,120240.0.html

Gruß Otto

Ich fürchte ich hätte doch besser den einen Rauchmelder mit MISSING ACKN behlten sollen, anstatt hier nun die Lichtorgel zu haben.
Aber wer suchet der findet....

[Beta-User]

*kopfschüttel*
Ich verstehe ja nichts von DOIF, würde aber der Einfachheit halber mal damit anfangen, nach "ist" zu fragen statt nach "enthält":
Aus

Code Auswählen Erweitern

[EG_wz_Licht_1] =~ /Short/
wird dann

Code Auswählen Erweitern

[EG_wz_Licht_1] eq "Short"
Und ob man Geräte schaltet, die sowieso schon on sind, wäre eine weitere Frage, aber da habe ich keine Ahnung, wie man das mit DOIF löst...

[maxritti]

*kopfschüttel*
Ich verstehe ja nichts von DOIF, würde aber der Einfachheit halber mal damit anfangen, nach "ist" zu fragen statt nach "enthält":
Aus

Code Auswählen Erweitern

[EG_wz_Licht_1] =~ /Short/
wird dann

Code Auswählen Erweitern

[EG_wz_Licht_1] eq "Short"
Und ob man Geräte schaltet, die sowieso schon on sind, wäre eine weitere Frage, aber da habe ich keine Ahnung, wie man das mit DOIF löst...

So einfach hate ich auch mal angefangen, mit dem eq.
Das Dumme ist halt, dass dann gar nichts passiert.
Die Lampen gehen werde an noch gehen die aus.

Von daher hatte ich gesucht und Posts gefunden, wo das mit  =~ /Short/ angegeben war.
Hatte ja auch einige Zeit funktioniert.

[Beta-User]

Wie gesagt, von DOIF verstehe ich nichts, aber der Tasterkanal scheint ein Reading im Hauptdevice zu sein (man kann das auch anders abfragen).
Das müßte dann in diese Richtung gehen

Code Auswählen Erweitern

[EG_wz_SD_Licht:EG_wz_Licht_1] eq "Short"

[Otto123]

Ich werde da nicht schlau raus, wobei für EG_EZ_Licht_1 in der Tat 3 x Short mit irgendwas dahinter kommt.
...
Was heisst STATE im Device abfragen? In welchem Device?

1. ist eben so ich kann nichts dafür

2. [DEVICE] heisst STATE abfragen [DEVICE:READING] heisst Reading im Device abfragen: FHEM Anfängerdoku oder so

Hast Du meine Links gelesen? Da steht doch umfangreich eine Erklärung drin? Vor allem warum man bei HM Geräten explizit keinen STATE abfragen sollte.


Ich sprach von peeren - Du übersetzt das falsch mit pairen. Steht auch in der Anfängerdoku und im Wiki explizit erklärt.
Und nochwas:

Allerdings hat sich seit dem ein neues Kuriosum eingeschlichen.

Der Code hat mit ziemlicher Sicherheit so noch nie funktioniert! Warum steht auch in meinem Link

[maxritti]

Moin zusammen,

das Problem ist und gelöst. Ich habe das DOIF weggeschmissen und ein notify neu erstellt.
Dies sieht nun wie folgt aus:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        EG_wz_Licht_1:Short.._[1-9][0-9]?[0-9]?.\(to.myVCCU\)|EG_wz_Licht_2:Short.._[1-9][0-9]?[0-9]?.\(to.myVCCU\) set EG_wz_4K_Switch_2 toggle; set EG_wz_4K_Switch_4 toggle; set  EG_wz_SD_LichtSofa toggle
   FUUID      61a711b5-f33f-7b3d-7c9e-f2b43d65ab875ba7
   NAME       no_wz_Licht
   NOTIFYDEV  EG_wz_Licht_2,EG_wz_Licht_1
   NR         5330
   NTFY_ORDER 50-EG_wz_Licht_2_notify_1
   REGEXP     EG_wz_Licht_1:Short.._[1-9][0-9]?[0-9]?.\(to.myVCCU\)|EG_wz_Licht_2:Short.._[1-9][0-9]?[0-9]?.\(to.myVCCU\)
   STATE      2021-12-01 08:36:27
   TRIGGERTIME 1638344187.98214
   TYPE       notify
   READINGS:
     2021-12-01 08:36:20   state           active
     2021-12-01 08:36:27   triggeredByDev  EG_wz_Licht_2
     2021-12-01 08:36:27   triggeredByEvent Short 1_169 (to myVCCU)
Attributes:

Damit geht das Licht nun wieder einwandfrei einmal an und einmal aus und keine Discolichter mehr. 

Es lag wie ihr gesagt ab wohl in der Tat an der unscharfen Bedingung des DOIF.

Bin nur mal gespannt, ob andere Zwischenstecker sich noch wie von Geisterhand schalten.
Da bin ich noch nicht weiter.

Noch mal vielen Dank an Eure Hilfe und Geduld.

[Otto123]

Hi,

diesen Trigger finde ich jetzt ev. wieder "zu genau" ich mache das einfach mit FB12_Btn_05:Short.*
Damit wird auf den state Event im Channel getriggert.
Es kommt nämlich auch mal vor, das im Event nicht (to myVCCU) steht, frag mich nicht warum.

Gruß Otto

[maxritti]

Na dir kann man es abe4 auch nicht Recht machen. 

Aber Du hast recht. Kommt mir auch ein wenig heftig vor der Ausdruck.
Vielleicht ändere ich den noch mal.

[Pfriemler]

Es kommt nämlich auch mal vor, das im Event nicht (to myVCCU) steht, frag mich nicht warum.

Immer dann, wenn der Sensor ein Event an einen Peer addressiert. Etliche meiner Fensterkontakte erzeugen zwei Events - an die Zentrale FHEM und an eine Mini-Alarm-Sirene.

[Otto123]

... und zeitweise "to broadcast" - ich bin nicht sicher ob das ein vorübergehendes "Feature" von CUL_HM war.

[frank]

... und zeitweise "to broadcast" - ich bin nicht sicher ob das ein vorübergehendes "Feature" von CUL_HM war.

sollte auch aktuell vorhanden sein. je nachdem, wie die raw message adressiert wird.
bei nicht gepairten devices müsste auf alle fälle "to broadcast" kommen.

[Pfriemler]

... und zeitweise "to broadcast" - ich bin nicht sicher ob das ein vorübergehendes "Feature" von CUL_HM war.

Das hat mit CUL_HM nichts zu tun, das machen die Geräte selbst, wie frank auch schrieb. Neben den "broadcasts" ungepairter Geräte gehen bei mir auch diverse Mitteilungen von Powersensoren (INFO) und Wettersensoren (WEATHER) (inkl. Temperaturmeldungen von Heizkörperthermosaten, ebenfalls INFO) "broadcast", wie das auch der von FHEM völlig unabhängige AskSinAnalyzer meldet (Zieladresse 000000). Übrigens das beste Homematic-Spielzeug ever - für mich, hat sich schon mehrfach bezahlt gemacht.

[martinp876]

Buttons senden trigger an peer-devices ( nicht channels) . Wenn kein peer dann broadcast.
Auch zur ccu wenn gepairt und kein peer vorhanden.
Es gibt unterschiede zwischen den devices was passiert wenn nicht gepeert.
Das beim gleichen kanal einmal zu broadcast und dann nicht gesendet wird ist eher unwahrscheinlich.

Ich würde nie ein notify auf das state reading setzen. Das reading "trigger" ist sicherer.
EG_wz_Licht_.:trigger:.Short.*
Sollte reichen

[martinp876]

hier einlmal meine lange erklärung wie ich solche notifys mache und machen würde. ok, notify ist an einigen stellen etwas schwach aufgestellt und hat für mich eine fragwürdige syntax. Aber man bekommt was man will. Will man was cooles wird es eng und schlecht kontrollierbar- aber machbar.

Erst die erklärungen, das Ergebnis dann unten.
Notify filtert trigger welche dargeboten werden als
<name>:<reading>: <value>
schwierig ist erst einmal das blank for den value - was man zwingend mit einem '.' ausfüllen muss.
Reading und Name kann man durch regex ermitteln, name leider nicht (sehr schwach...).
Weiter wurde aus irgendlechen historischen Gründen das Reading "state" weggelassen was das filtern hier (unnötig) verkompliziert. man kann das über das attribut "addStateEvent" addieren. Dennoch kann state auch informationen wir "dead" enthalten.
=> ich würde IMMER ein anderes Reading als state nutzen. CUL_HM hatte das Ziel trigger ohne state gestaltenzu können. Wichtig ist, und so ist das Design in CUL_HM, IMMER mit event-on-change-reading .* auszukommen. Das vermeidet duplikate. Ich mache bei jeden reboot ein

Code Auswählen Erweitern

attr TYPE=CUL_HM event-on-change-reading .*
um auf Buttons in CUL_HM zu triggern empfiehlt sich das Reading "trigger".

Code Auswählen Erweitern

trigger.* # short und long
trigger:.S.* # short only
trigger:.L.* # long only

nun hast du 2 Buttons mit der identischen Funktion. Mir war das zu dünn weshalb mein Ziel war, eine statische Defintion zu erdenken, welche meine Buttons mit kommandos versieht. Also ein notify für eine (oder auch mehrere) devices mit beliebig vielen Buttons. Jeder Button mit eigenenm Kommando. Schön übersichtlich.
Ein Button in CUL_HM uterstützt erst einmal Short und Long -was ich getrennt auswerten will.

Also brauche ich ein Attribut für jeden unterschiedlichen Trigger. Diese muss ich die userAttribute zulassen um sie anschliessend zu nutzen.
in deinem Fall

Code Auswählen Erweitern

attr no_wz_Licht userattr EG_wz_Licht_1Long EG_wz_Licht_1Short EG_wz_Licht_2Long EG_wz_Licht_2Short

Die Liste kann beliebig verlängert werden - auch über mehrere Devices hinweg.

nun noch die Kommandos hinterlegen:

Code Auswählen Erweitern


attr EG_wz_Licht_1Long  set EG_wz_4K_Switch_2 toggle
attr EG_wz_Licht_1Short set EG_wz_4K_Switch_4,EG_wz_SD_LichtSofa toggle
attr EG_wz_Licht_2Long  set EG_wz_4K_Switch_4;set EG_wz_SD_LichtSofa toggle
attr EG_wz_Licht_2Short set EG_wz_SD_LichtSofa off



Jetzt muss das notify noch überredet werden, die kommandos auszuführen. Das Komamndo im notify wäre dann - immer (also einfach eintragen)

Code Auswählen Erweitern

{$EVENT=~ m/.*(Short|Long).*/; fhem AttrVal($SELF,$NAME.$1,"attrUndef")}

Zusammenfassend ist das dann in deinem Fall

Code Auswählen Erweitern

define no_wz_Licht notify EG_wz_Licht_\d+:trigger.* {$EVENT=~ m/.*(Short|Long).*/; fhem AttrVal($SELF,$NAME.$1,"attrUndef")}

attr no_wz_Licht userattr EG_wz_Licht_1Long EG_wz_Licht_1Short EG_wz_Licht_2Long EG_wz_Licht_2Short
attr EG_wz_Licht_1Long  set EG_wz_4K_Switch_2 toggle
attr EG_wz_Licht_1Short set EG_wz_4K_Switch_4,EG_wz_SD_LichtSofa toggle
attr EG_wz_Licht_2Long  set EG_wz_4K_Switch_4;set EG_wz_SD_LichtSofa toggle
attr EG_wz_Licht_2Short set EG_wz_SD_LichtSofa off


da nun aber notiy ... schwach ... ist müssen trigger-filter-namen explizit, ohne regex, eingegeben werden. Technisch nicht, aber besser für die Performance. Wirklich schade. damit wird es ein klein wenig länger

Code Auswählen Erweitern

define no_wz_Licht notify EG_wz_Licht_1:trigger.*|EG_wz_Licht_2:.trigger.* {$EVENT=~ m/.*(Short|Long).*/; fhem AttrVal($SELF,$NAME.$1,"attrUndef")}

attr no_wz_Licht userattr EG_wz_Licht_1Long EG_wz_Licht_1Short EG_wz_Licht_2Long EG_wz_Licht_2Short
attr EG_wz_Licht_1Long  set EG_wz_4K_Switch_2 toggle
attr EG_wz_Licht_1Short set EG_wz_4K_Switch_4,EG_wz_SD_LichtSofa toggle
attr EG_wz_Licht_2Long  set EG_wz_4K_Switch_4;set EG_wz_SD_LichtSofa toggle
attr EG_wz_Licht_2Short set EG_wz_SD_LichtSofa off


Die Kommandos musst du nun über das Attribut einpflegen - sollte machbar sein.
Mit etwas mehr komfort(ich erstelle mir noch Readings zum besseren Lesen) und für eine 12 kanal FB sieht es bei mir so aus

Code Auswählen Erweitern

define ntfy_FB12 notify FB_..:trigger:.* {$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