DOIF reagiert nicht auf resetwait...

Begonnen von shamal2008, 31 Mai 2020, 20:46:56

Vorheriges Thema - Nächstes Thema

shamal2008

Hallo,

die Lösung von Otto hat bei 4 Motion-Sensoren hervorragend funktioniert, nur beim "WAF-wichtigsten" im Badezimmer "spinnt" das DOIF.
siehe hier: https://forum.fhem.de/index.php?topic=111352.msg1055874#msg1055874

Kann mir bitte irgendwer erklären, warum dieses DOIF (kopiert von 3 erfolgreichen) seit VORGESTERN NICHT funktioniert?? (siehe Listing unten).

Gleich zu Beginn: ich habe den Sensor im Conbee II gelöscht und neu angelernt (mehrfach), das DOIF von einem funktionierenden kopiert und nur die Zeiten geändert, das DOIF komplett neu angelegt, FHEM in der Zwischenzeit gefühlt 5x neu gestartet. FHEM wurde ebenfalls vor 10 Minuten aktualisiert.

Es ist definitiv so, dass das Doif auf das ResetWait nicht reagiert. Der Sensor kann während der Wait-Zeit 5x von Motion-auf no-motion und wieder zurück springen, es interessiert das DOIF einfach nicht.

Hat irgendwer eine Idee warum? Wäre cool bevor ich von meiner besseren Hälfte gesteinigt werde...  :-[

EDIT: Habe jetzt einen DOELSE()-Zweig mit dem ausschalten des Panels eingefügt, damit funktioniert der ResetWait-Timer, aber der Fehler muss definitiv im Resetwait liegen. Sobald ich einen zweiten Befehl im ersten Ausführungsteil einfüge, wirkt das resetwait nur auf den Teil mit DOELSE(). Der zweite Befehl im ersten Teil wird gar nicht angesprungen.

Internals:
   DEF        (([?li.bz.panel] eq "off") and ([mo.pr.bz.s2:state] eq "motion"))
(set li.bz.panel pct 100) (set li.bz.panel off)
   FUUID      5ed3924f-f33f-6c8f-3f51-4ce316ea1b1f3dcb
   MODEL      FHEM
   NAME       di.day.bz.panel
   NOTIFYDEV  mo.pr.bz.s2,global
   NR         382
   NTFY_ORDER 50-di.day.bz.panel
   STATE      cmd_1
   TYPE       DOIF
   VERSION    21224 2020-02-18 18:45:49
   READINGS:
     2020-05-31 20:34:35   Device          mo.pr.bz.s2
     2020-05-31 20:34:43   cmd             1.2
     2020-05-31 20:34:43   cmd_event       mo.pr.bz.s2
     2020-05-31 20:34:43   cmd_nr          1
     2020-05-31 20:34:43   cmd_seqnr       2
     2020-05-31 20:34:35   e_mo.pr.bz.s2_state nomotion
     2020-05-31 20:26:10   mode            enabled
     2020-05-31 20:34:43   state           cmd_1
     2020-05-31 20:34:43   wait_timer      no timer
   Regex:
     accu:
     cond:
       mo.pr.bz.s2:
         0:
           state      ^mo.pr.bz.s2$:^state:
   attr:
     cmdState:
     wait:
       0:
         0
         30
     waitdel:
   condition:
     0          (::InternalDoIf($hash,'li.bz.panel','STATE') eq "off") and (::ReadingValDoIf($hash,'mo.pr.bz.s2','state') eq "motion")
   do:
     0:
       0          set li.bz.panel pct 100
       1          set li.bz.panel off
     1:
   helper:
     DEVFILTER  ^global$|^mo.pr.bz.s2$
     NOTIFYDEV  global|mo.pr.bz.s2
     event      motion
     globalinit 1
     last_timer 0
     sleepdevice mo.pr.bz.s2
     sleepsubtimer -1
     sleeptimer -1
     timerdev   mo.pr.bz.s2
     timerevent motion
     triggerDev mo.pr.bz.s2
     DOIF_eventa:
       cmd_nr: 1
       cmd_seqnr: 2
       cmd_event: mo.pr.bz.s2
       cmd_1
     DOIF_eventas:
       cmd_nr: 1
       cmd_seqnr: 2
       cmd_event: mo.pr.bz.s2
       state: cmd_1
     timerevents:
       motion
     timereventsState:
       state: motion
     triggerEvents:
       motion
     triggerEventsState:
       state: motion
   internals:
     all         li.bz.panel:STATE
   readings:
     all         mo.pr.bz.s2:state
   trigger:
   uiState:
   uiTable:
Attributes:
   devStateIcon cmd_1:10px-kreis-gruen.png disabled:10px-kreis-rot.png
   do         resetwait
   group      00_Licht
   icon       helper_doif
   loglevel   3
   room       95_Conditions
   verbose    5
   wait       0,30


lg Shamal
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

Damian

Du musst genauer beschreiben, was das DOIF genau machen soll.

Es ist mir z. B. nicht klar: Soll es bei noMotion panel auf off setzen?

Was macht das DOIF genau nicht? Es ist normal, dass resetwait "etwas" nicht macht.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

shamal2008

#2
Hallo Damian,

also, das DOIF ist dafür gedacht, dass wenn das Licht, wenn NICHT bereits manuell eingeschalten, über die Bewegungserkennung aktiviert wird.
Dann soll es, solange der Bewegungsmelder erkennt, dass jemand im Raum ist, das Licht eingeschalten lassen. Der arbeitet auch zufriedenstellend und liefert brav im 10 Sekundentakt Events hinsichtlich motion und nomotion.

Als Sicherheit soll es bei "nicht-erkennen" einer Bewegung nachher noch 30 Sekunden gedimmt fahren und dann erst abschalten. Habe es gestern mit folgendem DOIF hinbekommen, dass er zumindest meiner Holden nicht ständig das Licht abdreht und sie mir bald "meinest"  ::)

