Hauptmenü

neues Modul DOIF

Begonnen von Damian, 21 Mai 2014, 15:53:18

Vorheriges Thema - Nächstes Thema

Damian

Zitat von: det. am 21 August 2014, 22:18:26
Hallo Damian,
vielen Dank für das sehr nützliche Modul. Hat gleich ein paar Altlasten (notify für WW-Zirkulation und Helligkeits- und zeitgesteuerte Außenbeleuchtung ersetzt). Ein kleines Problem habe ich noch - und vielleicht nur zu dumm gewesen, das in Deinem sehr ausführlichen commandref Artikel zu finden: Ich möchte einen Aktor nach 5min wieder ausschalten und der beherrscht kein on-for-timer 300.

So etwas hatten wir schon mal. Die Nachbildung eines on-for-timers lässt sich mit zwei DOIF´s und einem Dummy realisieren.

define schalter_d dummy

define di_Schalter DOIF ([Bewegungsmelder] eq "motion" )  (set schalter_d on, set schalter_d off)
attr di_Schalter do always

define di_Licht DOIF ([schalter_d] eq "on")  (set Licht on) DOELSE  (set Licht off)
attr di_Licht wait 0:300


Hiermit wird das Licht bei Bewegung eingeschaltet. Dabei wird, solange es brennt, bei jeder Bewegung die Ausschaltzeit auf 5 Minuten neugesetzt, "set Licht on" wird dabei nicht unnötig wiederholt.

Gruß

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

RoBra81

Hallo,

ich tüftele gerade an einer Aufgabenstellung und frage mich, ob (und wie) ich dafür DOIF einsetzen kann:

Ich habe einen Dummy für Alarm mit den Zuständen deaktiviert, aktiviert, traege und ausgelöst. Die Umschaltung zwischen deaktiviert, aktiviert und traege erfolgt über Taster an der Wand. Wenn der Alarm aktiviert ist, soll er sobald ein Bewegungsmelder auslöst auf ausgelöst wechseln. Soweit bekomme ich das hin. Nun zur DOIF-Frage: Wenn der Alarm in der Status ausgelöst wechselt, soll eine Aktion ausgeführt werden (auch das bekomme ich noch hin) und außerdem soll ab diesem Zeitpunkt zyklisch (30 Sekunden) geprüft werden, ob der Status noch immer ausgelöst ist und in diesem Fall die Aktion wiederholt werden (bei diesem zyklischen Teil bin ich mir nicht sicher, ob und wie DOIF das ohne at könnte). Der Wechsel aus dem Zustand ausgelöst erfolgt wieder per Wandtaster...

Geht das mit DOIF?

Vielen Dank
Ronny

Brockmann

Zitat von: RoBra81 am 22 August 2014, 10:59:58
Geht das mit DOIF?
Man kann mit DOIF (fast) alles machen. Das heißt aber nicht, dass man alles mit DOIF machen muss oder sollte (IMHO).

So ein alle 30-Sekunden-Task lässt sich mit einem simplen AT sehr einfach lösen.
Du könntest das AT fest definieren, aber standardmäßig mit dem Attribut disabled 1 versehen.
Wenn der Alarm ausgelöst wird, entfernt ein DOIF dieses Attribut und das AT führt alle 30 Sekunden seine Aktion durch.
Wenn der Alarm per Wandtaster aufgehoben wird, setzt ein (oder sogar dasselbe?) DOIF das Attribut wieder und das AT geht schlafen.

Das scheint mir die naheliegendste und geradlinigste Lösung zu sein.
Aber man kann das sicher auch mit zwei DOIFs und einem Dummy hinbekommen, vielleicht analog zu der Bewegungsmelder-Lösung von etwas weiter oben.

RoBra81

Da bevorzuge ich die AT-Lösung. Es hätte ja sein können, dass DOIF selbst auch soetwas zyklisches kann, aber einer Lösung mit zwei DOIFs und einem Dummy ziehe ich dann doch ein AT vor..

Vielen Dank

RoBra81

Hallo,

