[gelösst] DOIF mit reset waittimer

Begonnen von Larusso, 15 März 2019, 15:39:34

Vorheriges Thema - Nächstes Thema

Larusso

Hallo zusammen,

ich stehe mal wider ein bisschen auf dem Schlauch. Ich möchte über ein DOIF den Türzustand meines nuki locks ab 23 Uhr bis 5Uhr morgens abfragen. Sollte die Haustür nicht abgeschlossen sein so soll das doif diese abschließen, das ist soweit kein Problem. Nun möchte ich aber gerne noch einen wait timer einbauen der sich aber nach ändern des state reseted. Sollte also jemand nach 23 Uhr die Tür aufsperren und vergessen diese abzuschließen dann soll das doif die Tür mit einem wait von 10 Minuten abschließen. Wenn ich das ganze nur über ein wait mit 10min. mache und die Tür ist dann schon abgeschlossen nachdem jemand rein gekommen ist wird der Befehl ja trotzdem gesendet (ist jetzt nicht schlimm, kann man sich doch aber bestimmt sparen). Wenn möglich möchte ich das ganze über eine doif definition lösen und nicht zusätzlich noch einen watchdog mit einbauen. Hier ist mal das aktuelle doif ohne überwachen des state.

Internals:
   CFGFN     
   DEF        ([NukiLock:state] eq "unlock" and [23:00-05:00]) (set NukiLock lock)
DOELSEIF
([05:01])
   FUUID      5c8b451f-f33f-7f1e-56d3-e297838f7e36fcca
   MODEL      FHEM
   NAME       Tuer_abschliesen
   NR         9838
   NTFY_ORDER 50-Tuer_abschliesen
   STATE      initialized
   TYPE       DOIF
   .attraggr:
   .attrminint:
   READINGS:
     2019-03-15 15:38:50   Device          NukiLock
     2019-03-15 07:29:25   cmd             0
     2019-03-15 07:29:25   mode            enabled
     2019-03-15 07:29:25   state           initialized
     2019-03-15 07:29:25   timer_01_c01    15.03.2019 23:00:00
     2019-03-15 07:29:25   timer_02_c01    16.03.2019 05:00:00
     2019-03-15 07:29:25   timer_03_c02    16.03.2019 05:01:00
   Regex:
   attr:
     wait:
       0:
         300
   condition:
     0          ::ReadingValDoIf($hash,'NukiLock','state') eq "unlock" and ::DOIF_time($hash,0,1,$wday,$hms)
     1          ::DOIF_time_once($hash,2,$wday)
   days:
   devices:
     0           NukiLock
     all         NukiLock
   do:
     0:
       0          set NukiLock lock
     1:
       0         
     2:
   helper:
     event      name: Nuki_16EDFAAD,rssi: -55,paired: 1
     globalinit 1
     last_timer 3
     sleeptimer -1
     triggerDev NukiLock
     triggerEvents:
       name: Nuki_16EDFAAD
       rssi: -55
       paired: 1
     triggerEventsState:
       name: Nuki_16EDFAAD
       rssi: -55
       paired: 1
   internals:
   interval:
     0          -1
     1          0
   intervalfunc:
   itimer:
   localtime:
     0          1552687200
     1          1552708800
     2          1552708860
   readings:
     0           NukiLock:state
     all         NukiLock:state
   realtime:
     0          23:00:00
     1          05:00:00
     2          05:01:00
   time:
     0          23:00:00
     1          05:00:00
     2          05:01:00
   timeCond:
     0          0
     1          0
     2          1
   timer:
     0          0
     1          0
     2          0
   timers:
     0           0  1
     1           2
   trigger:
   triggertime:
     1552687200:
       localtime  1552687200
       hash:
     1552708800:
       localtime  1552708800
       hash:
     1552708860:
       localtime  1552708860
       hash:
   uiState:
   uiTable:
Attributes:
   do         always
   room       00 Schneider
   wait       300
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,

Otto123

Hi,

ich denke da musst Du einfach noch ein attr do resetwait setzen

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

Larusso

danke Otto, teste ich heute mal.
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,

amenomade

Ich würde einfach das DOELSEIF durch ein leeres DOELSE ersetzen. Damit würde das DOIF auf cmd_2 wechseln und das Timer abbrechen, sobald nicht mehr "unlock" (oder nicht mehr in der Zeitperiode)

Aber Vorsicht mit solchen DOIFs... da kann man sich ganz schnell aus dem Haus ohne Schlüssel aussperren... ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Otto123

Ach das hab ich nicht gesehen  :o
DOELSEIF
([05:01])
Ich würde das ganz weglassen, ich hasse solche leeren Zweige.

Es ist doch eine klare einfache Aufgabe - wozu braucht man da solche Konstrukte?
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

amenomade

Zitat von: Otto123 am 15 März 2019, 16:13:14
Ach das hab ich nicht gesehen  :o
DOELSEIF
([05:01])
Ich würde das ganz weglassen, ich hasse solche leeren Zweige.

Es ist doch eine klare einfache Aufgabe - wozu braucht man da solche Konstrukte?
Weil do always. Ohne DOELSE bleibt ein DOIF mit do always auf dem Zustand der letzte wahre Bedingung. Um das Timer abzubrechen braucht man aber doch ein Zustandswechsel.

PS: in dem Sinn ist das DOELSEIF [05:01] eher kontraproduktiv
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Damian

#6
Womöglich reicht schon das Weglassen von do always.

Dann gibt es automatisch den imaginären DOELSE-Zweig. Zwei mal "unlock" hintereinander kann es eigentlich nicht geben. Das Modul befindet sich nach 5:00 Uhr oder wenn es nicht unlock ist, immer in cmd2. Ein laufender waittimer wird bei ungleich "unlock" automatisch abgebrochen - das Modul wechselt also automatisch zwischen den beiden Zuständen cmd1 und cmd2.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Larusso

naja also es kann ja durchaus sein das nach 23 Uhr zwei Personen nochmal die Tür öffnen und dann würde doch ohne do always das schloss nur einmal verriegelt werden? Das resetwait würde dann auch nur einmal greifen, oder verstehe ich das falsch? Bei uns haben wir sieben Personen im Haushalt also muss auch ein zweites oder drittes öffnen der Tür wider zu einer Verriegelung führen.
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,

Damian

Zitat von: Larusso am 15 März 2019, 16:59:35
naja also es kann ja durchaus sein das nach 23 Uhr zwei Personen nochmal die Tür öffnen und dann würde doch ohne do always das schloss nur einmal verriegelt werden? Das resetwait würde dann auch nur einmal greifen, oder verstehe ich das falsch? Bei uns haben wir sieben Personen im Haushalt also muss auch ein zweites oder drittes öffnen der Tür wider zu einer Verriegelung führen.

Welche Zustände hat das Schloss? Es ist doch egal wie oft jemand das Schloss (wir reden ja nicht von der Tür) öffnet, denn wenn er es öffnet, muss es vorher einen anderen Zustand gehabt haben, sonst wäre es schon offen. Teste einfach mal deine Lösung (ggf. mit angepassten Zeiten) ohne do always.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Larusso

scheint zu funktionieren, denke das resetwait gut funktioniert.
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,