neues Modul DOIF

[Brockmann]

http://forum.fhem.de/index.php/topic,23833.msg228951.html#msg228951
Vielleicht kann mir noch jemand einen Tipp dazu geben, wie ich das am Besten lösen sollte.

Dein DOIF bekommt nichts von irgendwelchen Tasterdrücken mit, weil Du in den Bedingungen weder den Taster noch den Status des Lichts abfragst.
Die beiden Geschichten laufen quasi völlig nebeneinander her und streiten sich, wer nun das Licht schalten darf.
Integriere den Taster bzw. die dadurch generierten Events irgendwie in das DOIF, damit es beim Betätigen des Tasters getriggert wird und entsprechend der neuen Situation seinen Status ändern kann.

[sam50]

Da ist mit der Klammerung einiges im Argen. Versuche es mal so (ungetestet):

Code Auswählen Erweitern


define Jahreszeit_st DOIF ([{sunrise()}] and myAverage("43200", "FileLog_Aussen_Temp", "4:::") < 12)(set Jahreszeit Winter)


FUNKTIONIERT !!!!!!
Vielen Dank für die Unterstützung. Manchmal ist weniger einfach mehr (Besser). Das mit den Klammern habe ich noch nicht so ganz kapiert. werd es schon noch lernen.

[moonsorrox]

Vielleicht kann mir noch jemand einen Tipp dazu geben, wie ich das am Besten lösen sollte.

ein wenig verstehe ich schon vom DOIF, aber mir fällt auf das du dein(e) Taster nicht mit abfragst... frage mich jetzt nicht wo die rein müssen... das kann dir Damian sicher besser erklären

EDITH:// oops, da war schon jemand schneller... @Brockmann 

[Spartacus]

Dein DOIF bekommt nichts von irgendwelchen Tasterdrücken mit, weil Du in den Bedingungen weder den Taster noch den Status des Lichts abfragst.
Die beiden Geschichten laufen quasi völlig nebeneinander her und streiten sich, wer nun das Licht schalten darf.
Integriere den Taster bzw. die dadurch generierten Events irgendwie in das DOIF, damit es beim Betätigen des Tasters getriggert wird und entsprechend der neuen Situation seinen Status ändern kann.

Hallo Brockmann,
das mit der "Unabhängigkeit" ist mir schon klar!  Das "irgendwie integrieren" ist das, woran ich scheitere, da ich die Sequence habe und ein Tastendruck für zwei Funktionen benutzt wird. Mit dem "toggle" ist das in der Sequence recht einfach,  wird aber in der Form im DOIF nicht gehen!
Ich denke, ich kann hier nur den Aktor-Zustand abfragen und im DOIF verwursten, habe dann aber wieder das Problem der Verriegelung! Denn der Taster hat Priorität.... Ggf. muss man in der Sequence sich ein Hilfsdummy setzten, welches man im DOIF dann auswertet, aber genau da fehlt mir der Wegweiser, der zum Ziel führen könnte!

Christian

[Brockmann]

Ggf. muss man in der Sequence sich ein Hilfsdummy setzten, welches man im DOIF dann auswertet, aber genau da fehlt mir der Wegweiser, der zum Ziel führen könnte!

Wenn ich es richtig verstehe, soll der Taster das DOIF in jeder Situation "überstimmen"?
Würde es dann nicht ausreichen, die Konditionen jeweils um eine Abfrage des Lichtstatus zu erweitern? Also das Licht nur einschalten, wenn es nicht schon eingeschaltet ist und nur ausschalten, wenn es nicht schon ausgeschaltet ist. Zumindest die beiden von Dir beschriebenen "Fehler-Situationen" sollten sich dadurch auflösen lassen. Und generell erreichst Du damit, dass das DOIF mitbekommt, wenn sich extern an der "Lichtsituation" etwas verändert und darauf reagieren kann.

Ob das jetzt für alle Eventualitäten in Deinem Szenario ausreicht, weiß ich nicht. Aber den Sonderfall Silvester kannst Du ja bald testen. 

[Spartacus]

Wenn ich es richtig verstehe, soll der Taster das DOIF in jeder Situation "überstimmen"?
Würde es dann nicht ausreichen, die Konditionen jeweils um eine Abfrage des Lichtstatus zu erweitern? Also das Licht nur einschalten, wenn es nicht schon eingeschaltet ist und nur ausschalten, wenn es nicht schon ausgeschaltet ist. Zumindest die beiden von Dir beschriebenen "Fehler-Situationen" sollten sich dadurch auflösen lassen. Und generell erreichst Du damit, dass das DOIF mitbekommt, wenn sich extern an der "Lichtsituation" etwas verändert und darauf reagieren kann.

Ob das jetzt für alle Eventualitäten in Deinem Szenario ausreicht, weiß ich nicht. Aber den Sonderfall Silvester kannst Du ja bald testen. 

Hallo Brockmann,
ja! Das könnte funktionieren! Ich bin noch mal in mich gegangen und habe sowieso noch Fehler entdeckt. Das Licht soll ja nicht Silvester um 0:00 Uhr angehen, sondern Neujahr! (frage mich derzeit nur, ob der Kalender um exakt 0:00 Uhr den neuen Feiertag schon kennt, oder ob es besser ist hier Silvester und 24:00-02:00 Uhr zu verwenden, oder den 01.01. abzufragen)

Außerdem soll das Licht ja ausgehen, wenn LS und Tür im Leerlauf sind und nicht entweder/oder! Das macht m-E. keinen Sinn.

Dann sollte das m.E. so aussehen:

Code Auswählen Erweitern

  (((<Haustür offen> or <LS betätigt>) and <dunkel>) or ([0:00 - 02:00] and <Neujahr>)) and <Licht off>
  (set Licht on)
  DOELSEIF
  (<Haustür zu> and <LS Leerlauf> and <Licht on> and nicht (<Neujahr> and [00:00 - 02:00]))
  (set Licht off)

was meinst Du?
Christian

[Brockmann]

was meinst Du?

Ist etwas schwierig, solchen "Pseudo-Code" zu beurteilen. Dann lieber richtigen.

Was Du beachten solltest:
In der Kondition zum verzögerten Ausschalten darf die Bedingung <Licht on> nicht triggernd sein. Sonst würde das Licht auch bei Tasterbetätigung vermutlich einfach nach der wait-Zeit wieder ausgehen (zumindest wenn die anderen Readings ihren Zustand ("released") solange behalten, bis sich da wieder was ändert.
Wenn Du das Licht während der Ausschaltverzögerung manuell ausschalten willst, solltest Du noch ein DOELSE ans Ende hängen, damit das DOIF seinen Zustand ändern und den Timer abbrechen kann, wenn das Licht manuell ausgeschaltet wird.

[Reinerlein]

Hallo Damian,

ich wollte mal fragen, ob die Zugriffsmöglichkeit auf den Timestamp eines Readings schon in Reichweite ist.

Ich würde den gerne in Abfragen mit einbeziehen, bzw. als alleinige Bezugsgröße verwenden, z.B.:
15 Minuten nach dem letzten Auftreten eines Bewegungs-Ereignisses meines PIR soll die Aussenbeleuchtung leicht gedimmt noch angeschaltet bleiben.
So in der Art könnte ich mir einige Bedinungen vorstellen. Dafür ist (zumindest in meinem Konstrukt) die Verwendung des Wait-Timers nicht passend, da dort noch einige andere Bedingungen geprüft werden, um andere Dinge mit dem Licht zu machen...

Danke schon mal für deine Antwort...

Grüße
Reinerlein

[Damian]

Hallo Damian,

ich wollte mal fragen, ob die Zugriffsmöglichkeit auf den Timestamp eines Readings schon in Reichweite ist.

Ich würde den gerne in Abfragen mit einbeziehen, bzw. als alleinige Bezugsgröße verwenden, z.B.:
15 Minuten nach dem letzten Auftreten eines Bewegungs-Ereignisses meines PIR soll die Aussenbeleuchtung leicht gedimmt noch angeschaltet bleiben.
So in der Art könnte ich mir einige Bedinungen vorstellen. Dafür ist (zumindest in meinem Konstrukt) die Verwendung des Wait-Timers nicht passend, da dort noch einige andere Bedingungen geprüft werden, um andere Dinge mit dem Licht zu machen...

Danke schon mal für deine Antwort...

Grüße
Reinerlein

Das kannst du bereits mit Hilfe einer Perlfunktion nutzen:

siehe: http://forum.fhem.de/index.php/topic,23833.msg226744.html#msg226744

Gruß

Damian

[Reinerlein]

Hi Damian,

ja, so habe ich es auch umgesetzt. Ich finde nur diese Schreibweise etwas "unelegant" bzw. in meinem großen Konstrukt unübersichtlich, und ich dachte irgendwo gelesen zu haben, dass du da bei Gelegenheit etwas zum Rest passenderes bauen wolltest...

Trotzdem Danke für den Hinweis...

Grüße
Reinerlein

[Damian]

Hi Damian,

ja, so habe ich es auch umgesetzt. Ich finde nur diese Schreibweise etwas "unelegant" bzw. in meinem großen Konstrukt unübersichtlich, und ich dachte irgendwo gelesen zu haben, dass du da bei Gelegenheit etwas zum Rest passenderes bauen wolltest...

Trotzdem Danke für den Hinweis...

Grüße
Reinerlein

Mal schauen, ich kann ja

Code Auswählen Erweitern

[<device>:<reading>:sec] für Zeit in Sekunden seit der letzten Änderung des Readings auf die immer länger werdende todo-Liste setzen (diese aktualisiere ich im ersten Post des Threads).

Gruß

Damian

[Spartacus]

Hallo,
ich brauche nochmals Unterstützung. Weiß gerade nicht, wie ich das umsetzten soll!

Ich habe einen Taster, den ich so abfrage:

Code Auswählen Erweitern

define sKurzerLangerDruck_UR sequence PTM210.Gira.01:BI 0.5 PTM210.Gira.01:buttons:.released
attr sKurzerLangerDruck_UR disable 0
attr sKurzerLangerDruck_UR room 99-Test
attr sKurzerLangerDruck_UR triggerPartial 1
#
define nKurzerDruck_UR notify sKurzerLangerDruck_UR:trigger \
{ \
if (ReadingsVal ("Eingangslicht.dum", "state",0) eq"on")\
{\
  fhem("set Eingangslicht.dum off")\
}\
else\
{\
  fhem("set Eingangslicht.dum on")\
}\
}


Jetzt möchte ich im DOIF auf dieses Notify reagieren:

Code Auswählen Erweitern

sKurzerLangerDruck_UR:trigger
Also jedes mal, wenn dieses Event ausgelöst wird.
Irgendwie so:

Code Auswählen Erweitern

define diEingangsLicht DOIF (([EG.ss.TK.Haustuer:buttons] eq "pressed" or [EG.ss.LS.Eingang:buttons] eq "pressed") or [sKurzerLangerDruck_UR:trigger])   
Geht aber nicht, da "sKurzerLangerDruck_UR:trigger" ein event ist und kein Reading.
Jemand eine Idee, wie ich den Knoten aus dem Kopf kriege?

Danke,
Christian

[Spartacus]

....komme der Sache offenbar nicht näher,
Wird das Licht über Haustür oder LS eingeschaltet, kann ich es nicht direkt über den Schalter wieder ausschalten, da Eingangslicht.dum ja auf "off" bleibt. Irgendwie brauche ich noch einen weiteren Zustand, den ich mir merken muss, aber wie!?

Code Auswählen Erweitern

(([EG.ss.TK.Haustuer:buttons] eq "pressed" or [EG.ss.LS.Eingang:buttons] eq "pressed") or
([PTM210.Gira.01:buttons] eq "pressed" and [Eingangslicht.dum] eq "off"))
(set Aktor on)
DOELSEIF
([EG.ss.TK.Haustuer:buttons] eq "released" and [EG.ss.LS.Eingang:buttons] eq "released" and [Eingangslicht.dum] eq "off")
(set Aktor off)
DOELSEIF
([PTM210.Gira.01:buttons] eq "pressed" and [Eingangslicht.dum] eq "on")
(set Aktor off)
#
#
#
attr wait 0:10:0
Spartacus

NACHTRAG:
Nachdem ich nun alle möglichen Varianten ausprobiert habe, und immer noch kein Stück weiter bin kann hoffentlich jemand helfen! Deshalb schreibe ich hier noch einmal auf, was am Ende überhaupt dabei herauskommen soll:

Sensoren:
Lichtschranke:pressed=betätigt, released=Leerlauf
ReedKontakt: pressend=Tür auf; released=Tür zu
Taster: sequence partial_1, alternativ Trigger
Notaus:
Neujahr:

Aktoren:
Eingangsleuchte

- Reedkontakt oder Lichtschranke schalten den Aktor (pressed: ein; released: wait 120, dann aus)
- Notaus schaltet den Aktor ab, wenn Reedkontakt oder Lichschranke (pressed) 600s anliegen.
- Neujahr [00:00-02:00] schaltet den Aktor ein, unabhängig vom Zustand des Reedkontaktes oder der Lichtschranke
- Taster ist Trumpf, d.h. er kann den Timer abbrechen und den Aktor direkt abschalten, schaltet den Aktor direkt ein,
  jeweils unabhängig vom Zustand des Reedkontaktes, der Lichtschranke, Neujahr oder Notaus

Mein Problem ist eigentlich der Toggle-Taster, der auch noch eine Doppelfunktion hat (Sequence mit trigger und partial_1).
Ich kann den korrekten Zustand nicht bestimmen, wenn der Aktor beispielsweise durch die Lichtschranke aktiviert wurde.

Vielen Dank,
Christian

[Brockmann]

Ich kann den korrekten Zustand nicht bestimmen, wenn der Aktor beispielsweise durch die Lichtschranke aktiviert wurde.

Ich verstehe nicht, wozu Du [Eingangslicht.dum] brauchst. Prüfe doch einfach direkt den Status des Aktors. Dann hast Du auch immer den korrekte Zustand.

[Spartacus]

Hallo,
ich brauche doch irgendeinen Merker für den Taster, da er doch alle anderen Sensoren sticht!
Solange dieser Taster auf "ein" steht, ist der Aktor auf jeden Fall an, wenn er erneut getippt wird, ist auf jeden Fall der Aktor "aus". Das muss ich doch mit dem Dummy machen....zumindest habe ich keine Idee, wie das anders laufen könnte!

Christian