DOIF Triggerung durch bestimmtes device ausschließen

Begonnen von Peter_Listig, 27 Mai 2020, 11:37:22

Vorheriges Thema - Nächstes Thema

Peter_Listig

Tag zusammen,

ich habe meine Rolläden früher mal mit 433 Mhz Antrieben betrieben.
da diese jedoch keine Meldung für offen/geschlossen zurückgegeben
haben, habe ich simple Tür/Fenster Kontakte für Meldung benutzt.
Nach dem Umstieg auf DUOFERN-Antriebe waren und sind die Kontakte
- hier als Beispiel [IT_V3_1b68001] - eigentlich über flüssig.

Nun möchte ich sie jedoch benutzen um ein unbefugtes Öffnen (Hoch-
schieben) der Rolladen zu melden.


define ManuellAuf DOIF ([?12300-07:30] and [?ALARM_ON_OFF] eq "on" and [IT_V3_1b68001] eq "OFFEN") (set Mein_boot message Rollo wurde bewegt - bitte prüfen !)


Natürlich wird auch bei automatischer Betätigung (z.B. öffnen bei sunrise) oder manueller Betätigung (Tastendruck) logischerweise die
Meldung ausgegeben.

Kann man das verhindern indem man z.B. das auslösende Device (DUOFERN_611CA2) im DOIF ausschließt?

Bei [?DUOFERN_611CA2] kommt die Meldung auch.

Ein Tipp wäre toll

Danke im Voraus

Peter



Raspi4 / Debian Bullseye / FB 7490 / FHEM 6.x / CUL433 / CUL868 / aculfw / FrtizFon / DECT200 / IT / Homematic / ZigBee (Raspbee) /  Rademacher / HE / km200  / DS214+

moskito

Hi Peter,

also wenn Du ein Reading/Event des Duofern Gerätes hast, das Du auswerten kannst bevor der Magnetkontakt auslöst, dann kannst du es einfach in der Bedingung zum versenden mit berücksichtigen.
Ich weiß jetzt leider nicht, was ein Duofern Device im Detail an Informationen hergibt.
Und schau doch bitte noch mal über die Zeitbedingung
[?12300-07:30]
schaut ungewöhnlich aus.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

Peter_Listig

Hallo Danny,

danke für den Hinweis - bei


([?12300-07:30]


handelt es sich um einen gewöhnlichen Dreckfuhler  :)


([?23:00-07:30]


sollte es heißen.

auf Deinen Hinweis mit dem Reading bin auch gekommen und habe es eingebaut:


([?23:00-07:30] and [?ALARM_ON_OFF] eq "on" and [?DUOFERN_611CA2:moving] ne "up" and [IT_V3_1b68001] eq "OFFEN") (set   ...


damit habe ich zumindest ein eventuelles Hochfahren aus FHEM bzw. von Alexa (über Fhem-Connector) ausgeschlossen.
Das reading "moving" ändert sich sofort.

Fehlt noch der Tastendruck am Device selbst. Dabei werden die readings erst nach vollständigem
Hochfahren oder kurz nach Drücken der Stop-Taste geändert.

Die readings im Einzelnen:


Internals:
   .triggerUsed 1
   CODE       611CA2
   DEF        611CA2
   FUUID      5d5fe504-f33f-a567-db33-95fba911bc377533
   IODev      Rademacher
   LASTInputDev Rademacher
   MODEL      RolloTron Comfort Master
   MSGCNT     42
   NAME       DUOFERN_611CA2
   NR         942
   Rademacher_MSGCNT 42
   Rademacher_RAWMSG 0FFF0F218000500000004100140003611CA2FFFFFF01
   Rademacher_TIME 2020-05-28 08:01:50
   STATE      opened
   SUBTYPE    RolloTron Comfort Master
   TYPE       DUOFERN
   .attraggr:
   .attrminint:
   READINGS:
     2020-05-28 08:01:50   dawnAutomatic   off
     2020-05-28 08:01:50   duskAutomatic   off
     [i]2020-05-28 08:01:50    manualMode      on[/i]
     [b]2020-05-28 08:01:50   moving          stop[/b]
     2020-05-28 08:01:50   position        0
     2020-05-28 08:01:50   state           opened
     2020-05-28 08:01:50   sunAutomatic    off
     2020-05-28 08:01:50   sunMode         off
     2020-05-28 08:01:50   sunPosition     65
     2020-05-28 08:01:50   timeAutomatic   off
     2020-05-28 08:01:50   ventilatingMode off
     2020-05-28 08:01:50   ventilatingPosition 80
     2020-05-28 08:01:50   version         1.4
   helper:
Attributes:
   IODev      Rademacher
   alexaName  Toilettenrollo
   alias      WC_611CA2
   genericDeviceType blind
   group      Duofern
   icon       fts_shutter_90
   room       ROLLADEN


Nachdem das reading    moving  einen Teilerfolg gebracht hat
versuche ich nun  das Reading  manualMode mit einzubeziehen.

Gruß und Danke

Peter
Raspi4 / Debian Bullseye / FB 7490 / FHEM 6.x / CUL433 / CUL868 / aculfw / FrtizFon / DECT200 / IT / Homematic / ZigBee (Raspbee) /  Rademacher / HE / km200  / DS214+

moskito

ZitatFehlt noch der Tastendruck am Device selbst. Dabei werden die readings erst nach vollständigem
Hochfahren oder kurz nach Drücken der Stop-Taste geändert.
Ärgerlich.
Evtl. könnte man für diesen Fall eine Zeitverzögerung für die Meldung einbauen, um die Readingänderungen bei manueller Fahrt noch zu berücksichtigen, falls das mit "manualMode" nicht funktioniert. Geht aber dann schon wieder zu Lasten der Sicherheit.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

amenomade

Vielleicht ändert sich etwas seitens IODev Rademacher?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus