DOIF neue Features (Sleep-Alternative)

[Ellert]

Oh, das ist mir entgangen, dann müsste der nicht getestete Ausführungsteil so aussehen:

Code Auswählen Erweitern

(set Lampe.?:FILTER=STATE=off on)
Wenn man über Steckdosen schaltet, die mit "on" ihren Zustand wechseln, kann man verhindern, dass Lampe1 wieder ausgeschaltet wird.

[Ellert]

Ich benutze das DOIF sehr gern, deshalb bin ich gerade dabei meine Verzögerungen mit flüchtigen at auf die neuen wait Eigenschaften umzustellen.
Meine Verzögerungen sind von $we abhängig, die Startzeiten stehen in s7 und s8, die Verzögerungszeiten in Sekunden stehen in t7 und t8.
Ich könnte das DOIF so definieren:

Code Auswählen Erweitern

([s7|7] or [s8|8]) ()
mit dem wait geht es nicht, dies funktioniert nicht:

Code Auswählen Erweitern

wait [t7|7] or [t8|8]
wait if($we){return Value("t7")} else {return Value("t8")}

(Alternativ könnte man natürlich eine Funktion in der 99_myUtils.pm definieren, um vom Wochentag abhängige Zeiten zu erhalten.)

daher kann ich das DOIF nur so definieren:

Code Auswählen Erweitern

([s7|7]) ()
DOELSEIF ([s8|8]) ()

(Für komplexere Bedingungen wird es dadurch unübersichtlicher.)

und das wait so:

Code Auswählen Erweitern

wait [t7]:[t8]

Wäre es nicht wünschenswert, die Syntax der Zeitangaben in den Bedingungen auch für die wait timer einzuführen? Das könnte die Zahl der Bedingungszweige reduzieren.

Eine wait Definition sieht bei mir so aus:

Code Auswählen Erweitern

0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0

Da die Eingabezeile für Attribute recht kurz ist, schlage ich vor hier ein Editorfenster zur übersichtlichen Eingabe zu nutzen, wie es z.B. für das Attribut cellStyle der readingsGroup geschieht. Wird das im Modul gesteuert?

[Damian]

Ich benutze das DOIF sehr gern, deshalb bin ich gerade dabei meine Verzögerungen mit flüchtigen at auf die neuen wait Eigenschaften umzustellen.
Meine Verzögerungen sind von $we abhängig, die Startzeiten stehen in s7 und s8, die Verzögerungszeiten in Sekunden stehen in t7 und t8.
Ich könnte das DOIF so definieren:

Code Auswählen Erweitern

([s7|7] or [s8|8]) ()
mit dem wait geht es nicht, dies funktioniert nicht:

Code Auswählen Erweitern

wait [t7|7] or [t8|8]
wait if($we){return Value("t7")} else {return Value("t8")}

(Alternativ könnte man natürlich eine Funktion in der 99_myUtils.pm definieren, um vom Wochentag abhängige Zeiten zu erhalten.)


daher kann ich das DOIF nur so definieren:

Code Auswählen Erweitern

([s7|7]) ()
DOELSEIF ([s8|8]) ()

(Für komplexere Bedingungen wird es dadurch unübersichtlicher.)

und das wait so:

Code Auswählen Erweitern

wait [t7]:[t8]

Wäre es nicht wünschenswert, die Syntax der Zeitangaben in den Bedingungen auch für die wait timer einzuführen? Das könnte die Zahl der Bedingungszweige reduzieren.

Eine wait Definition sieht bei mir so aus:

Code Auswählen Erweitern

0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0

Da die Eingabezeile für Attribute recht kurz ist, schlage ich vor hier ein Editorfenster zur übersichtlichen Eingabe zu nutzen, wie es z.B. für das Attribut cellStyle der readingsGroup geschieht. Wird das im Modul gesteuert?

Du kannst auch  mit Zeiten rechnen:

Code Auswählen Erweitern

define s1 dummy
set s1 10:00

define t1 dummy
set t1 300

DOIF ([([s1]+[t1])|7] or ...) ()


