Allg. Frage zu Regeln/Workflow mit IF, AND/OR

[Lingualizer]

Hallo zusammen,
so nach und nach macht mein OH3, was in Livisi schon recht gut geklappt hat.
Jetzt geht's in die nächste Runde und da fehlt mir wohl noch etwas Grundwissen zu den Regeln.

Beispiel:
Ich habe einige virtuelle Schalter: Urlaub j/n, Zuhause j/n, Tag/Nacht, Wochenende j/n,...

Eine Rolloregel sieht zB so aus: Um 7 Uhr soll an Werktagen das Schlafzimmer-Rollo hochgefahren werden. Funktioniert bestens.

Ist Urlaub=Ja und Zuhause=Ja, soll der Rollo nicht hochgefahren werden.
Ist allerdings Urlaub=Ja und Zuhause=Nein, darf der Rollo hoch.

Wie kann man das ganze "workflow-mäßig" angehen?
Geht das mit einer Regel und ich rufe andere Regeln je nach Situation auf?
Was wäre die beste Vorgehensweise?

In dem Zusammenhang wüsste ich auch gerne, wie man UND/ODER in einer Regel unterbringt.
Also: wenn A ODER B, dann... bzw. wenn A UND B, dann...
und bei "But only if" im Prinzip genauso, wenn man 2 Bedingungen hat.

Lieben Dank für eure Antwort!
//Peter

[int5749]

Hi,

Du kannst "beliebig" viele Abfragen verschachteln, besser gehen solche Antworten jedoch noch an genauen Beispielen/Anfragen

Beispiel aus meinen DSL-Rules

Code: Alles auswählen

rule NightStarts
when
	Item Night changed
then
	if (Night.state == ON  && now.toLocalTime.getHour >= 15) {
       	ManSunProtection.sendCommand(OFF)
		SunProtection.sendCommand(OFF)
		mySunProtectionVis.postUpdate(ON)

		gShutterOG.members.filter(f|(f.state as DecimalType).intValue!==100).forEach[ s|
			s.sendCommand(DOWN)
			logInfo("Shutter", s.name + " received DOWN")
		]

		//schalte ein paar Lampen ein 
		Lampe_1.sendCommand(ON)
		Lampe_2.sendCommand(ON)
		Lampe_3.sendCommand(ON)
		if (Parents.state == OFF) {
			gShutterEG.members.filter(f|(f.state as DecimalType).intValue!==100).forEach[ s|
				s.sendCommand(DOWN)
				logInfo("Shutter", s.name + " received DOWN")
			]
			actions.sendMessageToDevice("X", "Rollladen fahren ab !!", "Notification")
			if (GhostMode.state == OFF) {
				actions.sendMessageToDevice("X", "Anwesendheitssimulation NICHT aktiviert !!", "Notification")
			} else if (GhostMode.state == ON) {
				Absence.postUpdate(ON)	// Starte Anwesendheitssimulation
			}
		} else if (Parents.state == ON) {
			// fahre ein paar RolloS runter
			1_Rollo.sendCommand(DOWN)
			2_Rollo.sendCommand(DOWN)
			3_Rollo.sendCommand(DOWN)

			// fahre ein paar RolloS auf halb-8
			5_Rollo.sendCommand(40)	//Weihnachten raus
			6_Rollo.sendCommand(40)
			7_Rollo.sendCommand(55)
			
			//etwas Deko Licht im Garten
			Lampe_9.sendCommand(ON)
			Lampe_10.sendCommand(ON)
			myCloseItSwitchVis.postUpdate(ON)
			myCloseItSwitch.postUpdate(OFF)
			actions.sendMessageToDevice("X", "Nicht vergessen Rollladen manuell zu schließen!!", "Alert")
		}
	} else if (Night.state == OFF) {
		actions.sendMessageToDevice("X", "Night deaktiviert.", "Notification")
		SleepMode.postUpdate(0)
		sonneost.postUpdate(0)
		sonnesued.postUpdate(0)
		sonnewest.postUpdate(0)
	}
end

Und verknüpfung: if (Night.state == ON && now.toLocalTime.getHour >= 15)

Oder verknüpfung: if (Night.state == ON || now.toLocalTime.getHour >= 15)

Und/Oder Verknüpfung: if ((Night.state == ON || now.toLocalTime.getHour >= 15) && (Summer.state == ON))

[Lingualizer]

Ah, ok, das passt schon für mich. Verschachteln und Klammern werd ich schon hinbekommen.
Nur unterscheiden sich die Beispiele hier von meinen Codes.
Die 7Uhr Rule sieht zB so aus:
-------------------

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      time: 07:00
    type: timer.TimeOfDayTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      offset: 0
    type: ephemeris.WeekdayCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      command: "70"
      itemName: SchlafzimmerRolloshelly25141_RollerControl0open100closed
    type: core.ItemCommandAction
  - inputs: {}
    id: "4"
    configuration:
      itemName: innogyPSSuntermBettSchlafzimmer_Schalter
      command: ON
    type: core.ItemCommandAction

---------------------------
Ich mach das meiste im Moment über das UI, weil ich noch nicht so fit mit dem Syntax bin.
Wie würde man den hier eine UND oder ODER Bedingung definieren?
Das müsste ja im Abschnitt 'conditions' sein.

[udo1toni]

