DOIF im Status "disabled" reagiert trotzdem

TubeHead · 10 Juni 2025, 23:03:00

Hallo Forengemeinde,

bin gerade auf ein Problem gestoßen, welches ich nicht gelöst bekomme und bitte um Hilfe.

Das folgende DOIF nimmt Events von Bewegungsmeldern entgegen, wenn "112_p1:a" == 0 und die Außenhelligkeit (LUM) den eingestellten Wert unterschritten hat; also jetzt am Abend.

Code Auswählen

defmod set_112_a1 DOIF ([112_p1:a] < 0) (set HM4SW1_1 off) DOELSEIF ([112_p1:a] > 0) (set HM4SW1_1 on) \
	DOELSEIF ([112_p1:a] == 0 and ([HM2BB2] eq "motion" or [HM2BB3] eq "motion") and [LUM:state] < [112_p1:b]) (setstate HM2BB2 noMotion, setstate HM2BB3 noMotion, set HM4SW1_1 on-for-timer [112_p1:c]) \
	DOELSEIF ([112_p1:a] == 0 and [LUM:state] > [112_p1:b]) (set HM4SW1_1 off)
attr set_112_a1 do always

setstate set_112_a1 disabled
setstate set_112_a1 2025-06-10 22:10:18 Device HM2BB2
setstate set_112_a1 2025-06-10 22:06:00 cmd 4
setstate set_112_a1 2025-06-10 22:06:00 cmd_event LUM
setstate set_112_a1 2025-06-10 22:06:00 cmd_nr 4
setstate set_112_a1 2025-06-10 08:43:47 e_112_p1_a 0
setstate set_112_a1 2025-06-10 22:10:18 e_HM2BB2_STATE noMotion
setstate set_112_a1 2025-06-10 22:07:38 e_HM2BB3_STATE noMotion
setstate set_112_a1 2025-06-10 22:09:00 e_LUM_state 40
setstate set_112_a1 2025-06-10 22:11:23 last_cmd cmd_4
setstate set_112_a1 2025-06-10 22:11:23 mode disabled
setstate set_112_a1 2025-06-10 22:11:23 state disabled

Wie man sieht, ist das DOIF deaktiviert (wird von anderer Stelle per Taster mit "set set_112_a1 disable" gesetzt). Dennoch wird beim Auslösen einer Bewegung das DOIF ausgeführt und die Beleuchtung eingeschaltet.

Was übersehe ich hier?

passibe · 11 Juni 2025, 00:26:46

Sicher, dass das Einschalten der Beleuchtung vom DOIF kommt? Die Zeitstempel von setstate zeigen eigentlich, dass nach disable (22:11:23 Uhr) nichts mehr passiert.

Vielleicht kannst du mal das DOIF deaktivieren, den Event Monitor starten und dann zum Bewegungsmelder laufen. Dann (natürlich nur, wenn auch das Licht an geht) im Event Monitor schauen, was genau da passiert bzw. das gerne auch hier posten. Vielleicht auch noch ein list vom DOIF posten.

Eventuell gibt es auch noch eine schlauere Möglichkeit nachzuverfolgen, woher der Einschaltbefehl kommt. Aber das mit dem Event Monitor hätte ich jetzt mal als erstes probiert.

TubeHead · 11 Juni 2025, 09:11:32

Danke für den Hinweis. Das werde ich heute Abend mal explizit durchtesten.

Zitat von: passibe am 11 Juni 2025, 00:26:46Sicher, dass das Einschalten der Beleuchtung vom DOIF kommt?

Da bin ich mir ziemlich sicher. Es gibt nur noch eine andere Stelle im "Code", in welcher auf die Aktoren Bezug genommen wird. Und das ist gleich danach die manuelle Ansteuerung der Aktoren via Taster.
Ich habe zur Sicherheit die fhem.cfg auch mal manuell nach Hinweisen auf die Aktoren (HM4SW1*) durchsucht. Hätte ja sein können, dass ich mal irgendwann was gemacht und vergessen habe. Aber nichts. Dabei sind auch nur die beiden genannten Stelle zu finden.

Da heute auch Wetter ist, werde ich dazu mal einen der auslösenden PIR von der Gaube holen, damit ich nicht immer zum Testen herauslaufen muss. Ich melde mich dann, sobald ich neue Fakten gesammelt habe.

MadMax-FHEM · 11 Juni 2025, 09:48:13

HM... <- Homematic?
Irgendwelche "Direktverbindungen" (Peering)?
Oder (wenn HM-IP) über eine CCU was angelegt?

Gruß, Joachim

