Timer für Rolladen/Dachfenster

Begonnen von tomily, 06 Dezember 2017, 11:19:29

Vorheriges Thema - Nächstes Thema

tomily

Hallo Leute,

ich habe mal eine Frage an euch:

Ich habe für mein el. Dachluke einen Homematic-Rolladenaktor verbaut und in FHEM eingebunden.
Kann mir jemand sagen, wie ich folgendes Ziel erreichen kann:

Sobald das Dachfenster am Schalter direkt geöffnet wird (Zustand ist dann größer =0), soll das Fenster nach 30 Minuten automatisch wieder schließen.
Status 0 = geschlossen / Status 100 = geöffnet.

Ich bin bei meinen Versuchen mit timern leider gescheitert.

Würde mich extrem über euer Feedback freuen.

Grüße Tom

Fixel2012

Ein einfaches Modul dafür ist DOIF, ist sehr anfänger freundlich.

Siehe hier:

http://commandref.fhem.de/commandref_DE.html#DOIF

Hat allerdings sehr viele Möglichkeiten und könnte dich am Anfang etwas verwirren.
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

CoolTux


define notifyDachfenster notify dachfensterdevice:pct:.* { if( $EVTPART1 > 0) { fhem("sleep 1800; set $DEVICE pct 0") }


Könnte so gehen

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Hollo

Zitat von: CoolTux am 06 Dezember 2017, 12:41:20
Könnte so gehen
Oder z.B. einen watchdog, der auf öffnen triggert und nach 30 Minuten schliesst, wenn nicht in der Zeit geschlossen.

Wir kennen ja die ganzen bisherigen Versuche nicht!?   :-\

FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

CoolTux

Das ist sogar noch viel viel besser. Ich vergesse immer wieder den Watchdog. Dabei ist der echt gut
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tomily

Hey Leute,

wow das ging aber schnell. Danke für eure Ansätze.
Werde mir das DoIf aufjeden Fall anschauen.

Hat bezüglich dem Watchdog jemand auf die Schnelle eine Idee, wie das realisierbar wäre?
Die Wiki-Einträge zum Watchdog erschlägt mich etwas :-)))

Grüße

CoolTux


presenceNadin.presence:.present 00:05:35 presenceNadin.presence:.absent {systemCommand("wd_GTagBatterieNadin","gtagbattery",5)} ; trigger wd_GTagBatterieNadin .


Achtung der Punkt am Ende ist wichtig, nicht übersehen!
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tomily

wow, danke für die schnelle Antwort. Jetzt sollte ich es nur noch kapieren :-)
"wd_GTagBatterieNadin" wäre dann durch den Namen meines Gerätes zu ersetzen, oder?

CoolTux

Sorry mein Fehler. So kannst Du natürlich nichts erkennen


Internals:
   CFGFN
   CMD        {systemCommand("wd_GTagBatterieNadin","gtagbattery",5)} ; trigger wd_GTagBatterieNadin .
   DEF        presenceNadin.presence:.present 00:05:35 presenceNadin.presence:.absent {systemCommand("wd_GTagBatterieNadin","gtagbattery",5)} ; trigger wd_GTagBatterieNadin .
   NAME       wd_GTagBatterieNadin
   NR         473
   NTFY_ORDER 50-wd_GTagBatterieNadin
   RE1        presenceNadin.presence:.present
   RE2        presenceNadin.presence:.absent
   STATE      defined
   TO         335
   TYPE       watchdog
   READINGS:
     2017-12-06 10:34:15   Activated       activated
     2017-12-06 10:39:50   Triggered       triggered
   helper:
Attributes:


So sieht man was was ist. Im Grunde funktioniert watchdog ähnlich wie notify.

presenceNadin.presence:.present 00:05:35 presenceNadin.presence:.absent - getriggert wird auf das Device presenceNadin mit dem Reading presence und den Wert present wenn das als Event kommt löst der watchdog aus. Dann wird 5min und 35sekunden gewartet und wenn in dieser Zeit kein Event kommt was das Device presenceNadin mit dem Reading presence und dem Wert absent beinhaltet wird ausgelöst.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tomily

Hallo CoolTux,

vielen Dank für Deine Mühe. Erst mal sorry für meine späte Antwort. Ich musste kurzfristig wegfahren.
Bitte lache mich nicht aus, aber ich bin immernoch nicht ganz dahinter gestiegen, würde es aber gerne verstehen.