kann mir noch jemand einen Tipp geben, wie ich einen langen Tastendruck als Bedingung formulieren kann? Ich habe ein HMW_IO_12_Sw7_DR_JEQ0497826 mit den Readings press_long und press_short. Beim Betätigen des Tasters gibt es die Events press_long und press_short, aber wie muss ich es Formulieren, damit der die entsprechende Aktion im DOIF ausgelöst wird?

Danke
Ronny

Brockmann

Zitat von: RoBra81 am 22 August 2014, 13:04:54
kann mir noch jemand einen Tipp geben, wie ich einen langen Tastendruck als Bedingung formulieren kann? Ich habe ein HMW_IO_12_Sw7_DR_JEQ0497826 mit den Readings press_long und press_short. Beim Betätigen des Tasters gibt es die Events press_long und press_short, aber wie muss ich es Formulieren, damit der die entsprechende Aktion im DOIF ausgelöst wird?
Wie sehen die Events bei press_long bzw. press_short denn genau aus? Drück doch mal beides und poste dann hier das Protokoll aus dem Event-Monitor.

RoBra81

Jeweils zwei mal gedrückt:

2014-08-22 13:41:38 HM485 OG.ez.WS.Ku_Tuer_1 press_short: press_short 14
2014-08-22 13:41:44 HM485 OG.ez.WS.Ku_Tuer_1 press_short: press_short 15
2014-08-22 13:41:46 HM485 OG.ez.WS.Ku_Tuer_1 press_long: press_long 16
2014-08-22 13:41:51 HM485 OG.ez.WS.Ku_Tuer_1 press_long: press_long 17

Brockmann

Zitat von: RoBra81 am 22 August 2014, 13:43:27
Jeweils zwei mal gedrückt:

2014-08-22 13:41:38 HM485 OG.ez.WS.Ku_Tuer_1 press_short: press_short 14
2014-08-22 13:41:44 HM485 OG.ez.WS.Ku_Tuer_1 press_short: press_short 15
2014-08-22 13:41:46 HM485 OG.ez.WS.Ku_Tuer_1 press_long: press_long 16
2014-08-22 13:41:51 HM485 OG.ez.WS.Ku_Tuer_1 press_long: press_long 17

Hmm, ich bin mir nicht sicher, was es mit den Zahlen jeweils am Ende auf sich hat. Zählen die einfach immer hoch?
Sollte aber auch egal sein. Im Prinzip müsste einfach ein
([OG.ez.WS.Ku_Tuer1:press_short])
in Verbindung mit attr do always reichen.
Das reagiert auf jedes Ereignis mit diesem Reading.
(Das ist für DOIF jetzt aber völlig off-topic. Ggf. gehts im Homematic-Forum weiter, falls es so noch nicht klappt.)

RoBra81

Hallo,

vielen Dank, dass du versuchst, mir zu helfen. Ich finde das nicht OffTopic für DOIF: Um mit dem Taster ein notify zu Triggern habe ich schon seit längerem eine funktionierende Schreibweise:

define TaserNot notify OG.ez.WS.Durchgang_1.*press_long.* ...

Leider schaffe ich es nicht, eine solche für DOIF zu finden. Ich habe es mal nach deinem Vorschlag probiert:

([OG.ez.WS.Durchgang_1:press_long])

Da ich zu Zeit nicht zu Hause bin, mach ich meine Test mit dem trigger-Befehl: Wenn ich

trigger OG.ez.WS.Durchgang_1 press_long

auslöse, reagiert das DOIF.  :)

Löse ich

trigger OG.ez.WS.Durchgang_1 dsfdsfdsfds

