neues Modul DOIF

[Brockmann]

Kann ich über z.B. DOIF regeln, daß ab einer bestimmten CPU-Temperatur das Relais einschaltet (Piface 1 auf 1) und bei einer anderenm wieder ausschaltet (Piface 1 auf 0)?
Das Schalten des Relais würde ich wohl hinbekommen denke ich, aber wie (bzw. woher) kann ich die Temperatur auslesen und dann einbinden?

Jein. Du könntest zwar im DOIF über die Funktion RpiTemp("") auf die Temperatur zugreifen und Vergleichen. Aber da das eine Funktion und kein Gerät ist, würde dieses Bedingung das DOIF niemals auslösen. (Die Funktion erzeugt keine regelmäßigen Events, sondern antwortet eben nur, wenn Sie gefragt wird.)
Du könntest aber die Temperatur regelmäßig in einen Dummy schreiben (ich zitiere mal aus dem Wiki):

Code Auswählen Erweitern

define <name_at> at +*00:05 { fhem("set <name> ".RpiTemp("")) }
Das schreibt alle fünf Minuten die aktuelle Temperatur in <name>. Diesen Dummy könntest Du dann wiederum im DOIF als Bedingung einsetzen, also

Code Auswählen Erweitern

DOIF ([<name>] > 55)(set Luefter an) DOELSE (set Luefter off)

[Damian]

Jein. Du könntest zwar im DOIF über die Funktion RpiTemp("") auf die Temperatur zugreifen und Vergleichen. Aber da das eine Funktion und kein Gerät ist, würde dieses Bedingung das DOIF niemals auslösen. (Die Funktion erzeugt keine regelmäßigen Events, sondern antwortet eben nur, wenn Sie gefragt wird.)
Du könntest aber die Temperatur regelmäßig in einen Dummy schreiben (ich zitiere mal aus dem Wiki):

Code Auswählen Erweitern

define <name_at> at +*00:05 { fhem("set <name> ".RpiTemp("")) }
Das schreibt alle fünf Minuten die aktuelle Temperatur in <name>. Diesen Dummy könntest Du dann wiederum im DOIF als Bedingung einsetzen, also

Code Auswählen Erweitern

DOIF ([<name>] > 55)(set Luefter an) DOELSE (set Luefter off)

Vieleicht baue ich irgendwann mal die bereits am Anfang geplante Selbsttriggerung noch ein.

Gruß

Damian

[bamm-bamm]

Danke für die Info. Leider klappt das bei mir nicht. Es erfolgt kein Schalten. Hier mal der Auszug aus der CFG:

define Rasptemp dummy
attr Rasptemp room RPi
define Rasptemp_log FileLog ./log/Rasptemp-%Y-%m.log Rasptemp
attr Rasptemp_log room RPi
define Rasptemp_at at +*00:05 { fhem("set Rasptemp ".RpiTemp("")) }
define Raspberry_Luefter DOIF ([Rasptemp]>51)(set piface 1 1) DOELSE (set piface 1 0)

Hab ich da irgendwo nen Denkfehler?

[Damian]

Danke für die Info. Leider klappt das bei mir nicht. Es erfolgt kein Schalten. Hier mal der Auszug aus der CFG:

define Rasptemp dummy
attr Rasptemp room RPi
define Rasptemp_log FileLog ./log/Rasptemp-%Y-%m.log Rasptemp
attr Rasptemp_log room RPi
define Rasptemp_at at +*00:05 { fhem("set Rasptemp ".RpiTemp("")) }
define Raspberry_Luefter DOIF ([Rasptemp]>51)(set piface 1 1) DOELSE (set piface 1 0)

Hab ich da irgendwo nen Denkfehler?

Poste hier Ausgabe von 'list Raspberry_Luefter'

Gruß
Damian

[bamm-bamm]

---schnipp----

Internals:
   CFGFN
   DEF        ([Rasptemp]>51)(set piface 1 1) DOELSE (set piface 1 0)
   NAME       Raspberry_Luefter
   NR         215
   NTFY_ORDER 50-Raspberry_Luefter
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2014-09-07 15:38:15   cmd_event       Rasptemp
     2014-09-07 15:38:15   cmd_nr          2
     2014-09-07 15:38:15   e_Rasptemp_STATE T: 53.53
     2014-09-07 15:38:15   state           cmd_2
   Condition:
     0          InternalDoIf('Rasptemp','STATE','')>51
   Devices:
     0           Rasptemp
     all         Rasptemp
   Do:
     0          set piface 1 1
     1          set piface 1 0
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           Rasptemp:STATE
     all         Rasptemp:STATE
   Readings:
   State:
Attributes:

----schnapp----

Da wohl T: xx.xx ausgelesen wird, hatte ich in DOIF schon mit Parameter":d"  und als Grenzwert 51.00 probiert. Beides jedoch ohne Erfolg.

[Damian]

---schnipp----

Internals:
   CFGFN
   DEF        ([Rasptemp]>51)(set piface 1 1) DOELSE (set piface 1 0)
   NAME       Raspberry_Luefter
   NR         215
   NTFY_ORDER 50-Raspberry_Luefter
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2014-09-07 15:38:15   cmd_event       Rasptemp
     2014-09-07 15:38:15   cmd_nr          2
     2014-09-07 15:38:15   e_Rasptemp_STATE T: 53.53
     2014-09-07 15:38:15   state           cmd_2
   Condition:
     0          InternalDoIf('Rasptemp','STATE','')>51
   Devices:
     0           Rasptemp
     all         Rasptemp
   Do:
     0          set piface 1 1
     1          set piface 1 0
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           Rasptemp:STATE
     all         Rasptemp:STATE
   Readings:
   State:
Attributes:

----schnapp----

Da wohl T: xx.xx ausgelesen wird, hatte ich in DOIF schon mit Parameter":d"  und als Grenzwert 51.00 probiert. Beides jedoch ohne Erfolg.

Es wurde das zweite Kommando ausgeführt. Jetzt muss du im Log schauen, warum um 15:38:15 set piface 1 0 nicht erfolgreich war.
Gruß
Damian

[Damian]

Ich plane folgende Erweiterungen des Moduls:

1) Regelmäßige Triggerung [+HH:MM] oder [+HH:MM:SS] oder [+{perl-func}]

Die Angaben sind natürlich wie Zeiten beliebig mit anderen Operatoren kombinierbar:

DOIF ([+00:05] and fhem("get modul reading")>100) (set ...)

Bedeutung: alle 5 Minuten wird reading ausgewertet, dessen Modul keine Ereignisse erzeugt

2) Wiederholung alle X-Sekunden zulassen

Beispiel für Benachrichtigung:

define di_hohe_feuchtigkeit DOIF ([bad:humidity]>70) (set tablet ttsSay Bitte im Badezimmer lüften.)
attr di_hohe_feuchtigkeit wait 300
attr di_hohe_feuchtigkeit do 600

Bedeutung: 10 Minuten (600 Sekunden) nach der Benachrichtigung wird das letzte Kommando zurückgesetzt. Damit wird eine erneute Benachrichtigung nach dieser Zeitspanne, falls ein Ereignis kommt und die Bedingung noch zutrifft, wiederholt.

Alternativ kann auch die Anzahl der Wiederholungen begrenzt werden:

attr di_hohe_feuchtigkeit do 3x600

Hiermit wird das Zurücksetzen bis zu drei mal wiederholt.

Die Angaben können für jeden DO-Fall mit Doppelpunkt, wie beim wait-Attribut, angegeben werden werden:

attr di_benachrichtigung do 3x600:0

Bei Anregungen zu diesen Erweiterungen, bitte hier posten.

Gruß

Damian

[Brockmann]

Diese Erweiterungen für DOIF hören sich sehr gut an.

Die Angaben können für jeden DO-Fall mit Doppelpunkt, wie beim wait-Attribut, angegeben werden werden:
attr di_benachrichtigung do 3x600:0

Was vielleicht noch eine sinnvolle Ergänzung wäre (und mit den geplanten Erweiterungen so noch nicht möglich wäre, oder?): Eine "globale" DO-Vorgabe, in welchem zeitlichen Abstand das DOIF ausgeführt werden soll, unabhängig davon, durch welchen DO-Fall es getriggert wurde.