Mein Device, das ich schalten will heißt bad_Dachfenster. Es soll nach der Zeit den Status 0 erhalten.
Wäre das dann die Zeile, die ich eingeben muss? Oder muss ich hierzu ein dummy o.ä. anlegen?

define bad_Dachfenster.presence:.present 00:05:35 bad_Dachfenster.presence:.absent {systemCommand("wd_GTagBatterieNadin","gtagbattery",5)} ; trigger wd_GTagBatterieNadin .

Besten Dank und Grüße

CoolTux

Zitat von: tomily am 11 Dezember 2017, 08:19:37
Hallo CoolTux,

vielen Dank für Deine Mühe. Erst mal sorry für meine späte Antwort. Ich musste kurzfristig wegfahren.
Bitte lache mich nicht aus, aber ich bin immernoch nicht ganz dahinter gestiegen, würde es aber gerne verstehen.

Mein Device, das ich schalten will heißt bad_Dachfenster. Es soll nach der Zeit den Status 0 erhalten.
Wäre das dann die Zeile, die ich eingeben muss? Oder muss ich hierzu ein dummy o.ä. anlegen?

define bad_Dachfenster.presence:.present 00:05:35 bad_Dachfenster.presence:.absent {systemCommand("wd_GTagBatterieNadin","gtagbattery",5)} ; trigger wd_GTagBatterieNadin .

Besten Dank und Grüße

Ok schauen wir mal zusammen.

Du möchtest einen watchdog anlegen

define wd_badDachfensterTimerClosed watchdog


Damit legst Du fest das etwas definiert wird (define), den Namen des Watchdogs, also wie er heißen soll (wd_badDachfensterTimerClosed) und um was für ein Gerätetyp es sich handelt (watchdog)

Nun kommt das eigentliche was soll getriggert/überwacht werden

define wd_badDachfensterTimerClosed watchdog bad_Dachfenster:pct.[1-9]+ 00:05:35 bad_Dachfenster:pct.0 set bad_Dachfenster pct 0, trigger wd_badDachfensterTimerClosed .

bad_Dachfenster:pct.[1-9]+
getriggert wird auf das Event bad_Dachfenster:pct.[1-9]+ , um es einfach zu sagen wenn das Device bad_Dachfenster im Reading pct eine Änderung erfährt vom Wert > 0 dann lasse den watchdog anlaufen (das [1-9]+ ist RegEx)
lasse den Watchdog  00:05:35 lang laufen so lange nicht ein Event kommt bad_Dachfenster:pct.0 , also einfach ausgedrückt wenn das Device bad_Dachfenster im Reading pct eine Änderung erfährt vom Wert gleich 0

Das trigger am Ende ist noch alte Schule, dafür gibt es mittlerweile ein Attribut, geht nur darum das er beim nächsten mal wieder triggert.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tomily

Hi,

danke für deine mega schnelle Reaktionen und die ausführliche Erklärung.
Habs definiert und es wurde auch angelegt. Leider fährt das Fenster nach Ablauf der Zeit nicht automatisch zu :-/

Hab mal 2 Screenshots angehängt, vielleicht kannst Dir das ja mal anschauen :-)

Grüße


CoolTux

Ist denn der Watchdog abgelaufen? Kannst du bitte Mal ein list geben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux


define wd_badDachfensterTimerClosed watchdog bad_Dachfenster:pct:.[1-9]+ 00:00:10 bad_Dachfenster:pct:.0 set bad_Dachfenster pct 0; trigger wd_badDachfensterTimerClosed .


Getestet und für gut befunden. Bitte kopie paste machen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tomily

cool! Danke. Also jetzt habe ich es grob gerafft, um was es geht.
Das anlegen hat geklappt. Allerdings funktioniert der Watchdog nur genau 1x.

Nach Anlage läuft der Timer zur korrekten Zeit und schließt auch das Fenster. Allerdings bleibt der watchdog dann für immer auf "triggered" stehen,
obwohl das Fenster wie im Screenshot auf Wert 10 (also über 0) steht.
Habe gerade noch festgestellt, dass der geschlossene Zustand "off" und nicht 0 ist. Kann es damit zu tun haben?
FHEM zeigt den Zustand also bis 0.1 in Zahlen und zeigt anschließend "off" als Schaltzustand an.

Liebe Grüße