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.
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?
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.
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.
HM... <- Homematic?
Irgendwelche "Direktverbindungen" (Peering)?
Oder (wenn HM-IP) über eine CCU was angelegt?
Gruß, Joachim
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.
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 :o :-\ 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...
Du kannst das DOIF auch "richtig" disablen, dann siehst du auch im Eventlog, was abgeht.
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?
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.
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 ;D
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?
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.
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.
Den Unterschied sieht man im Eventlog, wenn weiterhin das Cmd ausgeführt wird, muss es woanders her kommen.
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...
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.
### 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
### 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
### 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)
Was macht das DOIF set_395l_au_a?
Öhhh... Musste ich jetzt auch erstmal herausfinden. Wo hast Du denn das gesehen? Ist mir vollkommen entgangen :'(
Erstaunlicherweise taucht dort auch der besagte Aktor auf, wird aber, aus welchen Gründen auch immer, nicht von np++ gefunden.
Das scheint ein Überbleibsel aus den Anfängen meiner Fummelei zu sein.
Ich deaktiviere das mal und ergründe im Laufe des Abends mal, was das machen soll...
Zitat von: TubeHead am 12 Juni 2025, 22:52:20### 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
set_359l_au_a ist hier.
Deshalb besser den event monitor ohne Filter laufen lassen ... vor allem wenn man etwas Unbekanntes sucht:D
Aber ich vermute mal stark, dass dann set_359l_au_a tatsächlich der Übeltäter ist.
Jo... Da muss ich wohl mal ganz kleinlaut Abbitte leisten :-[ Vielen Dank und Dank an Deine Adleraugen!
Den "set_359l_au_a" konnte ich in der fhem.cfg per np++ deshalb nicht finden, da er wohl uralt und per include eingebunden war; muss schon mindestens 8 Jahre her sein.
Interessant dabei, dass die ganze Sache dennoch seit Jahren funktioniert hat, obwohl das eigentlich ein annähernder Zwilling des "set_112_a1" ist. Verblüffend!
Was mich aber dennoch irritiert ist der Umstand, dass hier nach dem Deaktivieren des "aktuellen" DOIF die Altlast nach einem Mal schalten anscheinend ebenfalls den Betrieb einstellt. Erwartet hätte ich, dass das Deaktivieren eines der "Zwillinge" schlicht keine Auswirkungen gezeigt hätte, da redundant und somit der verbleibende "Zwilling" die Funktionalität ungestört bereitstellt. Dem ist aber ganz offensichtlich nicht so...
Dann poste doch mal ein List.
... von den Zwillingen?
Von set_359l_au_a
Ok, bitteschön. Habe ich dafür temporär wieder aktiviert, deaktiviere ich aber gleich wieder...
Internals:
CFGFN /opt/fhem/_INC/395_Hausflur.cfg
DEF ([395l_au:a] < 0) (set HM4SW1_1 off) DOELSEIF ([395l_au:a] > 0) (set HM4SW1_1 on)
DOELSEIF ([395l_au:a] == 0 and [HM2BB2] eq "motion" and [LUM:state] < [395l_sl:a] ) (setreading HM2BB2 state noMotion, set HM4SW1_1 on-for-timer 200)
DOELSEIF ([395l_au:a] == 0 and [LUM:state] > [395l_sl:a] ) (set HM4SW1_1 off)
FUUID 5c7d4ffb-f33f-a7b8-2ddf-80cb00c620560bfb
MODEL FHEM
NAME set_395l_au_a
NOTIFYDEV 395l_sl,global,395l_au,LUM,HM2BB2
NR 2250
NTFY_ORDER 50-set_395l_au_a
STATE cmd_4
TYPE DOIF
VERSION 29460 2024-12-29 20:25:48
eventCount 3
READINGS:
2025-06-13 08:21:02 Device HM2BB2
2025-06-13 04:30:00 cmd 4
2025-06-13 04:30:00 cmd_event LUM
2025-06-13 04:30:00 cmd_nr 4
2023-06-06 10:38:49 e_395l_au_a 0
2024-11-19 16:59:25 e_395l_sl_a 36
2025-06-13 08:21:02 e_HM2BB2_STATE noMotion
2025-06-13 08:21:00 e_LUM_state 82
2024-10-25 12:30:01 e_TWI_tww 100
2025-06-14 18:46:56 mode enabled
2025-06-14 18:46:56 state cmd_4
Regex:
cond:
395l_au:
0:
a ^395l_au$:^a:
1:
a ^395l_au$:^a:
2:
a ^395l_au$:^a:
3:
a ^395l_au$:^a:
395l_sl:
2:
a ^395l_sl$:^a:
3:
a ^395l_sl$:^a:
HM2BB2:
2:
&STATE ^HM2BB2$
LUM:
2:
state ^LUM$:^state:
3:
state ^LUM$:^state:
attr:
waitdel:
condition:
0 ::ReadingValDoIf($hash,'395l_au','a') < 0
1 ::ReadingValDoIf($hash,'395l_au','a') > 0
2 ::ReadingValDoIf($hash,'395l_au','a') == 0 and ::InternalDoIf($hash,'HM2BB2','STATE') eq "motion" and ::ReadingValDoIf($hash,'LUM','state') < ::ReadingValDoIf($hash,'395l_sl','a')
3 ::ReadingValDoIf($hash,'395l_au','a') == 0 and ::ReadingValDoIf($hash,'LUM','state') > ::ReadingValDoIf($hash,'395l_sl','a')
do:
0:
0 set HM4SW1_1 off
1:
0 set HM4SW1_1 on
2:
0 setreading HM2BB2 state noMotion, set HM4SW1_1 on-for-timer 200
3:
0 set HM4SW1_1 off
4:
helper:
NOTIFYDEV 395l_sl,global,395l_au,LUM,HM2BB2
globalinit 1
last_timer 0
sleeptimer -1
timerdev
timerevent
timerevents
timereventsState
triggerDev
internals:
all HM2BB2:STATE
perlblock:
readings:
all 395l_au:a LUM:state 395l_sl:a
uiState:
uiTable:
Attributes:
group DOIF
room 395 - Hausflur, _90 HW - HM.HW
Zitat von: TubeHead am 14 Juni 2025, 10:31:18Was mich aber dennoch irritiert ist der Umstand, dass hier nach dem Deaktivieren des "aktuellen" DOIF die Altlast nach einem Mal schalten anscheinend ebenfalls den Betrieb einstellt
Hab den Code jetzt nicht genau angeschaut, aber set_359l_au_a hat kein do always, vielleicht liegts daran.
Vielleicht setzt es sich tagsüber dann zurück, abends löst es 1x aus und verfällt dann wieder in einen Zweig, der dann wieder auf das Tagsüber-Zurücksetzen wartet.
Hmmm, das wäre natürlich eine Möglichkeit, die Sinn ergibt. Und ja... resp. nein: always ist hier nicht gesetzt.
Schon witzig, was man sich mit Altlasten so an Kopfschmerzen holen kann O:-)