Wunsch: DOIF und generelle TOT-Zeit

Begonnen von daedalus0815, 28 Januar 2022, 10:40:40

Vorheriges Thema - Nächstes Thema

daedalus0815

Hallo Damian,

echt nur so als Idee....

--------------------------------

ich habe einen HUE-Switch, der folgendes absetzt:

2022-01-28 08:25:25 HUEDevice HUESwitch2 1000
2022-01-28 08:25:26 HUEDevice HUESwitch2 1002

oder mal
2022-01-28 08:25:25 HUEDevice HUESwitch2 1000
2022-01-28 08:25:26 HUEDevice HUESwitch2 1003

oder mal
2022-01-28 08:25:25 HUEDevice HUESwitch2 1000
2022-01-28 08:25:26 HUEDevice HUESwitch2 1004

Entscheidend ist dabei immer der letzte Wert.


Bisher ließ sich das mit [HUESwitch2:"^100"] wunderbar maskieren, funktioniert nur jetzt nimmer:
((Sorry...Keine Ahnung, ob das hier gegen die guten Sitten verstößt...ein Link zu meinem Anfangsproblem:))
https://forum.fhem.de/index.php/topic,125768.msg1203950.html#msg1203950

Jetzt muss man mit [HUESwitch2:"^1002"] bzw. [HUESwitch2:"^1003"] etc. maskieren....geht auch.
Ich stelle immer wieder fest, dass mir eine einstellbare DOIF-Gesamt-TOTzeit von wenigen Sekunden manches Problem leicht vom Hals halten würde.

In o.e. komme ich mit einem cmdPause ja nicht weiter, da ein Statuswechsel stattfindet... vielleicht sehe ich aber nur die bessere Lösung nicht  :o




Damian

[HUESwitch2:"^100"] bedeutet einfach: Event beginnt mit 100, Rest ist egal. Da hat sich an dieser Syntax noch nie etwas im DOIF geändert. Wenn etwas vorher funktioniert hat und jetzt nicht, dann liegt es nicht an "^100".

Du kannst immer von außen ein DOIF auf enable/disable per set setzen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

daedalus0815

#2
Nachgedacht....man kann das aber auch so lösen:


die erste Bedingung fängt das  "HUESwitch2 1000" ab.....:

---------------------------------------------------------------------------------------


( [HUESwitch2:"000"]   ) 
()

DOELSEIF  ### alle 100[b]x[/b]
([HUESwitch2:"^100"]  and [?HUE_Tresen:&STATE] eq "on" )
( set HUE_Tresen off )


DOELSEIF 
( [HUESwitch2:"^100"]  and  [?HUE_Tresen:&STATE] eq "off" ) 
( set HUE_Tresen on   )

-----------------------------------------------

P.S: ..... ist klar, am DOIF hat sich ja wirklich nix geändert, nur am Timing und der Auswertung der HUE-Events (siehe Link).
Totzeit war ja auch nur eine Idee und kein "must have" oder Fehler......
Vielleicht nutzt dieser Eintrag aber auch einem anderen FHEMler ....

disable/enable via at für 2 Sekunden aus dem DOIF ist auch nicht schön.... toll wäre z.B. ein DOIF-Funktion "set $SELF death 2"
=> für 2 Sekunden DOIF - Sperrung der Eventverarbeitung, cmdPause bietet das ja bereits auf unterer Ebene

Viele Wege führ'n nach Rom

Beta-User

Interessehalber: Wieso löst du sowas nicht innerhalb der ZigBee-Funktionalität, also entweder über ein "binding" oder eine Gruppe?
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

daedalus0815

#4
Sorry @Beta-User,

....mußte lange darüber nachhdenken, was du meinst....hab's  jetzt...direktes binding.

Bei mir steht ja auch nicht " set HUE_Becken on"
sondern  "set HUE_Becken pct 68".... und das noch in verschieden Varianten für verschieden Uhrzeiten (Morgens/Abends) und
Abhängigkeiten zum Alarmstatus.


Liest man meinen o.e. Link, sieht man, dass sich scheinbar über
ein geändertes STATE-Update-Timing das Auswerte-Verhalten meines DOIFs geändert hat....was ja per se kein DOIF-Problem ist.

