Verzögern der Bedingungsabfragen

Begonnen von lukasbastelpeter, 17 März 2017, 17:38:03

Vorheriges Thema - Nächstes Thema

lukasbastelpeter

Hallo,

ich habe folgendes DOIF:

([livingroom.shutter.controller:drivingUp] eq "on" and [livingroom.shutter] ne "drive-up") (set livingroom.shutter extern open)

mein Problem ist nun, ändert sich  [livingroom.shutter], wird die Bedingung geprüft. zu genau dem Zeitpunkt hat [livingroom.shutter.controller:drivingUp] aber zu 99% "noch" den State "on", der hängt nämlich von dem ersten teil ab. also das device livingroom.shutter sorgt für eine Änderung des livingroom.shutter.controller.
Somit ist der korrekte Status des livingroom.shutter.controller erst ca. 1-2 Sekunden nach dem auslösen des DOIF am Start.
Gibt es da eine Möglichkeit das entsprechend zu verzögern?
Alternativ habe ich mir überlegt einfach nur ein
DOIF ([livingroom.shutter] ne "drive-up") (IF ([livingroom.shutter.controller:drivingUp] eq "on") (set livingroom.shutter extern open))
zu erstellen, wo dann der "befehle", also der IF-Teil mit "Wait" versehen wird, das würde allerdings einiges an umfrickeln bedeuten, deswegen erhoffe ich mir da eine "schönere" Lösung :) Danke!
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

Damian

Zitat von: lukasbastelpeter am 17 März 2017, 17:38:03
Hallo,

ich habe folgendes DOIF:

([livingroom.shutter.controller:drivingUp] eq "on" and [livingroom.shutter] ne "drive-up") (set livingroom.shutter extern open)

mein Problem ist nun, ändert sich  [livingroom.shutter], wird die Bedingung geprüft. zu genau dem Zeitpunkt hat [livingroom.shutter.controller:drivingUp] aber zu 99% "noch" den State "on", der hängt nämlich von dem ersten teil ab. also das device livingroom.shutter sorgt für eine Änderung des livingroom.shutter.controller.
Somit ist der korrekte Status des livingroom.shutter.controller erst ca. 1-2 Sekunden nach dem auslösen des DOIF am Start.
Gibt es da eine Möglichkeit das entsprechend zu verzögern?
Alternativ habe ich mir überlegt einfach nur ein
DOIF ([livingroom.shutter] ne "drive-up") (IF ([livingroom.shutter.controller:drivingUp] eq "on") (set livingroom.shutter extern open))
zu erstellen, wo dann der "befehle", also der IF-Teil mit "Wait" versehen wird, das würde allerdings einiges an umfrickeln bedeuten, deswegen erhoffe ich mir da eine "schönere" Lösung :) Danke!


wenn livingroom.shutter.controller einen Trigger erzeugt, dann reicht nur auf diesen zu triggern und livingroom.shutter nur abzufragen.

also

([livingroom.shutter.controller:drivingUp] eq "on" and [?livingroom.shutter] ne "drive-up")...




Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

KernSani

Ich verstehe das Problem nicht, glaube ich... der Befehlsteil wird doch nur ausgeführt, wenn beide Bedingungen wahr sind...
Du musst meinem Verständnis nach den Controller als trigger nehmen und dem shutter ein ? vorne dran packen, dann triggert der nicht, sondern wird nur überprüft.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

lukasbastelpeter

#3
Ja, das ist alles recht komplex :D verbal wäre das schnell erklärt, aber das "?" ist das wonach ich glaube ich gesucht habe...
Ich kann also sagen:
Wenn sich die Rollade bewegt, und der Status nicht passt, dann mache....
Jetzt ist ja,
Die rollade bewegt sich, der Status wird geprüft, "noch" ist Status aber stop, ergo bleibt das teil wieder stehen...

Ich versuche es mal mit dem ?. Klingt logisch. Danke!

EDIT: Tut leider nicht wie ich es gerne hätte, ich kopiere jetzt mal meine Situation:

DOIF:
DOIF ([office.shutter.controller:drivingUp] eq "on" and [?office.shutter] ne "drive-up") (set office.shutter extern open) DOELSEIF ([office.shutter.controller:drivingUp] eq "off" and [?office.shutter] eq "drive-up") (set office.shutter extern stop)
DOELSEIF ([office.shutter.controller:drivingDown] eq "on" and [?office.shutter] ne "drive-down") (set office.shutter extern closed) DOELSEIF ([office.shutter.controller:drivingDown] eq "off" and [?office.shutter] eq "drive-down") (set office.shutter extern stop)



office.shutter:
Internals:
   CFGFN
   NAME       office.shutter
   NR         1539
   STATE      closed
   TYPE       ROLLO
   stoptime   1489772828
   Helper:
     Dblog:
       Position:
         System.database:
           TIME       1489772825.87591
           VALUE      99
   Readings:
     2017-03-17 18:47:06   command         closed
     2017-03-17 18:47:06   desired_position 100
     2017-03-17 18:47:08   drive-type      na
     2017-03-17 18:47:06   last_drive      drive-down
     2017-03-17 18:47:08   position        100
     2017-03-17 18:47:08   state           closed
