HM Geräte schalten doppelt/willkürlich

Begonnen von maxritti, 30 November 2021, 09:01:51

Vorheriges Thema - Nächstes Thema

maxritti

Na dir kann man es abe4 auch nicht Recht machen.  ;D ;)

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


Pfriemler

#16
Zitat von: Otto123 am 01 Dezember 2021, 09:06:07
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Otto123

... und zeitweise "to broadcast" - ich bin nicht sicher ob das ein vorübergehendes "Feature" von CUL_HM war.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

Zitat von: Otto123 am 02 Dezember 2021, 11:38:55
... 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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Zitat von: Otto123 am 02 Dezember 2021, 11:38:55
... 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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

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
attr TYPE=CUL_HM event-on-change-reading .*
um auf Buttons in CUL_HM zu triggern empfiehlt sich das Reading "trigger".
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
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:

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)

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

Zusammenfassend ist das dann in deinem Fall

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

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

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