Hallo zusammen,
ich habe ein kleines Problem. In meiner KNX Installation habe ich eine umgekehrte Schaltung für meine Rollädenktoren (Unten ist Oben und umgekehrt).
Innerhalb der KNX Welt kann ich das noch per Parameter ändern (für den Tastsensor) . Der Aktor ist ein UP Aktor und kann nicht ohne weiteres die Verkabelung umklemmen ( sind auch 21 an der Zahl)
Meine Versuche per Rules in OH3 sind mangels Erfahrung alle gescheitert . Hat jemand eine Idee, wie ich den invert hinbekomme?
Bin über jeden Hinweis dankbar.
PS: Aktor und Sensor sind von Gira, falls das hilft.
Viele Grüße
Driton
OH3 Invert auf Rolladenaktor in KNX
- udo1toni
- Beiträge: 15249
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: OH3 Invert auf Rolladenaktor in KNX
Wer hat denn da gepfuscht? In knx kann man eben nicht einfach oben und unten vertauschen, denn oben (Rollladen vollständig geöffnet) ist immer 0 % und unten (Rollladen vollständig geschlossen) ist immer 100 %, so wie es auch sachlich korrekt ist. Und wenn man Aktoren UP verbaut, dann so, dass man dennoch dran kommt. Es gibt z.B. zu allen wichtigen Schalterprogrammen passende Blindplatten mit leerem Montagerahmen, die man auf die UP-Dosen drauf schrauben kann.
In openHAB kannst Du für knx die Steuerung aus dem gleichen Grund nicht umkehren, weil eben 0 % "vollständig geöffnet" bedeutet und 100 % "vollständig geschlossen". Nur spätere Systeme haben da keine klare Definition und deshalb gibt es dort auch in openHAB entsprechende Invertierungsfunktionen.
Damit Du die Dosen nicht öffnen musst, wäre es das einfachste, Du legst dreiundzwanzig weitere Items an, und zwei Rules. Items:
Die erste Rule wertet ankommende Status aus, rechnet sie um und leitet sie an das komplementäre Item weiter.
Die zweite Rule wertet abgehende Kommandos aus, rechnet sie um und leitet sie an das komplementäre Item weiter.
Der Punkt ist: Du kannst nun beliebig viele Itempaare dieser Art anlegen und jeweils den beiden Gruppen zuordnen. Du musst nur sicherstellen, dass jeweils der erste Teil des Namens innerhalb eines Paares identisch ist und auch kein weiteres Item mit identischem ersten Namensteil existiert. Der Name muss also innerhalb der jeweiligen Gruppe eineindeutig sein und über beide Gruppen muss es jeweils ein Paar geben.
Der zweite Teil des Namens ist unerheblich, aber da alle Items insgesamt eineindeutige Namen haben müssen, bietet es sich an, die jeweilige Funktion mit zu notieren.
Die Rules setzen ein paar Dinge voraus, z.B. verwende ich in der ersten Rule einfach newState as Number. das geht hier, weil der Status eines Rollershutter Items immer eine Zahl ist. Nur wenn openHAB startet, ist der Status der Items NULL, beim nächsten changed Ereignis aber hat sich der Status geändert und beinhaltet eine Zahl.
In der zweiten Rule verhält es sich ähnlich. Als Kommandos stehen exakt zwei Möglichkeiten zur Verfügung. Entweder die Befehle UP/STOP/DOWN, oder aber ein Sollwert 0 bis 100. Da die ersten drei Werte über switch schon ausgeschlossen wurden, kann default also nur noch eine gültige Zahl sein. Da wir eine Variable brauchen, in der wir alle möglichen Befehle speichern können, bietet sich String als Datentyp an.
Wie gesagt, diese beiden Rules kümmern sich um alle Items, egal wieviele Itempaare Du definierst.
In openHAB kannst Du für knx die Steuerung aus dem gleichen Grund nicht umkehren, weil eben 0 % "vollständig geöffnet" bedeutet und 100 % "vollständig geschlossen". Nur spätere Systeme haben da keine klare Definition und deshalb gibt es dort auch in openHAB entsprechende Invertierungsfunktionen.
Damit Du die Dosen nicht öffnen musst, wäre es das einfachste, Du legst dreiundzwanzig weitere Items an, und zwei Rules. Items:
Code: Alles auswählen
Group gRollKNX
Group gRollOH
Rollershutter roll01_knx (gRollKNX) {channel="knx:bridge:rollthing01:ch"}
Rollershutter roll01_oh (gRollOH) // keine Bindung an einen Channel!
Code: Alles auswählen
rule "Rollladen Status"
when
Member of gRollKNX changed
then
val String strName = triggeringItem.name.split("_").get(0)
val myItem = gRollOH.members.filter[i|i.name.startsWith(strName)].head
myItem.postUpdate(100-(newState as Number).intValue)
end
rule "Rollladen Befehl"
when
Member of gRollOH received command
then
val String strName = triggeringItem.name.split("_").get(0)
val myItem = gRollKNX.members.filter[i|i.name.startsWith(strName)].head
var String newCommand = ""
switch(receivedCommand.toString) {
case "STOP" : newCommand = "STOP"
case "UP" : newCommand = "DOWN"
case "DOWN" : newCommand = "UP"
default : newCommand = (100 - (receivedCommand as Number).intValue).toString
}
myItem.sendCommand(newCommand)
end
Die zweite Rule wertet abgehende Kommandos aus, rechnet sie um und leitet sie an das komplementäre Item weiter.
Der Punkt ist: Du kannst nun beliebig viele Itempaare dieser Art anlegen und jeweils den beiden Gruppen zuordnen. Du musst nur sicherstellen, dass jeweils der erste Teil des Namens innerhalb eines Paares identisch ist und auch kein weiteres Item mit identischem ersten Namensteil existiert. Der Name muss also innerhalb der jeweiligen Gruppe eineindeutig sein und über beide Gruppen muss es jeweils ein Paar geben.
Der zweite Teil des Namens ist unerheblich, aber da alle Items insgesamt eineindeutige Namen haben müssen, bietet es sich an, die jeweilige Funktion mit zu notieren.
Die Rules setzen ein paar Dinge voraus, z.B. verwende ich in der ersten Rule einfach newState as Number. das geht hier, weil der Status eines Rollershutter Items immer eine Zahl ist. Nur wenn openHAB startet, ist der Status der Items NULL, beim nächsten changed Ereignis aber hat sich der Status geändert und beinhaltet eine Zahl.
In der zweiten Rule verhält es sich ähnlich. Als Kommandos stehen exakt zwei Möglichkeiten zur Verfügung. Entweder die Befehle UP/STOP/DOWN, oder aber ein Sollwert 0 bis 100. Da die ersten drei Werte über switch schon ausgeschlossen wurden, kann default also nur noch eine gültige Zahl sein. Da wir eine Variable brauchen, in der wir alle möglichen Befehle speichern können, bietet sich String als Datentyp an.
Wie gesagt, diese beiden Rules kümmern sich um alle Items, egal wieviele Itempaare Du definierst.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 3
- Registriert: 25. Aug 2022 14:10
Re: OH3 Invert auf Rolladenaktor in KNX
Hallo Udo,
vielen Dank für deine ausführliche Antwort.
Ja der Elektriker hat sich da in der Aderauswahl falsch entschieden. Ich kann die Adern in 16 UP dies ändern, weil da noch Blindplatten davor sind.
Die anderen habe ich aus Schönheitssicht verputzt und wollte diese nicht wieder raus holen...wenn ich in 3-4 Jahren neue Farbe auf die Wände bringe, dann hole ich diese raus und verkabel diese dann richtig.
Ich probiere die nächsten Tage deinen Weg und berichte dann über den hoffentlichen erfolg.
Viele Grüße
vielen Dank für deine ausführliche Antwort.
Ja der Elektriker hat sich da in der Aderauswahl falsch entschieden. Ich kann die Adern in 16 UP dies ändern, weil da noch Blindplatten davor sind.
Die anderen habe ich aus Schönheitssicht verputzt und wollte diese nicht wieder raus holen...wenn ich in 3-4 Jahren neue Farbe auf die Wände bringe, dann hole ich diese raus und verkabel diese dann richtig.
Ich probiere die nächsten Tage deinen Weg und berichte dann über den hoffentlichen erfolg.
Viele Grüße