Im Deconz kann ich das ganze nachbauen und dort funktioniert es auch. Nur ist es öd, eine Steuerung im Phoscon zu haben und alle anderen im FHEM, noch dazu, wenn diese in der "nacht" anders funktionieren sollen. Dafür gibt es di.night.* und di.days.*.

([?li.bz.panel:state] eq "off")
()
DOELSEIF ([mo.pr.bz.s2:state] eq "motion")
(set li.bz.panel pct 100)
DOELSEIF ([mo.pr.bz.s2:state] eq "nomotion")
    (set li.bz.panel pct 30)
    (set li.bz.panel off)


Das ResetWait sieht wie folgt aus: ATTR di.day.bz.panel resetwait 0:0:60,30

Hier auch die Events von gestern:
2020-06-01 00:38:21 HUEDevice li.bz.panel on
2020-06-01 00:38:26 HUEDevice mo.lux.bz.s1 lux: 55
2020-06-01 00:38:26 HUEDevice mo.lux.bz.s1 lightlevel: 17404
2020-06-01 00:38:26 HUEDevice mo.lux.bz.s1 daylight: 0
2020-06-01 00:38:26 HUEDevice mo.lux.bz.s1 dark: 0
2020-06-01 00:38:26 DOIF di.day.bz.panel wait_timer: no timer
2020-06-01 00:38:26 DOIF di.day.bz.panel wait_timer: 01.06.2020 00:39:26 cmd_2_2 mo.pr.bz.s2
2020-06-01 00:38:26 HUEDevice mo.pr.bz.s2 motion
2020-06-01 00:38:33 HUEDevice mo.lux.bz.s1 daylight: 0
2020-06-01 00:38:33 HUEDevice mo.lux.bz.s1 dark: 0
2020-06-01 00:38:33 HUEDevice mo.lux.bz.s1 lightlevel: 17324
2020-06-01 00:38:33 HUEDevice mo.lux.bz.s1 lux: 54
2020-06-01 00:38:33 DOIF di.day.bz.panel wait_timer: no timer
2020-06-01 00:38:33 DOIF di.day.bz.panel wait_timer: 01.06.2020 00:39:33 cmd_2_2 mo.pr.bz.s2
2020-06-01 00:38:33 HUEDevice mo.pr.bz.s2 motion