Praxisbeispiel: Ich habe ein DOIF, das Wetterdaten an ein Tablet zur Darstellung in einem Widget übermittelt. Das DOIF wird verschieden getriggert (Wettersensor innen, Wettersensor außen), soll das Widget aber höchstens alle 30 Minuten aktualisieren. Jetzt könnte ich zwar beide DO-Fälle mit do 1800:1800 begrenzen, aber wenn die Sensoren immer schön abwechselnd melden, würden diese Vorgaben quasi ignoriert, oder?
Da würde ich mir sowas wie do @1800 wünschen, was das DOIF insgesamt quasi für 30 Minuten disabled und dann wieder enabled.

Wie immer nur als Anregung gedacht... 

[bamm-bamm]

Leider hatte ich mein Log da noch zu klein (verbose). Ist jetzt behoben. Aber "cmd_2" wäre auch falsch, da bei Temperatur über 51 cmd_1 hätte ausgeführt werden müssen. Also doch eher ein Problem beim Auslesen des Temperaturwertes?

aktuell:

Internals:
   CFGFN
   DEF        ([Rasptemp]>51)(set piface 1 1) DOELSE (set piface 1 0)
   NAME       Raspberry_Luefter
   NR         215
   NTFY_ORDER 50-Raspberry_Luefter
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2014-09-08 09:27:39   cmd_event       Rasptemp
     2014-09-08 09:27:39   cmd_nr          2
     2014-09-08 09:27:39   e_Rasptemp_STATE T: 53.00
     2014-09-08 09:27:39   state           cmd_2
   Condition:
     0          InternalDoIf('Rasptemp','STATE','')>51
   Devices:
     0           Rasptemp
     all         Rasptemp
   Do:
     0          set piface 1 1
     1          set piface 1 0
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           Rasptemp:STATE
     all         Rasptemp:STATE
   Readings:
   State:
Attributes:

------

2014.09.08 09:27:38 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0101928 d:26EE12 O:26EC0A t:133300C3 IDcnt:0008
2014.09.08 09:27:39 5: exec at command Rasptemp_at
2014.09.08 09:27:39 5: Cmd: >{ fhem("set Rasptemp ".RpiTemp("")) }<
2014.09.08 09:27:39 5: Cmd: >set Rasptemp T: 53.00<
2014.09.08 09:27:39 4: dummy set Rasptemp T: 53.00
2014.09.08 09:27:39 5: Triggering Rasptemp (1 changes)
2014.09.08 09:27:39 5: Notify loop for Rasptemp T: 53.00
2014.09.08 09:27:39 5: Cmd: >set piface 1 0<
2014.09.08 09:27:39 3: PIFACE piface set port 1 0
2014.09.08 09:27:39 5: Triggering piface (1 changes)
2014.09.08 09:27:39 5: Notify loop for piface out1: 0
2014.09.08 09:27:39 4: eventTypes: PIFACE piface out1: 0 -> out1: .*
2014.09.08 09:27:39 5: Triggering Raspberry_Luefter (3 changes)
2014.09.08 09:27:39 5: Notify loop for Raspberry_Luefter cmd_nr: 2
2014.09.08 09:27:39 4: eventTypes: DOIF Raspberry_Luefter cmd_nr: 2 -> cmd_nr: .*
2014.09.08 09:27:39 4: eventTypes: DOIF Raspberry_Luefter cmd_event: Rasptemp -> cmd_event: Rasptemp
2014.09.08 09:27:39 4: eventTypes: DOIF Raspberry_Luefter cmd_2 -> cmd_2
2014.09.08 09:27:39 4: eventTypes: DOIF Raspberry_Luefter state: cmd_2 -> state: cmd_2
2014.09.08 09:27:39 4: eventTypes: dummy Rasptemp T: 53.00 -> T: .*
2014.09.08 09:27:39 4: eventTypes: dummy Rasptemp state: T: 53.00 -> state: T: .*
2014.09.08 09:27:39 5: redefine at command Rasptemp_at as +*00:05 { fhem("set Rasptemp ".RpiTemp("")) }
2014.09.08 09:27:47 5: HMLAN/RAW: /E286BA8,0000,1333248A,FF,FF97,E8865A286BA8000000A0BA41

Gruß,
Andreas

Es wurde das zweite Kommando ausgeführt. Jetzt muss du im Log schauen, warum um 15:38:15 set piface 1 0 nicht erfolgreich war.
Gruß
Damian

