DOIF nur wenn Tür mindestens 15 Minuten lang offen.

Begonnen von SebastianStorb, 25 Februar 2020, 08:45:17

Vorheriges Thema - Nächstes Thema

SebastianStorb

FHEM DOIF soll nur dann eine Nachricht schicken wenn ein Ereignis (z.B. Tür offen, Fenster offen, Temperatur im Kühlschrank abgefallen oder Lampe an) mindestens z.B. 30 Minuten lang besteht. Die Nachricht soll jedoch nicht geschickt werden, wenn das Ereignis in der Zwischenzeit nicht mehr besteht (Tür geschlossen, Fenster wieder zu, Temperatur im Kühlschrank wieder normal).

Was funktioniert:
Das Ereignis (Lampe an) wird ausgelöst.
Das Ereignis (Lampe an) wird zeitverzögert ausgelöst (z.B. 30 Sekunden).
Das Ereignis (Lampe an) wird per SMS auf mein Handy gesendet.

([Wohnzimmer] eq "on")
({system ("sudo gammu-smsd-inject TEXT +4917xxxxxxxx -text 'FHEM: Das Licht wurde eingeschaltet'")})


Hier vermutet ich, dass es funktioniert (getestete Zeit zu kurz um es genau sagen zu können):
Das Ereignis (Lampe an) wird zurückgesetzt wenn die Lampe zwischendurch ausgemacht wurde
attr doif_LampeAnSMS do resetwait
attr doif_LampeAnSMS wait 30 (<-wieder mit 30 Sekunden anstatt Minuten getestet)

Was nicht funktioniert:
Das Ereignis wird ausgelöst, obwohl sich der Status wieder geändert hat (Lampe aus).
Das Ereignis soll nach dem ersten Auslösen erst wieder nach einer weiteren (z.B. Stunde) Wartezeit per SMS verschickt werden (und nicht alle paar Minuten)

Kann mir jemand helfen? Ich habe gestern über 6 Stunden Anleitungen repeatcmd(DOELSEIF ([Wohnzimmer] eq "off" and [?$SELF:cmd] eq "1") und Hinweise aus Forum ausprobiert - ohne Erfolg - es funktioniert nicht.

rabehd

#1
Es ist immer gut, wenn man sich an das Problem rantastet. Es wird auch gern gesehen, wenn man Code als solchen darstellt (der Button mit # über den Editierfenster).

Willst Du auf alle diese Ereignisse nach einer Zeit mit der gleichen/Variablen Meldung reagieren?
ZitatEreignis (z.B. Tür offen, Fenster offen, Temperatur im Kühlschrank abgefallen oder Lampe an)

ZitatWas funktioniert:
Freut mich, aber wenn Du sagt wie es funktioniert (List des DOIF), dann hilft das mehr.
Das Problem in deinen ersten Satz ist schnell gelöst. Danach wird dein Text schwer verständlich.

Auch funktionierende Lösungen kann man hinterfragen.

Ralli

Zitat
Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.


def meindoif DOIF ([Wohnzimmer] eq "on")
({system ("sudo gammu-smsd-inject TEXT +4917xxxxxxxx -text 'FHEM: Das Licht wurde eingeschaltet'")})
DOELSE ()
attr meindoif wait 900:0
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

MadMax-FHEM

Hallo,

keine Hilfe bzgl. DOIF ;)

(wobei bei der Beschreibung laut Thread-Titel hätte verm. Watchdog auch funktioniert / warum immer gleich DOIF ;)  )

Aber eine Anmerkung genereller Art im "Umgang" mit fhem:

Zitat
({system ("sudo gammu-smsd-inject TEXT +4917xxxxxxxx -text 'FHEM: Das Licht wurde eingeschaltet'")})

fhem ist "single-threaded" -> Aufrufe wie der von dir verwendete können fhem blockieren, je nachdem was der Aufruf macht bzw. wenn dieser blockieren kann (also länger dauern kann, z.B. Netzwerk "nicht da" etc.)