Solche schnelle Event-Sequenzen von Devices kommen bestimmt öfters vor, man will aber nur auf EINEN Event aus der Sequenz reagieren...
Ändert sich dabei noch der DOIF-Status kann man mit cmdPause leider nicht blocken.

Für mich habe ich ja nun eine praktible Lösung gefunden, die mir den Code noch übersichtlich hält.....

Vielleicht seht ihr ja auch das Potential einer anderen Lösung .... ;)





MadMax-FHEM

Zitat von: daedalus0815 am 28 Januar 2022, 11:17:24
Solche schnelle Event-Sequenzen von Devices kommen bestimmt öfters vor, man will aber nur auf EINEN Event aus der Sequenz reagieren...

Wenn man ur auf EINEN Event (aus einer Sequenz) reagieren will, dann muss eben die Trigger-RegEx auch genau diesen einen Event "fassen"...
...klingt für mich ein wenig nach: nach Homematic Update schalten meine Geräte "komisch" -> zu "lasche" RegEx war dabei das eigentliche Problem

;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Sany

Hallo daedalus0815,

du könntest mit ^100[2-4]$ diese 3 Events rausfiltern, ein 1000 wird nicht beachtet.
Aber: es wurde ja schon geschrieben, die Regex muß entsprechend gestaltet werden, um nur gewünschte Events zu filtern. So wie Du den switch beschreibst, kommen diese verschiedenen Events aber irgendwie "unbestimmt", oder verstehe ich Dich da falsch? Was ist das denn für ein Switch?
Ich habe z.B. einen einfachen Taster von Aqara, der schickt bei einem kurzen Tastendruck 1000, bei doppelt ein 1002, bei 3-fach ein 1005 und 4-fach ein 1010. Einlanger Druck sendet kurz 1000, dann direkt 1001. beim Loslassen kommt 1003. Damit kann man schon sehr gezielt auf verschiedene Tastenbedienungen reagieren. Will sagen: der Erfinder hat sich bestimmt etwas dabei gedacht, welche Codes geschickt werden.


Gruß


Sany
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

daedalus0815

#7
Hallo Sany,

Danke, ....toller Tipp ! 

Es kann ja alles soooo einfach sein, wenn man's gleich richtig macht !   

------------------------------------------------------------------------------------------------------

Ist ein Philips HUE Switch/Dimmer mit 4 Tasten...

Einmalig, normal kurzes Drücken des HUESwitch.....=> Event Monitor:

2022-02-01 14:40:32.604 DOIF Paul_di cmd_event: HUESwitch2
2022-02-01 14:42:13 HUEDevice HUESwitch2 1000
2022-02-01 14:42:13 HUEDevice HUESwitch2 eventduration: 0
2022-02-01 14:40:32.627 DOIF Paul_di cmd_event: HUESwitch2
2022-02-01 14:42:13 HUEDevice HUESwitch2 eventduration: 1
2022-02-01 14:42:13 HUEDevice HUESwitch2 1002


Schalten funktioniert mit...:  (....man sieht auch den cmd_1/cmd_2 - Wechsel beim Ausschalten )


( [HUESwitch2:"000"]   )  ### fängt die 1000er aus der o.e. Sequenz 1000/1002 raus
()

DOELSEIF
([HUESwitch2:"^100"]  and [?HUE_Tresen] eq "on" ) 
( set HUE_Tresen off )

DOELSEIF 
( [HUESwitch2:"^100"]  and  [?HUE_Tresen] eq "off" ) 
( set HUE_Tresen pct 48   )



....aber das schaltet NICHT:

([HUESwitch2:"^100"]  and [?HUE_Tresen] eq "on" ) 
( set HUE_Tresen off )

DOELSEIF 
( [HUESwitch2:"^100"]  and  [?HUE_Tresen] eq "off" ) 
( set HUE_Tresen pct 48   )

.... [HUESwitch2:"^1002"] auch nicht

identisch:
attr Paul_di DbLogExclude .*
attr Paul_di disable 0
attr Paul_di do always
attr Paul_di verbose 3


Welchen Baum übersehe ich hier....???   

P.S:.....Fhem-Update heute


UPDATE:
Hinweis von @justme1968:
https://forum.fhem.de/index.php/topic,125768.msg1204327.html#msg1204327

Das Thema geht wohl sehr viel tiefer    ::)

Für mich läuft's mit meinem o.e. FIX erstmal .....werde das Thema aber weiter interessiert verfolgen  8)