Das Konstrukt "when ... but only if" ist hier nicht flexibel genug, Du müsstest zwei Rules mit gleichem Inhalt definieren, die eine, welche nur triggert, wenn Urlaub OFF ist, die andere, die nur triggert, wenn Urlaub ON und Zuhause OFF ist.
Alternativ könntest Du natürlich ein Script für den "but only if" Teil nehmen. Aber da beißt sich die Katze in den Schwanz...

Die Syntax der Rule ist in diesem Fall echt nicht schwer:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      time: 07:00
    type: timer.TimeOfDayTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      offset: 0
    type: ephemeris.WeekdayCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: >-
        if((Urlaub.state == ON && Zuhause.state == OFF) || Urlaub.state == OFF) {
            SchlafzimmerRolloshelly25141_RollerControl0open100closed.sendCommand(70)
            innogyPSSuntermBettSchlafzimmer_Schalter.sendCommand(ON)
        }
    type: script.ScriptAction

Ich möchte Dir dringend empfehlen, die Items sinnvoll zu benennen. Beispiel Rollladen: Es ist vollkommen uninteressant, welche Hardware den Rollladen steuert, erst recht, wie der Rollladen gesteuert wird. Je nach Aufbau und Größe des Gebäudes kann es interessant sein, eine Information zum Stockwerk oder zur Wohneinheit mit im Namen des Items zu haben. Gibt es nur ein Schlafzimmer, so reicht das natürlich, um das Item eindeutig zuzuordnen. Es handelt sich um einen Rollladen. Also reicht im Zweifel das als Name: Schlafzimmer_Rollladen. Alles andere ist Ballast, der innerhalb einer Rule (und auch an jeder anderen Stelle in openHAB) nur unnötig das Leben schwer macht. Man könnte sogar zu Recht den Namen noch weiter einkürzen, z.B. auf Schlaf_Roll. Bei uns gibt es Kinderzimmer. Also Eltern_Roll und Kind1_Roll sowie Kind2_Roll. Da beide Kinderzimmer zwei Fenster mit elekrischen Rollläden haben, gibt es in Wirklichkeit vier Items für die Kinderzimmer mit einem zusätzlichen _l bzw. _r hinten dran. Damit weiß ich, ob es das linke oder das rechte Fenster ist.

Weiter: Befehle werden nicht an Schalter gesendet. Schalter spielen überhaupt nur höchst selten eine Rolle in openHAB (so es um die Hardware geht). openHAB steuert Aktoren.
Ja, es gibt kombinierte Schalter/Aktoren, aber man möchte in openHAB allgemein den Aktor steuern. Da der PSS vermutlich mehrere Kanäle hat, kannst Du natürlich dennoch ein Schlüsselwort für die Funktion nutzen, aber im Grunde ist das Schalten des Aktors die Hauptaufgabe, man könnte hier also bequem auf das _Schalter verzichten und wüsste am Ende dennoch, was gemeint ist. Auch hier gilt: Lass die Information zur Hardware weg. Stell Dir vor, Du möchtest das Innogy Gerät gegen etwas anderes tauschen, z.B. einen Shelly Zwischenstecker. Ohne Hardwareinformation im Itemnamen musst Du lediglich den Link ändern, mit Hardwareinformation stimmt entweder der Itemname nicht, oder Du musst das Item löschen und neu anlegen. Und natürlich musst Du alle Bezüge in Rules usw. neu erstellen.

Genau deshalb gibt es in openHAB eine strikte Trennung zwischen Hardware (Things + Channel) und openHAB Bus (Items). Auf dem Bus sollte man nur logische Funktionen als Namen nutzen.

openHAB verwendet natürlich zum Generieren von Items die Thing- und Channel Label, Das ist aber nur ein Mittel, um zu verhindern, dass Itemnamen komplett generisch sind. Es ist bestenfalls eine Krücke, man sollte direkt von Beginn an ein sinnvolles Namenskonzept verwenden.

EDIT: Ach so... Weil Du im Rollladen Itemnamen auch noch 0open100closed mit drin stehen hast: in openHAB geht das gar nicht anders es gibt keine Möglichkeit, 100 als open zu verwenden und 0 als closed. du kannst natürlich Geräte anbinden, die das intern verkehrt verwenden, dann musst Du es in openHAB aber umdrehen, mindestens über eine entsprechende Konfiguration (invertieren der Laufrichtung).

0 = OPEN und 100 = CLOSED kommt übrigens nicht von ungefähr: Ein Rollladen ist in seiner Funktion das komplette Gegenteil eines Dimmers. Ein Dimmer kann ein dunkles Zimmer heller machen oder auch nicht. Wenn die Lampe aus ist, wirkt der Dimmer zu 0 %, auf hellster Stufe wirkt der Dimmer zu 100 %. Man kann mit einem Dimmer das Zimmer aber nicht abdunkeln, sofern gerade die Sonne scheint und der Raum Fenster mit geöffneten Läden hat.
Ein Rollladen kann das Zimmer abdunkeln. Wirkt der Rollladen zu 100 %, so ist das Zimmer komplett dunkel, wirkt er zu 0 % so ist das Zimmer so hell, wie es eben durch die Fenster herein kommt. Der Rollladen kann das Zimmer aber nicht heller machen. Denke dabei bitte an die Nachtstunden!
Aus diesem Grund ist in knx (und auch in openHAB) die obere Endlage als 0 und die untere Endlage als 100 definiert.
Leider haben andere Programmierer vergessen, wie die reale Welt funktioniert und deshalb willkürlich 100 als obere Endlage definiert...