Besser (wenn kein Rückgabewert notwendig):


({fhem("\"sudo gammu-smsd-inject TEXT +4917xxxxxxxx -text 'FHEM: Das Licht wurde eingeschaltet'\"")})


Siehe auch: http://heinz-otto.blogspot.com/2018/02/in-fhem-externe-programme-aufrufen.html

Andere Variante: den Aufruf auf "Non-Blocking-Call" umbauen. Aber sehr aufwendig (verglichen mit "einfach Anführungszeichen verwenden"), siehe auch: https://wiki.fhem.de/wiki/Blocking_Call

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)

CoolTux

Hier mal ein Watchdog Beispiel

Internals:
   CMD        set pushmsg msg title="Wohnungsstatus krittisch" priority=1 device=handy-marko Achtung! Seit 30min wurde die Wohnungstür nicht geschlossen
   DEF        TuerKontaktFlur_Wohnungstuer.open 00:30 TuerKontaktFlur_Wohnungstuer.closed set pushmsg msg title="Wohnungsstatus krittisch" priority=1 device=handy-marko Achtung! Seit 30min wurde die Wohnungstür nicht geschlossen
   FUUID      5c485fb1-f33f-fc06-60e0-cce34b6fb1cc8c32
   NAME       wd_WgTuereNichtZu
   NR         416
   NTFY_ORDER 50-wd_WgTuereNichtZu
   RE1        TuerKontaktFlur_Wohnungstuer.open
   RE2        TuerKontaktFlur_Wohnungstuer.closed
   STATE      defined
   TO         1800
   TYPE       watchdog
   READINGS:
     2020-02-25 07:01:56   Activated       activated
     2020-02-25 07:01:59   Reset           reset
     2019-10-25 13:02:13   Triggered       triggered
Attributes:
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

Pfriemler

genau, Watchdog.
Anderenfalls ist zunächst eine Zustandsmaschine erforderlich. Wie beim Watchdog für jedes Device ein DOIF, zwei Zweige (je nach Zustand "Countdown für Nachricht" oder "Ereignis hat sich erledigt". Benachrichtigung verzögern, fertig.

Die übrigen Dinge wie wiederholte Benachrichtigung und Sperrzeiten hängen sehr davon ab welche Events die überwachten Geräte liefern (einmalig, wiederholt, Abstand).

Mehr Hilfe bei mehr Details.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Ebenfalls ohne DOIF...
Benni's Code für eine "Globale und flexible Fenster- und Türüberwachung", https://forum.fhem.de/index.php/topic,36504.msg287778.html#msg287778
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

SebastianStorb

Vielen herzlichen Dank für die Vielen Antworten und Anregungen!

Es scheint jetzt gut zu funktionieren, daher wollte ich noch meine Attributes Einstellungen mitteilen (wie oben empfohlen):
do resetwaitdeleteattr
room
System
deleteattr
wait
30
deleteattr

SebastianStorb

#8
Vielen herzlichen Dank für die vielen Antworten und Anregungen!

Es scheint jetzt gut zu funktionieren, daher wollte ich noch meine Attributes Einstellungen mitteilen (wie oben empfohlen):

([Wohnzimmer] eq "on")
({fhem("\"sudo gammu-smsd-inject TEXT +4917xxxxxxxx -text 'FHEM: Das Licht wurde eingeschaltet'\"")})
DOELSE ()
attr doif_LampeAnSMS wait 30:0


do resetwait
room System
wait 30


Die o.g. Änderung für den SMS Versand habe ich sofort einpflegt! Hierdurch wird der Versand auch sofort versendet (und nicht mit Verzögerung von 30 Sekunden) und auf 900:0 einstellen!

Beta-User

Neben dem Hinweis auf [gelöst](?) vielleicht noch zwei Lesetipps, mit denen du das etwas ungeschickte Rauskopieren aus der WEB-Darstellung optimieren kannst:

https://fhem.de/commandref_modular.html#list
https://wiki.fhem.de/wiki/Import_von_Code_Snippets
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors