Verständnisfrage zu Readings..

[rabehd]

Kann das funktionieren ohne DOELSE oder ohne "attr <name> do always" ?

[Sany]

do always hat er wohl gesetzt, ansonsten funktioniert das schon, aber eben nur ein mal, wenn die Bedingungen erfüllt sind. Deshalb ja meine Ausführung zu: was sonst?

[Damian]

Ich würde alle Trigger zulassen und do always nicht setzen:

Code Auswählen Erweitern

defmod di_Heizung_morgens DOIF ([05:00-06:00] and  [BluetoothAnwesend:presence] eq "present" and  [Klima_Wohni:temperature] < 14.0) (set  Heizung_Climate desired-temp 15.0)

Begründung:

Wenn Presence nach 05:00 Uhr wahr wird, wäre das Setzen der Temperatur sinnvoll, genauso, wenn nach 05:00 Uhr die Temperatur unter 14 fällt.

Ohne do always wird nur einmal geschaltet und dann ggf. erst wieder am nächsten Tag oder wenn Presence zwischendurch unwahr war bzw. Temperatur auf über 14 Grad gestiegen und wieder gefallen ist - also so, wie es Sinn macht.

Als nächstes wird die Frage kommen, wann wird die Solltemperatur auf einen anderen Wert gesetzt

[MadMax-FHEM]

Als nächstes wird die Frage kommen, wann wird die Solltemperatur auf einen anderen Wert gesetzt

Jetzt hat es doch einer ausgesprochen!

Sie war's, sie war's, äh: er war's, er war's...

Gruß, Joachim

[UweUwe]

Hab jetzt die Frage verschoben, wie gebeten , nach Automatisierung, sehr gerne.
Die "List" sind in meinem Startbeitrag alles beinhaltet.
Morgen schau ich mir eure Vorschläge noch an. Das ? vor zum Beispiel "Bluetoothanwesend" macht mir noch Kopfzerbrechen.

[MadMax-FHEM]

Das Fragezeichen bei DOIF bedeutet: wenn das DOIF getriggert wird, also eine "Auswertung" startet, dann werden Bedingungen mit Fragezeichen nur "abgefragt". D.h. eine Änderung von Anwesenheit führt nicht zur Triggerung des DOIF (das muss dann durch eine der anderen Bedingungen erfolgen, z.B. eben Temperatur)

Das meinte ich ja mit: du musst wissen welche Änderungen das DOIF triggern sollen und welche Dinge nur "bewertet" werden sollen...

Gruß, Joachim

[UweUwe]

Vielen Dank für eure bisherigen Hinweise und Hilfen. Ich habe den Eindruck, dass das DOIF jetzt tut, was es soll. Damit ich alles korrekt verstehe und auch für weitere DOIFs anwenden kann, möchte ich den Befehl mal analysiern:

Hier nochmal das DOIF:

defmod di_Heizung_morgens DOIF ([05:00-06:00] and  [?BluetoothAnwesend:presence] eq "present" and  [?Klima_Wohni:temperature] < 14.0) (set  Heizung_Climate desired-temp 15.0)

Hinweise: ? bedeutet:
Das Fragezeichen bei DOIF bedeutet: wenn das DOIF getriggert wird, also eine "Auswertung" startet, dann werden Bedingungen mit Fragezeichen nur "abgefragt". D.h. eine Änderung von Anwesenheit führt nicht zur Triggerung des DOIF (das muss dann durch eine der anderen Bedingungen erfolgen, z.B. eben Temperatur)
==> für meinen Fall bedeutet dies Um 5 Uhr wird das DOIF getriggert und die Werte für BluetoothAnwesend und Klima_Wohni einmal ausgewertet. Heizung_Climate wird daraufhin geändert oder auch nicht. Durch die ? vor BluetoothAnwesend und Klima_Wohni ist die Definition eines Zeitraumes sinnlos. Man erhält dasselbe Ergebnis, wenn man den Zeitraum 5:00 Uhr-6:00 Uhr durch den Zeitpunkt 5:00 Uhr ersetzt. Es wird danach sowieso nicht mehr geprüft.

defmod:     ==> ??ich verstehe noch nicht wann ich define und wann ich defmod machen muss.
di_Heizung_morgens  : ==> Name der DOIF
DOIF   ==> Befehlsname
05:00-06:00   ==> DOIF prüft überhaupt nur in diesem Zeitraum , dazu muss aber ein Trigger vorliegen, um 5:00 Uhr wird in jedem Fall geprüft.
?BluetoothAnwesend:presence  : ==> das Reading presence des Modules BluetoothAnwesend wird um 5:00 Uhr geprüft , aufgrund des ? erzeugt BluetoothAnwesend:presence keinen Trigger.
eq   ==> Prüfung auf syntaktische Gleichheit
present  ==>  Ausdruck, auf den das Reading "BluetoothAnwesend:presence geprüft wird
and  => logisches Und
?Klima_Wohni:temperature   ==> das Reading Klima_Wohni:temperature wird auch um 5:00 Uhr geprüft, wie BluetoothAnwesend:presence erzeugt auch Klima_Wohni keinen Trigger bei Änderung
<  :      ==> kleiner als
14.0   ==> Wert auf den Klima_Wohni geprüft wird.
(set  Heizung_Climate desired-temp 15.0) :   ==> falls die  Prüfung positiv ist, wird über den Kanal Heizung_Climate desired temperature gesetzt.

attr di_Heizung_Test do always  : ==> ?? ich verstehe nicht, warum dies notwendig ist.

Euer Kommentar war folgendenmassen:
Ohne do always wird nur einmal geschaltet und dann ggf. erst wieder am nächsten Tag oder wenn Presence zwischendurch unwahr war bzw. Temperatur auf über 14 Grad gestiegen und wieder gefallen ist - also so, wie es Sinn macht:
Aufgrund der Fragezeichen wird doch sowieso nur einmal um 5 Uhr geprüft, auch wenn sich Presence oder Temperatur ändert. Aus meiner Sicht ist deshalb das Setzten des Attributes "do always". unnötig

Vielen Dank

[Per]

define - erstellt ein neues Device
modify- ändert ein vorhandenes Device
defmod - ändert ein vorhandenes Device, ist keins vorhanden, wird es erstellt.
Quasi das Tool für beides, wurde kreiert, um Codes zu importieren, ohne Rücksicht darauf, ob schon da oder nicht. Kannst du also immer verwenden.

[05:00-06:00] kannst du verwenden, da es hier der einzige Trigger ist, kannst du auch [05:00] verwenden, da der Endeteil zwar triggert, gleichzeitig aber false ist.
Damit könnte man z.B. ein DOELSE auslösen.

do always brauchst du hier eher (noch) nicht, aber ein DOIF wächst gern mal über die Zeit, bei dir fehlt ja auch noch das Umschalten auf eine andere desired-temp...