Organisation Event Handling

[zeropage]

Moin!

Ich habe mit der Rule DSL inzwischen etwa 30 Rules programmiert. In den vergangenen Monaten bin ich dazu übergegangen die Rules anders zu organisieren und mich würde interessieren, wie ihr das so seht.

Ich vermute, die meisten haben wie ich damit angefangen, je Event eine Regel zu implementieren, die dann ein oder mehrere Aktionen auslöst. Das wirkt zunächst auch übersichtlicher. Als dann aber immer mehr Messwerte und Ereignisse hinzukamen, wurde das ganze unübersichtlich und führte schließlich zu unkontrolliertem Verhalten.

Nun habe ich eher je Aktor eine Rule, die auf alle erforderlichen Ereignisse reagiert. Also genau umgekehrt. Dadurch ist im Code besser zu erkennen, welche Bedingungen zu einem bestimmten Verhalten führen. Leider musst ich dazu aber zwei Nachteile hinnehmen: Im Body der Rule muss ich ggf. die Bedingungen ein zweites Mal prüfen. Und ich "weiß" im Body ggf. nicht mehr, was jeweils das Ereignis war. Insbesondere bei Ereignissen unterschiedlichen Typs.

Code: Alles auswählen

rule "Kitchen worktop light switch"
when
	System started or
	Item Kitchen_MotionSensor_Occupancy changed or
	Item sPresence changed or
	Item vDaylight changed
then
	var OnOffType state 

	// Determine new state
	if (Kitchen_MotionSensor_Occupancy.state == ON && sPresence.state == "PRESENT" && vDaylight.state != "SUNNY") {
		state = ON
	} else {
		state = OFF
	}

	// Publish new state, if changed
	if (Kitchen_Worktop_Light_Switch.state == NULL || Kitchen_Worktop_Light_Switch.state != state) {
		Kitchen_Worktop_Light_Switch.sendCommand(state)
	}
end

[udo1toni]

Grundsätzlich möchte ich davon abraten, diesen Ansatz zu verfolgen. openHAB stellt default nur 5 (+ 2) Threads für Rules zur Verfügung. Wenn Du nun Rules anlegst, die gleiche Trigger haben (weil verschiedene Aktoren auf gleiche Trigger reagieren sollen), kann es sein, dass die Threads knapp werden.

Wie Du aber schon erkannt hast, ist das andere Extrem auch nicht ohne Tücken. Der korrekte Ansatz liegt deshalb "in der Mitte".

Achte darauf, möglichst keine Rules mit gleichem Trigger anzulegen. Wenn der selbe Code mit unterschiedlichen Triggern ausgeführt werden muss, schreibe mehrere Trigger in die selbe Rule.
Wenn Du mehrere gleichartige Rules hast (z. B. diverse Temperatursensoren, die alle jeweils einen bestimmten Aktor steuern sollen), so kannst Du Groups verwenden und über Itemnamen, die sich anhand der triggernden Items "errechnen lassen" das jeweils passende Item heraussuchen, um es gemäß den eigenen Wünschen zu manipulieren.

Du kannst über die impliziten Variablen innerhalb der Rule immer eindeutig zuordnen, wie die Rule ausgelöst wurde.

receivedCommand enthält zum Beispiel das Kommando, welches die Rule getriggert hat. ist die Variable aber null, so wurde die Rule nicht durch ein Kommando getriggert.
previousState enthält den alten Status, newState den neuen Status, für den Fall, dass ein changed der Auslöser war.
triggeringItem enthält das Item, welches die Rule getriggert hat. Ist triggeringItem null, so muss ein Time cron oder System started verantwortlich für den Start der Rule sein (oder natürlich ein Channel Trigger... den kann man über receivedEvent erkennen)
Wenn man mehrere Time cron Trigger für eine Rule hat, kann man über entsprechende Abfragen den richtigen identifizieren.
Aber wie gesagt sollte das nur unter bestimmten Umständen eine Rolle spielen.

Unter OH3.x ist triggeringItem nur verfügbar, wenn die Rule mit Member of getriggert hat, sind einzelne Items der Trigger, so kann nur der Name über triggeringItemName ermittelt werden.

[zeropage]

Achte darauf, möglichst keine Rules mit gleichem Trigger anzulegen. Wenn der selbe Code mit unterschiedlichen Triggern ausgeführt werden muss, schreibe mehrere Trigger in die selbe Rule.

Ich bin nicht sicher, ob ich verstanden habe, wie du das meinst. Hättest du ein Beispiel?

Du kannst über die impliziten Variablen innerhalb der Rule immer eindeutig zuordnen, wie die Rule ausgelöst wurde.

Das ist mir grundsätzlich bekannt. Insbesondere Gruppen nutze ich gerne dafür. Nicht klar war mir, wie es sich bei Rules mit gemischten Triggern verhält. Abgesehen davon möchte ich noch erwähnen, dass ich aufgrund des Design Pattern: Time Of Day und dort Abschnitt "Rules DSL" zu meiner Vorgehensweise gekommen bin.