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!
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")...
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.
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
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.