TubeHead · 11 Juni 2025, 10:09:44

Moin Joachim,

HM = HomeMatic, das ist in diesem Fall mit Bezug auf die betroffenen Geräte korrekt.

Ansonsten nein und nein. Die Sensoren (PIR = HM-SEN-MDIR-O, Tasten = HM-PB-6-WM55) und Aktoren (4fach Hutschiene = HM-LC-SW4-DR) laufen in diesem Fall alle über FHEM und besitzen kein direktes Peering. Die würden sich funktechnisch auch nicht "sehen" aufgrund der örtlichen Gegebenheiten und dem Stahlschrank, in dem die Aktoren untergebracht sind.

TubeHead · 11 Juni 2025, 23:47:29

Ok, ich habe jetzt gut eine Stunde herumgewurschtelt und versucht, das Phänomen nachzustellen.
Ob es sich noch genau so verhält wie angesagt, hatte ich zuerst ausprobiert. Dem war auch so. Also Deaktivierung -> Bewegung -> Licht an.
Dann habe ich nach Ablauf des Timers erneut eine Bewegung ausgelöst (die PIR blinken ganz kurz auf), aber beim zweiten mal wurde das Licht NICHT wieder eingeschaltet, also das erwartete Verhalten.

Nun wollte ich genau dieses Verhalten, das nämlich nach dem Deaktivieren genau einmal das Licht noch geschaltet wird, über den Eventmonitor erfassen, einmal für das DOIF selber, einmal für den Aktor.

Ich weiß jetzt nicht, was hier abgeht, aber ich bekomme es kontrolliert nicht wieder in den fehlerhaften Zustand

$:-\$ Nachdem man einmal das Ganze deaktiviert hat und einmal die Beleuchtung fälschlich eingeschaltet war, verhält es sich anschließend wie erwartet... Kapier ich nicht

Ich lasse das für heute. Morgen werde ich ohne vorherigen Test mal versuchen, vor einer meiner ersten Aktionen die Events aufzuzeichnen. Ich habe da so eine Ahnung, dass dieser Fehler nur auftritt, wenn das System durch die Außenhelligkeit den Tag über nicht schaltet, und dann das System deaktiviert wird.

Ich melde mich morgen dazu wieder...

Per · 12 Juni 2025, 08:19:49

Du kannst das DOIF auch "richtig" disablen, dann siehst du auch im Eventlog, was abgeht.

TubeHead · 12 Juni 2025, 08:24:22

Zitat von: Per am 12 Juni 2025, 08:19:49Du kannst das DOIF auch "richtig" disablen,

Du meinst jetzt über die GUI? Der Effekt ist doch identisch. Ob ich nun per GUI per Mausklick ein "set blablub disable" oder per DOIF sende, ist doch identisch, auch was die Reaktionen betrifft; oder nicht?
Oder meinst Du was ganz anderes?

tomcat.x · 12 Juni 2025, 10:31:48

Vielleicht ist das Attribut "disable" gemeint. Ich sehe, dass ich das in manchen meiner DOIFs drin habe. Zwar gerade auf 0 gesetzt, aber dass es vorhanden ist bedeutet, dass ich das schon mal auf 1 gesetzt hatte. Hatte vermutlich einen Grund. Aber ich könnte auch nicht sagen, dass das war, weil mit set ... diable noch was aktiv war.

TubeHead · 12 Juni 2025, 10:43:20

Ok, von dem Attribut habe ich bis dato noch nichts gehört. Muss ich mich mal schlaulesen...

EDIT:
Habe was Interessantes dazu unter https://forum.fhem.de/index.php?topic=117088.0 gefunden. Habe ich noch nicht so ganz verstanden, aber immerhin mal was drüber gelesen

Nun stellt sich mir halt die Frage, was in meinem Fall besser geeignet ist, um per Tastendruck die Ausführung des DOIF zu verhindern. Wenn ich das richtig verstanden habe, sorgt ein "set blablub disable" zwar dafür, dass das DOIF keine Befehle mehr ausführt, wohl aber "intern" noch aktiv ist und die ggf. gesetzten Timer weiterlaufen.
Dem Gegenüber führt das gesetzte Attribut "disable" dazu, dass das DOIF selbst quasi aus dem Framework herausgenommen/unsichtbar ist und auch alle Timer nichts mehr machen...

Habe ich das richtig verstanden?

tomcat.x · 12 Juni 2025, 11:47:51

Wie genau das Verhalten des DOIF in beiden Fällen ist, kann ich Dir nicht sagen. Von der Nutzung gibt es noch einen Unterschied, das Attribut überlebt einen Neustart nur nach einem save. Daher nutze ich das höchstens für Sachen wie Sommer-/Winterumstellung, nicht für ständige Änderungen. Aber für Deinen Test könnte es vielleicht eine Hilfe sein, um zu sehen, ob das etwas am Verhalten ändert.

passibe · 12 Juni 2025, 11:59:31

Also ich habe auch DOIFs, die ich über einen Taster temporär ein-/ausschalte und nutze dafür ausschließlich set <NAEME> disable bzw. set <NAME> initialize (teilweise auch gefolgt von checkall).
Hatte damit noch nie Probleme.

Es wäre mir auch neu, dass sich, jedenfalls für diesen Anwendungsbereich, der Effekt von disable (set statt attr) unterscheidet.

Per · 12 Juni 2025, 15:49:56

Den Unterschied sieht man im Eventlog, wenn weiterhin das Cmd ausgeführt wird, muss es woanders her kommen.

TubeHead · 12 Juni 2025, 16:03:33

Hmmm... Wenn es woanders herkommt, dann müsste es aber nach disable dauernd (weiterhin) funktionieren / das Licht einschalten. Tut es aber nicht, sondern (vermeintlich) nur genau einmal, nach dem das DOIF mit disable deaktiviert wurde.

Aber ich teste das heute Abend noch mal explizit aus und schaue mir die Logs an...

TubeHead · 12 Juni 2025, 22:52:20

So... Ich habe es jetzt noch mal ohne vorherige Auslösung versucht. Und dann kommt der Fehler genau einmal zum Tragen.
Also den ganzen Tag nicht angefasst und gewartet, bis die Schaltschwelle der Helligkeit unterschritten wurde.
Dann jeweils einen gefilterten Eventmonitor für den PIR, das DOIF und den Aktor erzeugt, aus denen ich dann folgendes Verhalten herauskopiert habe (in drei Blöcken der Übersicht halber).
Obwohl das DOIF nicht mehr reagiert, wird dennoch genau einmal der Aktor geschaltet. Woher das kommt, ist mir ein großes Rätsel. Ich habe sicherheitshalber noch einmal die ganze fhem.cfg mit np++ durchsucht, aber erneut keinen weiteren Abschnitt finden können, in dem der genannte Aktor vorkommt, von dem Abschnitt mit der direkten Steuerung Taste -> Aktor mal abgesehen. Der existiert ohne jeden Zweifel nur in dem genannten DOIF.
Wenn also dieses DOIF deaktiviert ist und auch im Eventmonitor nicht zuckt, was zur Hölle schaltet dann den Aktor genau einmal nach Deaktivierung???
Noch was: Im zweiten Abschnitt "### Bewegung ausgelöst, Licht wird eingeschaltet trotz Deaktivierung" ist im Aktor "set_on-for-timer 200" zu lesen. Das ist exakt der Wert, der in dem deaktivierten DOIF gesetzt ist.

Code Auswählen

### Taste zur Deaktivierung betätigt (blink)

## Events HM2BB.*
(none)

## Events set_112_a1.*
2025-06-12 22:24:23.252 DOIF set_112_a1 last_cmd: cmd_4
2025-06-12 22:24:23.252 DOIF set_112_a1 disabled
2025-06-12 22:24:23.252 DOIF set_112_a1 mode: disabled

## Events HM4SW1_1.*
2025-06-12 22:24:23.255 CUL_HM HM4SW1_1 commState: CMDs_pending
2025-06-12 22:24:23.257 CUL_HM HM4SW1_1 set_on-for-timer 0.1
2025-06-12 22:24:23.258 CUL_HM HM4SW1_1 commState: CMDs_processing...
2025-06-12 22:24:23.260 CUL_HM HM4SW1_1 trigLast: fhem:02
2025-06-12 22:24:23.348 CUL_HM HM4SW1_1 trigLast: fhem:02
2025-06-12 22:24:23.424 CUL_HM HM4SW1_1 commState: CMDs_done
2025-06-12 22:24:23.424 CUL_HM HM4SW1_1 deviceMsg: on (to VCCU)
2025-06-12 22:24:23.424 CUL_HM HM4SW1_1 level: 100
2025-06-12 22:24:23.424 CUL_HM HM4SW1_1 pct: 100
2025-06-12 22:24:23.424 CUL_HM HM4SW1_1 on
2025-06-12 22:24:23.424 CUL_HM HM4SW1_1 timedOn: running
2025-06-12 22:24:25.993 CUL_HM HM4SW1_1 commState: CMDs_done
2025-06-12 22:24:25.993 CUL_HM HM4SW1_1 deviceMsg: off (to VCCU)
2025-06-12 22:24:25.993 CUL_HM HM4SW1_1 level: 0
2025-06-12 22:24:25.993 CUL_HM HM4SW1_1 pct: 0
2025-06-12 22:24:25.993 CUL_HM HM4SW1_1 off
2025-06-12 22:24:25.993 CUL_HM HM4SW1_1 timedOn: off