Das, was hier nicht funktioniert war die Erkennung, dass das Licht bereits an ist und er daher nichts mehr tun braucht. Bei uns herrscht die Regel, wer aufdreht, dreht auch wieder ab (=FHEM auf/ab, manuell auf/ab). Was ich nicht verstehe ist, dass er überhaupt in das DOIF reinspringt, wenn das Panel "on" ist. Egal ob mit Fragezeichen, ohne, mit "state" oder nur mit li.bz.panel:"off", sobald der PIR anschlägt, bin ich drin und dann dreht er ab, wie er lustig ist.

Ich komme offensichtlich mit den Events/Status/Triggern bzw. Ereignis/Status nicht klar. Da hilft offensichtlich keine 200 Seiten Threads, gefühlte 10x Commandref, WIKI, DOIF-Labor, etc. und ca. 20 Tests mit allen möglichen Varianten. Ich bin offensichtlich zu dämlich dafür.

lg Shamal
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

Damian

Die erste Bedingung wird nicht ausgewertet, da sie keinen Trigger hat, daher ist eine solche Definition nicht sinnvoll.

Du musst erkennen, ob manuell eingeschaltet wurde oder automatisch.

Das kannst du an der Abfrage [?li.bz.panel:state] eq "off" alleine nicht erkennen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Otto123

Moin,

ich habe das gestern auch schon mitgelesen und nicht verstanden was nicht geht :)
Damian, deinen Einwand verstehe ich auch nicht.
Ich habe ein ähnliches DOIF
defmod di_Flurlicht DOIF ([PIR1:"motion:.on"] and (!isday("REAL")?1:0 or [?PIRWg:brightness] < 130)) (set SW01_Sw01 on)(set SW01_Sw01 off)
attr di_Flurlicht do resetwait
attr di_Flurlicht room Flur
attr di_Flurlicht wait 0,180
Das funktioniert so einwandfrei. Es enthält auch eine Abfrage ohne trigger. Allerdings werte ich beim Bewegungsmelder den Event aus.

@Shamal Ich habe eine ähnliche Erkennung auch schon gemacht, allerdings setze ich in dem Fall den Befehl on-for-timer nicht ab wenn schon on ist. Wenn dein DOIF einmal zugeschlagen hat, kann ja die Bedingung nicht mehr wahr werden, denn dann ist ja nicht mehr off. Du kannst doch aber mit pct arbeiten pct 99 ist automatik, alles andere ist manuell. Nutze ich so bei meinen Rollläden.

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

Damian

#5
Zitat von: Otto123 am 01 Juni 2020, 10:12:49
Moin,

ich habe das gestern auch schon mitgelesen und nicht verstanden was nicht geht :)
Damian, deinen Einwand verstehe ich auch nicht.
Ich habe ein ähnliches DOIF
defmod di_Flurlicht DOIF ([PIR1:"motion:.on"] and (!isday("REAL")?1:0 or [?PIRWg:brightness] < 130)) (set SW01_Sw01 on)(set SW01_Sw01 off)
attr di_Flurlicht do resetwait
attr di_Flurlicht room Flur
attr di_Flurlicht wait 0,180
Das funktioniert so einwandfrei. Es enthält auch eine Abfrage ohne trigger. Allerdings werte ich beim Bewegungsmelder den Event aus.

@Shamal Ich habe eine ähnliche Erkennung auch schon gemacht, allerdings setze ich in dem Fall den Befehl on-for-timer nicht ab wenn schon on ist. Wenn dein DOIF einmal zugeschlagen hat, kann ja die Bedingung nicht mehr wahr werden, denn dann ist ja nicht mehr off. Du kannst doch aber mit pct arbeiten pct 99 ist automatik, alles andere ist manuell. Nutze ich so bei meinen Rollläden.

Gruß Otto

Deine Lösung ist aber nicht das was er will.
Er will die Automatik manuell übersteuern, das ist bei dir nicht drin.

Wenn Licht manuell eingeschaltet, dann soll die Automatik nicht laufen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

shamal2008

Hallo Damian & Otto,

Damian hat recht - genau das soll das Doif machen - wenn das Licht bereits manuell eingeschalten wurde, dann sollen die DOIFs für die Bewegungsmelder "außer Betrieb" gehen. Ich dachte mittlerweile an eine Lösung, die ich bereits für die unterschiedlichen Lichtszenen in der Nacht verwende.

Die wäre wie folgt: das DOIF disablen, sobald das Licht brennt und wenn es wieder ausgeschalten wird, dann wieder enablen.

Trotzdem verstehe ich nach wie vor nicht, warum das DOIF überhaupt "anspringt". Meinem Verständnis nach wird geprüft, ob eingeschalten ist. Wenn das der Fall ist, müsste das DOIF doch überhaupt nicht aktiv werden. Wo ist mein Denkfehler bzw. mein Knopf im Kopf?

Gibt es irgendwo ein Tutorial/HowTo, etc. (ausser WIKI, CommandRef), wo das mit den Triggern,Events usw. im DOIF erklärt ist. Wie gesagt, die Beispiele in der CommandRef helfen mir leider nicht weiter im Verständnis.

Danke,
Shamal

PS: mit der letzten Variante (mit dem "Blindbefehl" geht zumindest das Licht nicht mehr zwischendurch aus. Das hat mal für's erste schon beruhigt..
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

MadMax-FHEM

Wie Otto schon geschrieben hat, du brauchst eine "Erkennung" bzw. KLARE "Unterscheidung" zwischen Manuell und DOIF...

Und abfragen auf "on" ist keine Lösung.
Weil du bei einem neuen Durchlauf des DOIF nicht weißt, ob on durch BWM/DOIF kam oder durch manuelle Bedienung...

Otto meint, dass DOIF nicht on, sondern 99 setzt: Automatik
Du könntest dir auch einen anderen Merker setzen (Reading in DOIF, geht ja glaube ich) und den "abfragen"...

Was halt immer noch passieren kann mit dem Merker: BWM schaltet ein (Merker) und jemand schaltet manuell aus -> Merker "automatik" bleibt...

Daher ist die "99-Lösung" wohl "besser"...

Außer der Schalter ist nicht "direkt verbunden" und alles geht irgendwie über fhem (oder du hast ein notify was den Merker zurücksetzt)...
...aber Licht, Heizung, ... muss (meiner Meinung nach) "autark" laufen...

Ich habe bei mir EnOcean, da senden die Schalter. D.h. fhem bekommt mit, wenn manuell geschaltet wurde und setzt Automatik außer Kraft...
Bewegungsmelder (Kompfort-Funktion ;)  die kann schon mal über fhem gehen / "muss" in dem Fall, weil kein EnOcean BWM) schaltet nur, wenn nicht manuell betätigt...

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)

Damian

Das sollte deine Lösung sein:

defmod di_motion DOIF ([li.bz.panel:state] eq "on")\
DOELSEIF([li.bz.panel:state] eq "off")\
DOELSEIF([mo.pr.bz.s2:state] eq "motion" and $cmd != 1)(set li.bz.panel pct 100) (set li.bz.panel off)
attr di_motion do resetwait
attr di_motion wait ::0,30
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

shamal2008

Hallo Damian,

danke für den Vorschlag. Probiere ich heute nachmittag aus und gebe Bescheid.

Wenn das Licht zuverlässig "on" bleibt, was bis dato ja nicht wirklich gegeben war, schaltet bei uns eh keiner mehr "manuell" aus. Das fällt gsd schon unter "Notbetrieb". Die Faulheit siegt sowieso.

@MadMax-FHEM: Versuche auch den Vorschlag von Otto mit pct 99.

lg Shamal.
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;