oder

Code Auswählen Erweitern

DOIF ([([s1]+myfunction())|7] or ...) ()


Hier brauchst du kein wait.

Weitere Informationen siehe: Zeitsteuerung mit Zeitberechnung in der Commandref des Moduls

Gruß

Damian

[Ellert]

Ja, da ist bei meiner Vereinfachung etwas untergegangen, es müsste so aussehen:

Code Auswählen Erweitern

([s7|7]) () ()
DOELSEIF ([s8|8]) () ()

wait 0,[t7]:0,[t8]

Hier wäre folgendes wünschenswert, aus meiner Sicht.

Code Auswählen Erweitern

([s7|7] or [s8|8]) () ()

wait 0,[t7|7] or [t8|8]

Bei mir konkret sind diese Dummys [work...] für Werktags und diese [wend...] fürs Wochenende. Die massgeblichen Bedingungszweige haben 3 Komandos:

Code Auswählen Erweitern

wait 0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0

[Damian]

Ja, da ist bei meiner Vereinfachung etwas untergegangen, es müsste so aussehen:

Code Auswählen Erweitern

([s7|7]) () ()
DOELSEIF ([s8|8]) () ()

wait 0,[t7]:0,[t8]

Hier wäre folgendes wünschenswert, aus meiner Sicht.

Code Auswählen Erweitern

([s7|7] or [s8|8]) () ()

wait 0,[t7|7] or [t8|8]

Bei mir konkret sind diese Dummys [work...] für Werktags und diese [wend...] fürs Wochenende. Die massgeblichen Bedingungszweige haben 3 Komandos:

Code Auswählen Erweitern

wait 0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0

ja, da wirst du erst mal mit mehreren DO-Fällen arbeiten müssen. Mangels Zeit wird es voraussichtlich erst im nächsten Jahr weitere Erweiterungen des Moduls geben. Bis dahin bietet das Modul bereits genügend Potential, um es nach belieben auszureizen


Gruß

Damian

[Ellert]

...bietet das Modul bereits genügend Potential...  Deshalb bleibt das DOIF auch mein funktionales Lieblingsmodul 

[Toto1973]

Ich steuere inzwischen alles mit DOIF.
Es ist sehr verständlich und hat fast unendlich viele Möglichkeiten

[Mumpitz]

hallo zusammen

Ich habe heute bei meinem DOIF folgendes Verhalten festgestellt, welches ich nicht nachvollziehen kann:

ich habe folgendes DOIF für meine Beschattung:

Code Auswählen Erweitern

Internals:
   DEF        ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "off" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and ([Multisensor_Ost:state] > 25000 or [Sensor_Licht_Sued:state] > 19000)) (set Beschattung_OG on)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and [Sensor_Licht_Sued:state] < 9000) (set Beschattung_OG off)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and ([Helligkeit_Twilight:azimuth] > 277 or [Helligkeit_Twilight:compasspoint] eq "west")) (set Beschattung_OG off)
   NAME       di_SoSchu_OG
   NR         119
   NTFY_ORDER 50-di_SoSchu_OG
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2015-09-14 11:26:28   Device          Multisensor_Ost
     2015-09-14 11:17:15   cmd_event       Beschattung_OG
     2015-09-14 11:17:15   cmd_nr          2
     2015-09-14 11:17:15   e_Beschattung_OG_STATE off
     2015-09-14 11:24:36   e_Helligkeit_Twilight_azimuth 142.97
     2015-09-14 11:24:36   e_Helligkeit_Twilight_compasspoint southeast
     2015-09-14 11:26:28   e_Multisensor_Ost_state 2175
     2015-09-14 04:33:17   e_Sensor_Licht_Sued_state 0
     2015-09-14 11:17:15   state           cmd_2
     2015-09-14 11:17:15   wait_timer      no timer
   Condition:
     0          InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "off" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and (ReadingValDoIf('Multisensor_Ost','state','') > 25000 or ReadingValDoIf('Sensor_Licht_Sued','state','') > 19000)
     1          InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and ReadingValDoIf('Sensor_Licht_Sued','state','') < 9000
     2          InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and (ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 277 or ReadingValDoIf('Helligkeit_Twilight','compasspoint','') eq "west")
   Devices:
     0           Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
     1           Auto_Beschattung Beschattung_OG Helligkeit_Twilight Sensor_Licht_Sued
     2           Auto_Beschattung Beschattung_OG Helligkeit_Twilight
     all         Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
   Do:
     0:
       0          set Beschattung_OG on
     1:
       0          set Beschattung_OG off
     2:
       0          set Beschattung_OG off
     3:
   Helper:
     globalinit 1
     last_timer 0
     sleepdevice Beschattung_OG
     sleepsubtimer -1
     sleeptimer -1
   Internals:
     0           Auto_Beschattung:STATE Beschattung_OG:STATE
     1           Auto_Beschattung:STATE Beschattung_OG:STATE
     2           Auto_Beschattung:STATE Beschattung_OG:STATE
     all         Auto_Beschattung:STATE Beschattung_OG:STATE
   Itimer:
   Readings:
     0           Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state
     1           Helligkeit_Twilight:azimuth Sensor_Licht_Sued:state
     2           Helligkeit_Twilight:azimuth Helligkeit_Twilight:compasspoint
     all         Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state Helligkeit_Twilight:compasspoint
   State:
   Trigger:
Attributes:
   wait       900:2400

nach meiner Ansicht müsste der Multisensor_Ost während 900 sec den Wert von 25'000lx überschreiten, erst dann sollte er ausgelöst werden.
Anhand des Logs des Sensors ist jedoch ersichtlich, dass er nur um 1022 Uhr und 1024 Uhr diesen Wert überschritten hat. Daher hätte das DOIF  den cmd_1 nicht auslösen dürfen. Oder sehe ich das falsch?

der Rollladen wurde jedoch um:

2015.09.14 10:37:15 3: CUL_HM set Rollladen_Eltern_1 0

ausgelöst

Hier die Werte meines Sensors:

Code Auswählen Erweitern

2015-09-14_10:40:21 Multisensor_Ost humidity: 63
2015-09-14_10:40:21 Multisensor_Ost temperature: 24
2015-09-14_10:40:21 Multisensor_Ost 5044
2015-09-14_10:40:21 Multisensor_Ost lux: 5044
2015-09-14_10:38:21 Multisensor_Ost humidity: 64
2015-09-14_10:38:21 Multisensor_Ost temperature: 23
2015-09-14_10:38:21 Multisensor_Ost 5698
2015-09-14_10:38:21 Multisensor_Ost lux: 5698
2015-09-14_10:36:21 Multisensor_Ost humidity: 64
2015-09-14_10:36:21 Multisensor_Ost temperature: 23
2015-09-14_10:36:21 Multisensor_Ost 7720
2015-09-14_10:36:21 Multisensor_Ost lux: 7720
2015-09-14_10:34:22 Multisensor_Ost humidity: 64
2015-09-14_10:34:22 Multisensor_Ost temperature: 22
2015-09-14_10:34:22 Multisensor_Ost 28036
2015-09-14_10:34:22 Multisensor_Ost lux: 28036
2015-09-14_10:32:14 Multisensor_Ost humidity: 64
2015-09-14_10:32:14 Multisensor_Ost temperature: 22
2015-09-14_10:32:14 Multisensor_Ost 17910
2015-09-14_10:32:14 Multisensor_Ost lux: 17910
2015-09-14_10:30:14 Multisensor_Ost humidity: 65
2015-09-14_10:30:14 Multisensor_Ost temperature: 22
2015-09-14_10:30:14 Multisensor_Ost 5340
2015-09-14_10:30:14 Multisensor_Ost lux: 5340
2015-09-14_10:28:15 Multisensor_Ost humidity: 67
2015-09-14_10:28:15 Multisensor_Ost temperature: 22
2015-09-14_10:28:15 Multisensor_Ost 5339
2015-09-14_10:28:15 Multisensor_Ost lux: 5339
2015-09-14_10:26:14 Multisensor_Ost humidity: 68
2015-09-14_10:26:14 Multisensor_Ost temperature: 22
2015-09-14_10:26:14 Multisensor_Ost 8084
2015-09-14_10:26:14 Multisensor_Ost lux: 8084
2015-09-14_10:24:14 Multisensor_Ost humidity: 67
2015-09-14_10:24:14 Multisensor_Ost temperature: 21
2015-09-14_10:24:14 Multisensor_Ost 32354
2015-09-14_10:24:14 Multisensor_Ost lux: 32354
2015-09-14_10:22:14 Multisensor_Ost humidity: 66
2015-09-14_10:22:14 Multisensor_Ost temperature: 20
2015-09-14_10:22:14 Multisensor_Ost 54612
2015-09-14_10:22:14 Multisensor_Ost lux: 54612

Den Licht_Sensor_Süd kann man vernachlässigen, der sendet zur Zeit immer 0. Sprich für die Auslösung nicht relevant...

Ich möchte auch sagen, dass das DOIF in den letzten Monaten immer funktioniert hat. Diesen, aus meiner Sicht, Fehler stelle ich erst jetzt fest...

Weiss jemand rat oder kann den Fehler nachvollziehen?

[RoBra81]

Hallo,

ein Schuss ins blaue: Kann es sein, dass du einen expliziten DOELSE-Zweig brauchst? Du hast nämlich den Multisensor in keinem anderen Zweig, daher wird der 1. Zweig nicht verlassen...

Ronny

[Mumpitz]

Aus meiner Sicht braucht ich das nicht. Wenn der Sensorwert unterboten oder der azimuth wert größer ist wird ja cmd_2 oder 3 ausgelöst!

[RoBra81]

Aus meiner Sicht passiert nichts, wenn der Sensorwert unterboten wird, da keiner der anderen Trigger greift...

[Damian]

Aus meiner Sicht passiert nichts, wenn der Sensorwert unterboten wird, da keiner der anderen Trigger greift...

ja, in der Commandref steht auch:

Die Angaben werden immer von links nach rechts abgearbeitet. Zu beachten ist, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event das dazughörige Device bzw. die dazugehörige Triggerzeit beinhalten. Kommt ein Device in mehreren Bedingungen vor, so wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist.


Gruß

Damian

[Mumpitz]

Hmm, jetzt steh ich etwas auf dem Schlauch:

Heißt das das ich einen doelse Zweig brauche welcher trigert wenn der Wert unter 25'000 ist?
Wenn ja, was soll der tun?

[RoBra81]

Wenn er dann nichts machen soll hängst du einfach ein DOELSE ohne Aktion hinten dran...

[Brockmann]

Aus meiner Sicht braucht ich das nicht. Wenn der Sensorwert unterboten oder der azimuth wert größer ist wird ja cmd_2 oder 3 ausgelöst!

Da der Sensorwert in den beiden anderen Bedingungen gar nicht abgefragt wird, können diese auch nicht reagieren, wenn er unterboten wird.

Die eigentlich entscheidende Stelle der Commandref ist vielleicht diese:

Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.

Und zwar nur dann!

wait bedeutet also nicht, dass eine Aktion A ausgeführt wird, wenn die Bedingung A für die bei wait spezifizierte Zeit Bestand hat.
wait bedeutet: Wenn irgendwann mal Bedingung A galt und seitdem keine andere Bedingung desselben DOIF wahr geworden ist, wird nach Ablauf der in wait spezifierten Zeit Aktion A ausgeführt, egal ob Bedingung A zu diesem Zeitpunkt immer noch wahr ist oder nicht.

Man kann sich darüber streitet ob das nun ein Feature oder ein Fehler ist (DOIF vs. DOEVENIFNOTANYMORE). Aber so ist es nunmal und man muss sein DOIF ggf. um diese Eigenart herumprogrammieren. Wie hier ja schon geschrieben wurde, ist ein "leeres" DOELSE der bevorzugte Workaround.