Hallo,
ich möchte bei mir jede Nacht um 00:00 die Sollraumtemperatur im Bad runternehmen, wenn sie zuvor auf einem höheren Wert gesetzt war:
Dachte mir, das geht so:
defmod HeizungsReset DOIF ( [00:00] and ([HzgSetBad:desired-temp] > 29)) (set HzgSetBad desired-temp 25)
Also, wenn der Thermostat sagt, ich will 30 Grad haben und es zufälligerweise genau 00:00 ist, dann soll die Solltemperatur wieder auf 25 °C zurückgeschalten werden.
Das sollte passen. Mach noch ein DOELSEIF drunter ohne Befehl oder setze das Attribut do auf always.
Kannst aber auch [HzgSetBad:desired-temp] ne "25" machen, dann wird es auf 25 gesetzt wenn es nicht 25 ist.
Gesendet von meinem S3_32 mit Tapatalk
Ich würde es so machen
defmod HeizungsReset DOIF ( [00:00] and ([?HzgSetBad:desired-temp] > 29)) (set HzgSetBad desired-temp 25)
Ja, ist ressourcen schonender. 😉
Gesendet von meinem S3_32 mit Tapatalk
Wieso ressourcenschonender?
Wegen dem ? vor dem Reading?
Zitat aus der commandref:
Trigger verhindern [?<devicename>], [?<devicename>:<readingname>], [?<devicename>:&<internalname>], [?<time specification>]
Werden Status, Readings, Internals und Zeitangaben in der Bedingung mit einem Fragezeichen eingeleitet, triggern sie nicht.
sowie:
https://fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger (https://fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger)
Wieso löst ein Zugriff auf das Reading einen Trigger aus?
Und welche(n)?
Zitat von: wowogiengen am 28 September 2017, 19:18:35
Wieso löst ein Zugriff auf das Reading einen Trigger aus?
Und welche(n)?
rate doch mal wann diese Bedingung ausgewertet wird:
DOIF ([HzgSetBad:desired-temp] > 29) ...
Hallo Damian,
ich will nicht raten :-\
Weil unter einem Trigger verstehe ich ein Ereignis, welches ausgelöst wird, wenn sich ein Zustand ändert.
Und der einzige Zustand, der sich hier ändert, ist das Setzen der Wunschtemperatur auf 25°C.
Durch das Auslesen des Readings wird doch kein Trigger ausgelöst?
Und wenn doch, wo kann man das nachlesen?
siehe: https://fhem.de/commandref_DE.html#DOIF_checkReadingEvent
Hallo,
Thermostat Mode auto und templist ist zu einfach?
Weshalb muß man da ein DoIf bemühen?
Gruß Rolf
Zitat von: Damian am 29 September 2017, 18:29:02
siehe: https://fhem.de/commandref_DE.html#DOIF_checkReadingEvent
Bezogen auf mein Beispiel mit dem Raumthermostat würde das heissen, dass mein DoIf auch dann die Temperatur auswerten würde, wenn sich die Luftfeuchtigkeit im Raum ändert? Also ohne checkReadingEvent.
Inwieweit wirkt es sich dann positiv oder negativ auf die Performance aus, wenn man zuerst die Uhrzeit und dann die Temperatur prüft, oder umgekehrt?
Also:
defmod HeizungsReset DOIF ( [00:00] and ([HzgSetBad:desired-temp] > 29)) (set HzgSetBad desired-temp 25)gegenüber
defmod HeizungsReset DOIF ( ([HzgSetBad:desired-temp] > 29) and [00:00]) (set HzgSetBad desired-temp 25)bzw. dann noch besser
defmod HeizungsReset DOIF ( [00:00] and ([?HzgSetBad:desired-temp] > 29)) (set HzgSetBad desired-temp 25)gegenüber
defmod HeizungsReset DOIF (([?HzgSetBad:desired-temp] > 29) and [00:00]) (set HzgSetBad desired-temp 25)
Das Beispiel in der CommandRef verstehe ich nicht:
Angaben in eckigen Klammern, die mit einem Fragezeichen beginnen, führen zu keiner Triggerung des Moduls, sie dienen lediglich der Abfrage.
Anwendungsbeispiel: Licht soll zwischen 06:00 und 10:00 angehen, getriggert wird nur durch den Taster nicht um 06:00 bzw. 10:00 Uhr und nicht durch das Device Home
define di_motion DOIF ([?06:00-10:00] and [button] and [?Home] eq "present")(set lamp on-for-timer 600)
attr di_motion do always
Kann mir mal jemand ein Beispiel machen, wo man den Unterschied sehen kann, was mit oder ohne Fragezeichen tatsächlich ausführt?
Viele Grüße
Wolfgang
Zitat von: rvideobaer am 29 September 2017, 18:38:58
Hallo,
Thermostat Mode auto und templist ist zu einfach?
Weshalb muß man da ein DoIf bemühen?
Gruß Rolf
Ich glaube, dass ich absichtlich von dem Auto-Modus und der Temperaturliste weggegangen bin, weil für meinen Anwendungsfall das nicht funktioniert:
Meine Frau sitzt im Rollstuhl, und
in der Regel geht sie jeden zweiten Tag baden, und wenn sie baden geht, schalten wir in der Früh die FBH auf 30°C dass es abends ja nicht zu kalt ist im Bad für sie. Damit wir die Heizung aber nach dem Baden nicht vergessen können, wollte ich jede Nacht um 00:00 bei Solltemperatur 30°C die Solltemperatur wieder auf 25°C runternehmen, was auch schon viel ist, aber grade so passt...
Den Automodus und die Temperaturliste kann ich aber nur so verwenden, dass ich an gleichen Wochentagen abwechselnd 30°C und Normaltemperatur einstelle, also z.B. Mo, Mi, Fr und So. Aber in der zweiten Woche wären die Badetage dann ja Di, Do und Sa. Und das versteht die Templist doch nicht?
Außerdem kann man dann nicht manuell eingreifen, ohne dass man am Abend wieder auf Auto stellen muss, wenn mal die Badetage doch anders wären.
Von daher habe ich es jetzt mal mit manueller Steuerung versucht, und um 00:00 dann wieder auf normale Temperatur zurück.
Bei kompletter Steuerung über FHEM könnte man sicher auch einen virtuellen Button "Badetag" definieren, der in der Früh dafür sorgt, dass von Auto auf manuell umgeschalten wird, und auf 30 °C Solltemperatur, sowie um 00:00 dann wieder auf Auto...
Zitat von: wowogiengen am 29 September 2017, 20:31:59
Bezogen auf mein Beispiel mit dem Raumthermostat würde das heissen, dass mein DoIf auch dann die Temperatur auswerten würde, wenn sich die Luftfeuchtigkeit im Raum ändert? Also ohne checkReadingEvent.
Inwieweit wirkt es sich dann positiv oder negativ auf die Performance aus, wenn man zuerst die Uhrzeit und dann die Temperatur prüft, oder umgekehrt?
Also:
defmod HeizungsReset DOIF ( [00:00] and ([HzgSetBad:desired-temp] > 29)) (set HzgSetBad desired-temp 25)
gegenüber
defmod HeizungsReset DOIF ( ([HzgSetBad:desired-temp] > 29) and [00:00]) (set HzgSetBad desired-temp 25)
bzw. dann noch besser
defmod HeizungsReset DOIF ( [00:00] and ([?HzgSetBad:desired-temp] > 29)) (set HzgSetBad desired-temp 25)
gegenüber
defmod HeizungsReset DOIF (([?HzgSetBad:desired-temp] > 29) and [00:00]) (set HzgSetBad desired-temp 25)
Das Beispiel in der CommandRef verstehe ich nicht:
Angaben in eckigen Klammern, die mit einem Fragezeichen beginnen, führen zu keiner Triggerung des Moduls, sie dienen lediglich der Abfrage.
Anwendungsbeispiel: Licht soll zwischen 06:00 und 10:00 angehen, getriggert wird nur durch den Taster nicht um 06:00 bzw. 10:00 Uhr und nicht durch das Device Home
define di_motion DOIF ([?06:00-10:00] and [button] and [?Home] eq "present")(set lamp on-for-timer 600)
attr di_motion do always
Kann mir mal jemand ein Beispiel machen, wo man den Unterschied sehen kann, was mit oder ohne Fragezeichen tatsächlich ausführt?
Viele Grüße
Wolfgang
1) ja, auch Feuchtigkeit oder jedes anderes Reading des Devices würde dein DOIF-Modul triggern.
2) Die Reihenfolge der Angaben spielt hier keine Rolle, dein Beispiel 1 entspricht Beispiel 2 bzw. 3 entspricht 4.
Für dich ist Beispiel 3 oder 4 das richtige, denn die Temperaturabfrage soll nur um 0:00 Uhr stattfinden.
Zitat von: Damian am 29 September 2017, 21:36:54
1) ja, auch Feuchtigkeit oder jedes anderes Reading des Devices würde dein DOIF-Modul triggern.
2) Die Reihenfolge der Angaben spielt hier keine Rolle, dein Beispiel 1 entspricht Beispiel 2 bzw. 3 entspricht 4.
Für dich ist Beispiel 3 oder 4 das richtige, denn die Temperaturabfrage soll nur um 0:00 Uhr stattfinden.
Hallo Damian,
ausgehend von dem was ich in anderen Programmiersprachen gelernt habe, würde ich sagen, dass ich das Reading, welches weniger häufig wechselt als erstes angeben würde.
Weil, wenn das Reading dann nicht true ergibt, würde beim "and" das zweite Reading gar nicht mehr ausgewertet werden müssen.
Bis grade eben wollte ich die Uhrzeit als erste Bedingung angeben, und die Temperatur als zweites.
Aber nach ein bischen Überlegen:
die Uhrzeit wechselt eigentlich jede Sekunde, und die Temperatur etwas langsamer.
Somit zuerst auf die Temperatur abfragen und dann auf die Uhrzeit.
Wobei aber die Solltemperatur an dem in Frage kommenden Tag ja seit der Früh auf 30°C steht...
Viele Grüße
Wolfgang
Zitat von: wowogiengen am 30 September 2017, 12:00:20
Hallo Damian,
ausgehend von dem was ich in anderen Programmiersprachen gelernt habe, würde ich sagen, dass ich das Reading, welches weniger häufig wechselt als erstes angeben würde.
Weil, wenn das Reading dann nicht true ergibt, würde beim "and" das zweite Reading gar nicht mehr ausgewertet werden müssen.
Bis grade eben wollte ich die Uhrzeit als erste Bedingung angeben, und die Temperatur als zweites.
Aber nach ein bischen Überlegen:
die Uhrzeit wechselt eigentlich jede Sekunde, und die Temperatur etwas langsamer.
Somit zuerst auf die Temperatur abfragen und dann auf die Uhrzeit.
Wobei aber die Solltemperatur an dem in Frage kommenden Tag ja seit der Früh auf 30°C steht...
Viele Grüße
Wolfgang
ja, auch in Perl (das ist ja die DOIF-Bedingung in Wirklichkeit) gilt diese Regel, wenn bei and die erste Teilbedingung wahr ist wird der Rest nicht mehr ausgewertet.
Du musst dich von einer sequentiellen Abarbeitung von Befehlssequenzen lösen. Wir sind hier bei ereignisgesteuerter Abarbeitung von Befehlssequenzen.
(([?HzgSetBad:desired-temp] > 29) and [00:00]) wird genau einmal am Tag überprüft, da ist es ziemlich egal wie rum die Befehle stehen.
Unabhängig davon kannst du davon ausgehen, dass
niemals zwei Ereignisse gleichzeitig vom Modul begearbeitet werden können:
(([HzgSetBad:desired-temp] > 29) and [00:00])
dh. Trigger von HzgSetBad und 00:00 wird niemals in FHEM gleichzeitig beim DOIF ankommen.
Hallo,
dann frag ich einfach mal dumm weiter, wenn es dir nichts ausmacht... Vielleicht kann man die Antworten irgendwie ins WIKI einfliessen lassen?
Ich stelle mir FHEM so vor, dass irgendwo eine Schleife läuft (der Haupt-Thread sozusagen), welche zum einen den Input vom Funkmodul verarbeitet, daraus dann Readings für die Devices macht, und anhand der Readings dann eben das Ereignis generiert, dass sich das Reading des Device geändert hat.
An einer anderen Stelle prüft FHEM dann für jeden Befehl sag ich mal(also AT, DoIf, Notify und was weiss ich noch), ob irgendein Ereignis vorliegt, welches auf die Bedingung und den Status des Befehls passt. Wenn ja, wird der Befehl entsprechend weiterverarbeitet.
Aber dazu passt dann meine Vorstellung von dem DoIf und den Triggern nicht, dass diese nie gleichzeitig im DoIf ankommen.
Du schreibst, dass meine Bedingung genau 1 x am Tag geprüft wird. Dazu muss aber das DoIf wissen, wann es prüfen soll.
Wenn ich ein Intervall angegeben hätte, also z.B. von 22:00 bis 23:59, dann muss doch innerhalb dieses Zeitraums ständig geprüft werden, ob die Solltemperatur vielleicht bei 30°C liegt - außer die Ereignissteuerung weiß, dass das DoIf vom Reading der Solltemperatur abhängt und triggert dann das DoIf wenn die Solltemperatur von irgendwas auf 30°C umgestellt wird. Aber das passiert ja nur genau 1 x am Tag. Und dann auch nicht im Intervall oder um 00:00.
Wenn ich die Uhrzeit als Triggerquelle nehme, dann triggert diese doch das DoIf immer dann, wenn sie sich ändert, also nicht nur 1 x am Tag.
Bin etwas verwirrt :-\
Viele Grüße
Wolfgang
Wie die internen FHEM-Mechanismen im einzelnen funktionieren, musst du im Developer-Bereich nachlesen.
zu Zeitintervallen: https://fhem.de/commandref_DE.html#DOIF_Zeitsteuerung_mit_Zeitintervallen
da steht, dass genau zwei mal getriggert wird.
[00:00] ist kein Zeitintervall, sondern ein Zeitpunkt, er ist nur im "Augenblick" der Triggerung, gesteuert von FHEM, wahr und sonst nie. Und da ein FHEM-Modul immer nur zu einem Event "geweckt" wird, welches es abarbeitet und die Kontrolle sofort zurückgibt, kann es niemals zwei verschiedene Events im Modul geben: z. B. Zeit-Event und Ereignis-Event.
Merke: "DOIF schaut nie eigenständig irgendwo nach, sondern macht etwas, wenn es dazu durch Ereignisse/Zeittrigger von FHEM aufgefordert wird."