Code Auswählen

### Bewegung ausgelöst, Licht wird eingeschaltet trotz Deaktivierung

## Events HM2BB.*
2025-06-12 22:27:32.852 DOIF set_395l_au_a cmd_event: HM2BB2
2025-06-12 22:27:32.852 CUL_HM HM2BB2 brightness: 71
2025-06-12 22:27:32.852 CUL_HM HM2BB2 motion: on (to VCCU)
2025-06-12 22:27:32.852 CUL_HM HM2BB2 motionCount: 135_next:15s
2025-06-12 22:27:32.852 CUL_HM HM2BB2 motion
2025-06-12 22:27:32.852 CUL_HM HM2BB2 trigger_cnt: 135
2025-06-12 22:27:32.852 CUL_HM HM2BB2 noMotion
2025-06-12 22:27:48.929 CUL_HM HM2BB2 brightness: 89
2025-06-12 22:27:48.929 CUL_HM HM2BB2 motion: on (to VCCU)
2025-06-12 22:27:48.929 CUL_HM HM2BB2 motionCount: 136_next:15s
2025-06-12 22:27:48.929 CUL_HM HM2BB2 motion
2025-06-12 22:27:48.929 CUL_HM HM2BB2 trigger_cnt: 136
2025-06-12 22:28:05.838 CUL_HM HM2BB2 motion: off
2025-06-12 22:28:05.838 CUL_HM HM2BB2 motionDuration: 33
2025-06-12 22:28:05.838 CUL_HM HM2BB2 noMotion

## Events set_112_a1.*
(none)

## Events HM4SW1_1.*
2025-06-12 22:27:32.835 CUL_HM HM4SW1_1 commState: CMDs_pending
2025-06-12 22:27:32.842 CUL_HM HM4SW1_1 set_on-for-timer 200
2025-06-12 22:27:32.846 CUL_HM HM4SW1_1 commState: CMDs_processing...
2025-06-12 22:27:32.850 CUL_HM HM4SW1_1 trigLast: fhem:02
2025-06-12 22:27:32.897 CUL_HM HM4SW1_1 trigLast: fhem:02
2025-06-12 22:27:33.022 CUL_HM HM4SW1_1 commState: CMDs_done
2025-06-12 22:27:33.022 CUL_HM HM4SW1_1 deviceMsg: on (to VCCU)
2025-06-12 22:27:33.022 CUL_HM HM4SW1_1 level: 100
2025-06-12 22:27:33.022 CUL_HM HM4SW1_1 pct: 100
2025-06-12 22:27:33.022 CUL_HM HM4SW1_1 on
2025-06-12 22:27:33.022 CUL_HM HM4SW1_1 timedOn: running
2025-06-12 22:30:55.677 CUL_HM HM4SW1_1 commState: CMDs_done
2025-06-12 22:30:55.677 CUL_HM HM4SW1_1 deviceMsg: off (to VCCU)
2025-06-12 22:30:55.677 CUL_HM HM4SW1_1 level: 0
2025-06-12 22:30:55.677 CUL_HM HM4SW1_1 pct: 0
2025-06-12 22:30:55.677 CUL_HM HM4SW1_1 off
2025-06-12 22:30:55.677 CUL_HM HM4SW1_1 timedOn: off

Code Auswählen

### nach 10 Minuten erneut Bewegung ausgelöst, Licht bleibt aus

## Events HM2BB.*
2025-06-12 22:41:38.528 CUL_HM HM2BB2 motion: on (to VCCU)
2025-06-12 22:41:38.528 CUL_HM HM2BB2 motionCount: 137_next:15s
2025-06-12 22:41:38.528 CUL_HM HM2BB2 motion
2025-06-12 22:41:38.528 CUL_HM HM2BB2 trigger_cnt: 137
2025-06-12 22:41:55.437 CUL_HM HM2BB2 motion: off
2025-06-12 22:41:55.437 CUL_HM HM2BB2 motionDuration: 17
2025-06-12 22:41:55.437 CUL_HM HM2BB2 noMotion

## Events set_112_a1.*
(none)

## Events HM4SW1_1.*
(none)