[Brockmann]

Leider hatte ich mein Log da noch zu klein (verbose). Ist jetzt behoben. Aber "cmd_2" wäre auch falsch, da bei Temperatur über 51 cmd_1 hätte ausgeführt werden müssen. Also doch eher ein Problem beim Auslesen des Temperaturwertes?

   DEF        ([Rasptemp]>51)(set piface 1 1) DOELSE (set piface 1 0)

Versuch doch mal  ([Rasptemp:state:d]>51)
Damit werden nur die Zahlen ausgewertet und "T:" ignoriert.

[Damian]

Diese Erweiterungen für DOIF hören sich sehr gut an.
Was vielleicht noch eine sinnvolle Ergänzung wäre (und mit den geplanten Erweiterungen so noch nicht möglich wäre, oder?): Eine "globale" DO-Vorgabe, in welchem zeitlichen Abstand das DOIF ausgeführt werden soll, unabhängig davon, durch welchen DO-Fall es getriggert wurde.

Praxisbeispiel: Ich habe ein DOIF, das Wetterdaten an ein Tablet zur Darstellung in einem Widget übermittelt. Das DOIF wird verschieden getriggert (Wettersensor innen, Wettersensor außen), soll das Widget aber höchstens alle 30 Minuten aktualisieren. Jetzt könnte ich zwar beide DO-Fälle mit do 1800:1800 begrenzen, aber wenn die Sensoren immer schön abwechselnd melden, würden diese Vorgaben quasi ignoriert, oder?
Da würde ich mir sowas wie do @1800 wünschen, was das DOIF insgesamt quasi für 30 Minuten disabled und dann wieder enabled.

Wie immer nur als Anregung gedacht... 

Auch bei 1800:1800 reagiert das Modul. Es ist also zu keinem Zeitpunkt disabled, sondern unterbindet nur Wiederholung derselben Bedingung für die angegebene Zeitdauer. Ein Zustandswechsel führt also, wie bisher, zur sofortigen Ausführung des entsprechenden (anderen) Kommandos, wenn kein wait-Attribut gesetzt ist.

Edit: Ich sehe gerade du wolltest das Gegenteil haben, lässt sich sicherlich auch einbauen.

Gruß

Damian

[bamm-bamm]

Super  - danke schön
Irgendwie hatte ich die Wiki wohl falsch verstanden und es nur mit "Rasptemp:d", also ohne "state" probiert.
Scheinbar stören auch die Nachkommastellen nicht *puu*, nach halbstündiger Beobachtung scheint der Wechsel zu klappen.

Ich hätte zwar auch einen temperaturgesteuerten Lüfter einbauen können, aber der Raspberry/Piface sollen schliesslich selbst mal was tun für den teuren Strom *gg*

Versuch doch mal  ([Rasptemp:state:d]>51)
Damit werden nur die Zahlen ausgewertet und "T:" ignoriert.

[Damian]

Super  - danke schön
Irgendwie hatte ich die Wiki wohl falsch verstanden und es nur mit "Rasptemp:d", also ohne "state" probiert.
Scheinbar stören auch die Nachkommastellen nicht *puu*, nach halbstündiger Beobachtung scheint der Wechsel zu klappen.

Ich hätte zwar auch einen temperaturgesteuerten Lüfter einbauen können, aber der Raspberry/Piface sollen schliesslich selbst mal was tun für den teuren Strom *gg*

Wenn man tatsächlich den Status filtern wollte, weil es z. B. keinen Reading "state" gäbe, dann könnte man das mit [Rasptemp:&STATE:d] erreichen.

Gruß

Damian

[Invers]

Da ich mein folgendes Problem gerne mit DOIF lösen würde, poste ich mal hier. Sollte das nicht ok sein, ziehe ich gerne zu HM um.
Ich möchte meine Küchenbeleuchtung mit dem DOIF Beispiel aus der Commandref nutzen und hab das mal nachgebaut:

Code Auswählen Erweitern

define switch_d dummy
define di_switch DOIF ([BM_Kueche] eq "motion" and  [BM_Kueche:brightness:d] <50) (set switch_d on, set switch_d off)
attr di_switch do always
define di_light DOIF ([switch_d] eq "on") (set LED_Kueche on,set MyTTS tts An.) DOELSE (set LED_Kueche off,set MyTTS tts Aus.)
attr di_light wait 0:240

Leider funktioniert es nicht wie erwartet.

Zuerst stellte ich fest, dass motion vom Bewegungsmelder auch gemeldet wurde, wenn irgendein anderer Wert sich änderte.
Das konnte ich umgehen, indem ich beim BM

Code Auswählen Erweitern

attr BM_Kueche event-on-update-reading state
gesetzt habe.
Das hat nun leider den Nachteil, dass auch nichts anderes mehr im Log erscheint. Gerne würde ich wieder die Helligkeitswerte loggen, aber das löst leider dann auch motion aus.

Leider funktioniert es trotzdem noch nicht, wie erwartet. Das Licht geht zwar brav immer bei Bewegung an, aber leider geht es immer wieder mal aus, auch dann, wenn Bewegung stattfindet.
Es hat den Anschein, als wenn eine fortlaufende Bewegung nicht registriert wird, sondern nur, wenn eine Unterbrechung stattfindet, also wenn jemand kurzzeitig den Raum verlässt und wieder rein kommt.

Kennt jemand eine Möglichkeit, die Bewegung mit einem DOIF so abzufragen, dass das Licht so lange an bleibt, bis 240 Sekunden keine Bewegung stattgefunden hat?

Das könnte man wahrscheinlich mit motioncount lösen, aber ich bekomme das nicht in das DOIF rein.

Danke im Voraus.

[Damian]

Da ich mein folgendes Problem gerne mit DOIF lösen würde, poste ich mal hier. Sollte das nicht ok sein, ziehe ich gerne zu HM um.
Ich möchte meine Küchenbeleuchtung mit dem DOIF Beispiel aus der Commandref nutzen und hab das mal nachgebaut:

Code Auswählen Erweitern

define switch_d dummy
define di_switch DOIF ([BM_Kueche] eq "motion" and  [BM_Kueche:brightness:d] <50) (set switch_d on, set switch_d off)
attr di_switch do always
define di_light DOIF ([switch_d] eq "on") (set LED_Kueche on,set MyTTS tts An.) DOELSE (set LED_Kueche off,set MyTTS tts Aus.)
attr di_light wait 0:240

Leider funktioniert es nicht wie erwartet.

Zuerst stellte ich fest, dass motion vom Bewegungsmelder auch gemeldet wurde, wenn irgendein anderer Wert sich änderte.
Das konnte ich umgehen, indem ich beim BM

Code Auswählen Erweitern

attr BM_Kueche event-on-update-reading state
gesetzt habe.
Das hat nun leider den Nachteil, dass auch nichts anderes mehr im Log erscheint. Gerne würde ich wieder die Helligkeitswerte loggen, aber das löst leider dann auch motion aus.

Leider funktioniert es trotzdem noch nicht, wie erwartet. Das Licht geht zwar brav immer bei Bewegung an, aber leider geht es immer wieder mal aus, auch dann, wenn Bewegung stattfindet.
Es hat den Anschein, als wenn eine fortlaufende Bewegung nicht registriert wird, sondern nur, wenn eine Unterbrechung stattfindet, also wenn jemand kurzzeitig den Raum verlässt und wieder rein kommt.

Kennt jemand eine Möglichkeit, die Bewegung mit einem DOIF so abzufragen, dass das Licht so lange an bleibt, bis 240 Sekunden keine Bewegung stattgefunden hat?

Das könnte man wahrscheinlich mit motioncount lösen, aber ich bekomme das nicht in das DOIF rein.

Danke im Voraus.

Ich habe diesen Bewegungsmelder nicht. Du musst erstmal ein eindeutiges Kriterium nur für Bewegung bei dem Sender herausfinden.

Wenn zyklisch Helligkeitswert ohne Bewegung gesendet wird, dann solltest du die Abfrage aus der Bedingung herausnehmen, damit DOIF die Helligkeitsveränderung nicht als Trigger ansieht:

Code Auswählen Erweitern

define di_switch DOIF ([BM_Kueche] eq "motion") (IF ([BM_Kueche:brightness:d] <50) (set switch_d on, set switch_d off))


Gruß

Damian