Attributes:
   DbLogInclude position
   alias      Rollade
   autoStop   0
   blockMode  blocked
   commandDown set office.shutter.controller pulse 14 1 500
   commandStopDown set office.shutter.controller pulse 14 1 500
   commandStopUp set office.shutter.controller pulse 13 1 500
   commandUp  set office.shutter.controller pulse 13 1 500
   devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:open position-90:fts_shutter_80:closed position-80:fts_shutter_80:closed position-70:fts_shutter_70:closed position-60:fts_shutter_60:closed position-50:fts_shutter_50:closed position-40:fts_shutter_40:open position-30:fts_shutter_30:open position-20:fts_shutter_20:open position-10:fts_shutter_10:open position-0:fts_shutter_10:closed
   excessBottom 0
   excessTop  0
   group      Raum
   resetTime  2
   room       00_Arbeitszimmer
   secondsDown 23
   secondsUp  25
   shutter    home.shutter
   switchTime 1
   type       normal
   userattr   shutter shutter_map structexclude
   webCmd     open:closed:half:stop:position



und mein office.shutter.controller:
Internals:
   CFGFN
   CHANGED
   DEF        192.168.20.138 80 interface.esp shutter_office_interface
   ESP_BUILD  142
   ESP_SLEEP  0
   ESP_UNIT   0
   HOST       192.168.20.138
   IDENT      shutter_office_interface
   INTERVAL   300
   IODev      interface.esp
   LASTInputDev interface.esp
   MSGCNT     3463
   NAME       office.shutter.controller
   NOTIFYDEV  global
   NR         1541
   NTFY_ORDER 50-ESPEasy_shutter_office_interface
   PORT       80
   STATE      present, -57.00
   SUBTYPE    device
   TYPE       ESPEasy
   VERSION    0.81
   interface.esp_MSGCNT 3463
   interface.esp_TIME 2017-03-17 18:48:01
   Readings:
     2017-03-17 18:47:27   drivingDown     off
     2017-03-17 18:47:03   drivingUp       off
     2017-03-17 18:44:37   presence        present
     2017-03-17 18:48:01   rssi            -57.00
     2017-03-17 18:48:01   state           dri: off dri: off rss: -57.00
   Helper:
     fpc        1489567592.33172
     Intat:
       1:
         FN         ESPEasy_statusRequest
         INTERVAL   302
         TRIGGERTIME 17.03.2017 18:49:38
     Received:
       drivingDown 1489772847.17063
       drivingUp  1489772823.54909
       rssi       1489772881.63791
Attributes:
   IODev      interface.esp
   Interval   300
   alias      Arbeitszimmer Rolladen ESP
   event-on-change-reading drivingDown,drivingUp,rssi,presence
   group      ESP
   presenceCheck 1
   readingSwitchText 1
   room       98_Aktoren,98_Sensoren
   setState   3
   stateFormat {ReadingsVal("office.shutter.controller","presence","absent").", ".ReadingsVal("office.shutter.controller","rssi","noValue")}




So, ich habe also ein DOIF, ein "Rollo"-Device und ein ESP, welcher das physikalische Interface zum Gurtwickler darstellt.
Nutze ich das Rollo-Device, welches nur die Logik abbildet autark, also ohne Rückmeldung des ESP, funktioniert alles bestens.

Folgende Situation möchte ich nun mit dem DOIF abfangen:
FHEm steuert das Rollo-Device an und sagt z.B. "open", ich sitze im Wohnzimmer faul vor dem Fernseher und möchte aber nicht, dass die Rollade auf geht damit ich weiter TV schauen kann ;). Also drücke ich den Taster auf dem Gurtwickler, Rollade bleibt stehen. Damit nun der Status in FHEM entsprechend nachgeführt wird gibt es ein "Set extern open/closed" im ROLLO-Modul.
Das sollte dann in diesen Fällen den Status entsprechend anpassen.

Natürlich wird das Reading des Controllers aber auch gesetzt wenn alles planmäßig von FHEM aus gesteuert wird. Leider halt erst mit ein wenig Verzögerung...
Denn 1. muss der Befehl via WLAN zum Gurtwickler(ca. 400ms) und dann muss der Status das sich nun etwas bewegt oder auch nicht mehr, via WLAN zurück. So dauert es mindestens 1s bis der Controller das Reading auf "drivingUp=on" stehen hat...

Greift das DOIF jetzt aber schon bevor der Status aktualisiert ist, denkt das Rollo-Modul, ok, ich habe "beweg dich" gesendet, aber es bewegt sich nicht, bzw "es ist anscheinend schon am Endanschlag" o.Ä. und Setzt den Status auf geschlossen. oder sowas.

Hilfe! :D :o
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

Damian

Allgemein kann man sagen: wenn du es nicht schaffst den "richtigen" späteren Trigger abzugreifen. Dann kannst du mit IF und wait arbeiten oder sogar sleep mit Semikolon dahinter nutzen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF