Also, grundsätzlich lassen sich solche Regeln eleganter erstellen, allerdings ist die Frage, warum das überhaupt als Dimmer angelegt wird, schließlich ist das gesteuerte Gerät ja gar nicht als Dimmer verwendbar.
Wie ist das Gerät angebunden (wie verbindest Du Dich mit Zigbee)? Es könnte sein, dass das Gerät falsch in der Datenbank hinterlegt ist. Mit Zigbee arbeite ich aber nicht, ich stochere da also genauso im Trüben.
Wie sendest Du denn das Stopp-Signal?
Hier dennoch mal eine Variante, wie ich das lösen würde, wenn es beim Dimmer Channel bleibt:
Gegeben für jeden Aktor ein Dimmer Item, Itemname entspricht der Form RSDim_Aktor, Wobei RSDim_ exakt so verwendet wird, das Wort Aktor wird durch ein eindeutiges Wort ersetzt, welches für jeden Shutter unterschiedlich ist. Wichtig: es muss exakt ein Wort sein, so dass das Item anschließend exakt einen Unterstrich enthält. Nun erzeugen wir dazu jeweils passend ein Rollershutter Item, dieses trägt den gleichen Namen, der vordere Teil lautet aber RSCtl_. Wir haben nun je Aktor zwei Items, z.B. RSDim_Wohnzimmer1 und RSCtl_Wohnzimmer1.
Weiterhin legen wir zwei Gruppen an, Typ der Gruppen ist egal, die eine Gruppe heißt gRSDim, die andere Gruppe heißt gRSCtl. Du kannst es Dir denken, alle Items, die mit RSDim_ anfangen kommen in die Gruppe gRSDim, alle Items, die mit RSCtl_ anfangen, kommen in die Gruppe gRSCtl.
Nun reichen zwei Rules:
Code: Alles auswählen
rule "RSCtl to RSDim"
when
Member of gRSCtl received command
then
val String strCtl = triggeringItem.name.split("_").get(1) // der Teil hinter dem _
val myItem = gRSDim.members.filter[i|i.name.endsWith(strCtl)].head // das passende Dimmer Item
switch(receivedCommand) {
case STOP: {
myItem.sendCommand(STOP) // hier noch korrekten Stop-Befehl einfügen
}
case UP: {
myItem.sendCommand(100)
}
case DOWN: {
myItem.sendCommand(0)
}
default: {
myItem.sendCommand(100-(receivedCommand as Number).intValue)
}
}
end
rule "RSDim to RSCtl"
when
Member of gRSDim changed
then
val String strDim = triggeringItem.name.split("_").get(1) // der Teil hinter dem _
val myItem = gRSCtl.members.filter[i|i.name.endsWith(strDim)].head // das passende Rollershutter Item
myItem.postUpdate(100 - (newState as Number).intValue)
end
Die Rules lassen sich auch über die UI erstellen, aber ich habe sie hier in der normalen DSL Notation angegeben.
Funktionsweise:
Die erste Rule triggert, sobald eines der Rollershutter Items einen Befehl sendet. Zuerst wird der eindeutige Teil des Itemnamens ermittelt, anschließend wird das passende Item aus der zweiten Gruppe herausgesucht.
Danach wird abhängig vom empfangenen Befehl der passende Befehl an das Item gesendet. Dabei habe ich hier berücksichtigt, dass der Aktor offensichtlich falsch herum arbeitet. In openHAB ist ein Rolladen zu 100% geschlossen oder zu 0% geschlossen, "oben" ist also 0 und "unten" ist 100.
Die zweite Rule nimmt die Rückmeldung des Aktors entgegen, das läuft genauso wie in der ersten Rule, nur wird hier statt sendCommand ein postUpdate verwendet, um die Position in das passende Rollershutter Item zu schreiben. Der Status ist ausschließlich 0 - 100, so dass der "aktive" Teil der Rule nur aus einer Zeile besteht.
Es ist essenziell, dass die Rules mit exakt den angegeben Triggern arbeiten, weil sich sonst eine Endlosschleife bildet.
Aber wie gesagt, das wäre nur die zweite Wahl, erst mal würde ich versuchen, herauszufinden, ob man das Gerät nicht auch korrekt mit Rollershutter Channeln einbinden kann...
openHAB5.0.1 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime) (Proxmox 9.0.11, LXC)