aus, reagiert das DOIF auch.  :(

Löse ich

trigger OG.ez.WS.Durchgang_1 press_long: press_long 55

aus, so sieht das Event so aus wie beim Tastendruck, es passiert jedoch nix im DOIF  :( :(

EDIT: Letzteres löst das notify übrigens korrekt aus...

Brockmann

Zitat von: RoBra81 am 22 August 2014, 14:29:09
: Um mit dem Taster ein notify zu Triggern habe ich schon seit längerem eine funktionierende Schreibweise:
define TaserNot notify OG.ez.WS.Durchgang_1.*press_long.* ...
Diese Definition ist leider nicht eindeutig. Die kann darauf reagieren, dass der Status des Geräts den Wert press_long irgendwas annimmt oder dass das Reading press_long des Geräts auf irgendwas gesetzt wird. Deshalb kann man (bzw. ich jedenfalls) daraus nicht einfach so eine passende DOIF-Bedingung ableiten. Anders gesagt: Das Notify reagiert einfach auf jedes Event, beim dem auf die Zeichenkette "ez.WS.Durchgang_1" die Zeichenkette "press_long" folgt.
Bei DOIF musst man aber konkret angeben, ob nun der Gerätestatus oder ein Reading des Geräts den Trigger liefern sollen.

Mein Verständnis nach Deinen Schilderungen war, dass das Reading press_long bei einem entsprechenden Kontakt auf den Wert press_long <#fortlaufende Nummer> gesetzt wird und diesen Wert solange behält, bis ein erneuter Kontakt erfolgt. Anscheinend ist das aber nicht so oder zumindest kann ich das von Dir beschriebenen Verhalten auf die verschiedenen trigger-Tests nicht nachvollziehen und halte mich deshalb mit weiteren Mutmaßungen zurück.

Aber nochmal der Hinweis: Wenn Du nicht rausbekommst, wann bei diesem Gerät welche Werte wie gesetzt werden, frag doch mal im Homematic-Forum nach, da kann man Dir bei diesem Problem vermutlich besser helfen.

Damian

Zitat von: RoBra81 am 22 August 2014, 14:29:09
([OG.ez.WS.Durchgang_1:press_long])

wird so nicht funktionieren, dann eher:

([OG.ez.WS.Durchgang_1] =~/long/)

Gruß

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

Invers

Einen Hinweis und eine Frage hätte ich.
Hinweis:
Wenn ich die Definition define DI_Test DOIF ins Frontend eingebe, kann ich nicht mehr konfigurieren. Ich muss das DOIF löschen und korrekt definieren.

Jetzt die Frage:
Ich habe eine Anwesenheitsprüfung (BinIchDa), die absent und present liefert.
Wenn ich ins Frontend eingebe BinIchDa setstate absent, dann funktioniert das tadellos.
Definiere ich aber folgendes DOIF, geht es nicht.
define DI_Anwesend DOIF ([Schloss] eq "locked" and [BinIchDa] eq "present") (BinIchDa setstate absent)

Die Fehlermeldung lautet:
BinIchDa setstate absent: Unknown command BinIchDa, try help.

Warum geht das so nicht?
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

ph1959de

Bist Du sicher, dass Du da wirklich beide male den gleichen Befehl verwendet hast?

Die "offizielle" Syntax lautet doch setstate <devspec> <value> während Du behauptest(?) im WebInterface (damit meinst Du das Befehls-Eingabefeld(?)) würde <devspec> setstate <value> funktionieren?
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Invers

Oh, du hast Recht. Ich könnte aber wirklich schwören, dass es gestern Nacht so funktioniert hat. Ich hab auch noch extra mehrmals nachgesehen. Nur die Commandref hatte ich nicht noch einmal befragt, da es ja in meinen Augen funktioniert hatte. Eine Stunde hatte ich rumprobiert. Ich sollte vielleicht so spät nachts nichts mehr machen.
Vielen Dank und sorry.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Damian

#419
Zitat von: Invers am 27 August 2014, 01:45:56
Einen Hinweis und eine Frage hätte ich.
Hinweis:
Wenn ich die Definition define DI_Test DOIF ins Frontend eingebe, kann ich nicht mehr konfigurieren. Ich muss das DOIF löschen und korrekt definieren.

Mit der aktuellen Version ist:
define DI_Test DOIF
durchaus eine sinnvolle Eingabe, wenn man das Modul nur für Statusanzeige nutzen will (siehe dazu Beispiele in der Commandref).

Wenn man im DEF-Editor DOIF ergänzen möchte (was ebenfalls sinnvoll ist), dann muss man mindestens die erste Bedingung mit einem Device oder Zeit angeben, also:

define DI_Test DOIF ([Schloss])

Danach kann man auf den DEF-Button klicken und die Eingaben ergänzen.

Das gilt für die eingecheckte Version.

Gruß

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