Hauptmenü

OR-Bedingung funktioniert nicht

Begonnen von Bartimaus, 02 Juli 2018, 22:47:49

Vorheriges Thema - Nächstes Thema

Bartimaus

Moin,

folgendes DOIF funktioniert nicht, obwohl der erste Wert in der Bedingung (Multisensor.luminance (4) > (1wireLuxRollo =8) UNWAHR ist. Wo ist mein Denkfehler ?

Ich hätte jetzt erwartet, das DOELSE eintritt, aber es wird gewartet bis  die OR-Bedingung wahr ist, erst dann kommt DOELSE.

Hier das List:

Internals:
   DEF        ([Multisensor:luminance:d] > [1wireLuxRollo] or [myT:twilight:d] > 25) ## wenn heller als Schwellenwert
(set PushiPhone message RolloTestVorne hoch)
  DOELSE
(set PushiPhone message RolloTestVorne runter)

   MODEL      FHEM
   NAME       Ti_RolloVorneDoelseTest
   NR         1332
   NTFY_ORDER 50-Ti_RolloVorneDoelseTest
   STATE      fts_shutter_10
   TYPE       DOIF
   READINGS:
     2018-07-02 22:37:18   Device          Multisensor
     2018-07-02 22:36:19   cmd             1
     2018-07-02 22:36:18   cmd_count       1
     2018-07-02 22:36:19   cmd_event       1wireLuxRollo
     2018-07-02 22:36:19   cmd_nr          1
     2018-07-02 22:36:18   e_1wireLuxRollo_STATE 9
     2018-07-02 22:37:18   e_Multisensor_luminance 4 Lux
     2018-07-02 22:36:56   e_myT_twilight  33.9
     2018-07-02 22:33:44   mode            enabled
     2018-07-02 22:36:19   state           fts_shutter_10
   Regex:
   attrtimer:
     repeatsame:
       1
       1
     wait:
     waitdel:
   condition:
     0          ReadingValDoIf($hash,'Multisensor','luminance','','d') > InternalDoIf($hash,'1wireLuxRollo','STATE') or ReadingValDoIf($hash,'myT','twilight','','d') > 25
   devices:
     0           Multisensor 1wireLuxRollo myT
     all         Multisensor 1wireLuxRollo myT
   do:
     0:
       0          set PushiPhone message RolloTestVorne hoch
     1:
       0          set PushiPhone message RolloTestVorne runter
   helper:
     DOIF_Readings_events
     DOIF_eventas
     event      luminance: 4 Lux
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   Multisensor
     timerevent luminance: 4 Lux
     triggerDev Multisensor
     timerevents:
       luminance: 4 Lux
     timereventsState:
       luminance: 4 Lux
     triggerEvents:
       luminance: 4 Lux
     triggerEventsState:
       luminance: 4 Lux
   internals:
     0           1wireLuxRollo:STATE
     all         1wireLuxRollo:STATE
   itimer:
   readings:
     0           Multisensor:luminance myT:twilight
     all         Multisensor:luminance myT:twilight
   trigger:
   uiState:
   uiTable:
Attributes:
   cmdState   fts_shutter_10|fts_shutter_100
   disable    0
   group      01 Test
   repeatsame 1:1
   room       Jalousien


Ich hatte mich an der Commandref (Klammersetzung) orientiert..., auch wenn ich jede Bedingung in eine eigene Klammer setze, hat es leider nicht wie gewünscht funktioniert.

Anwendungsbeispiel: Rollläden sollen an Arbeitstagen nach 6:25 Uhr hochfahren, wenn es hell wird, am Wochenende erst um 9:00 Uhr, herunter sollen sie wieder, wenn es dunkel wird:

define di_shutters DOIF ([sensor:brightness]>100 and [06:25-09:00|8] or [09:00|7]) (set shutters up) DOELSEIF ([sensor:brightness]<50) (set shutters down)
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

Twilight 33,9 ist mehr als 25.
Damit zieht cmd1.
Ist ja oder verknüpft.

Gesendet von meinem Doogee S60 mit Tapatalk


Bartimaus

Ich dachte es zieht jeweils der zuerst getriggerte Wert... :o, so habe ich das Gefühl, das dies hier eine AND-Verknüpfung ist und keine OR-Verknüpfung.

Scheinbar ist mein Verständnis hierfür falsch.

Ich möchte einfach nur eine Fallback-Lösung haben, falls der Multisensor ausfällt, das dann immer noch spätestens der Wert aus dem Twilight-Modul (myT) zieht.

Ideen ?

LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

myT zieht doch.
or [myT:twilight:d] > 25)
2018-07-02 22:36:56   e_myT_twilight  33.9
ergibt nunmal WAHR und damit cmd1.


Bartimaus

#4
Ja, aber heute morgen war [Multisensor:luminance:d] > 10 (=WAHR), und dennoch wurde cmd1 NICHT ausgelöst, weil ([myT:twilight:d] < 25 war, somit =FALSE).

Ich hab da jetzt echt nen Knoten im Hirn.

Ist es nicht so, das NUR EINE Bedingung aus einer "OR-Verknüpfung" wahr sein muss, um auszulösen ?

Oder hebt DOELSE das wieder auf, weil die Zweite Bedingung = FALSE ist ?
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

hast Du ein list vom Fehlerzeitpunkt heute früh?

Bartimaus

#6
Nein, leider nicht. Aber ich werde mal ein Filelog von dem DOIF basteln.

Aber das List wird nix anderes zeigen als zum Pendant von gestern Abend
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

Am List siehtst aber alle Stati und alle Werte.
Damit kann man eindeutig sehen warum das DOIF was gemacht hat.

Bartimaus

Gerade nochmal im LOG geschaut, heute morgen hat myT ausgelöst, weil die Bedingung VOR dem Multisensor wahr wurde.
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

für dein Verständnis:

Du hast Drei Geräte in dem DOIF.
wenn EINES davon sich aktualisiert überprüft das DOIF ALLE drei Werte.
vielleicht ist ja hier dein Denkfehler?

Per

Und: ohne Zusatzattribute prüft DOIF nur die Zweige, wo ein gerade getriggerter Wert ist. Diese aber jeweils vollständig.

Bartimaus

Nachdem ich den Schwellenwert für myT von 25 auf 50 geändert habe, löst der Multisensor nun die Commands aus...

LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly