HM Geräte schalten doppelt/willkürlich

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

Vorheriges Thema - Nächstes Thema

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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...
Zitat von: Beta-User am 03 November 2021, 10:55:55
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!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

Zitat von: maxritti am 30 November 2021, 11:13:27
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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:

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

#7
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. :) :D ;D alles ist im Fluss :'(

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

maxritti

Zitat von: Otto123 am 30 November 2021, 17:03:26
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.


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


Zitat von: Otto123 am 30 November 2021, 17:03:26
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.

Zitat von: Otto123 am 30 November 2021, 17:03:26
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.

Zitat von: Otto123 am 30 November 2021, 17:03:26

Für CUL_HM ist praktisch kein Trigger scharf genug. :) :D ;D 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
[EG_wz_Licht_1] =~ /Short/
wird dann[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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

maxritti

Zitat von: Beta-User am 30 November 2021, 17:48:17
*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
[EG_wz_Licht_1] =~ /Short/
wird dann[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
[EG_wz_SD_Licht:EG_wz_Licht_1] eq "Short"
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

#12
Zitat von: maxritti am 30 November 2021, 17:44:03
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:
ZitatAllerdings hat sich seit dem ein neues Kuriosum eingeschlichen.
Der Code hat mit ziemlicher Sicherheit so noch nie funktioniert! Warum steht auch in meinem Link
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

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:

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