openhabforum.de

Hallo zusammen,
ich lese zwar schon seit geraumer Zeit hier mit und habe mir auch schon sehr viele wertvolle Informationen aus dem Forum geholt, aber jetzt komme ich nicht mehr weiter:

Ich bin gerade dabei, mir eine Beschattungsautomatik für mein Haus (knx-Installation) zu basteln.
Hierzu habe ich in ETS Gruppenadressen für jede Himmelsrichtung (Ost, Süd, West) erzeugt und diese den jeweiligen Rollo-Aktoren zugewiesen.
Habe das auch mit der Positions- und mit der jeweiligen Rückmeldeadresse so gemacht.
Diese Gruppen habe ich nun folgendermaßen in OpenHab2 integriert:

Auszug knx.things: Da es sich hierbei nicht um einen Aktor, sondern eine Gruppe von Aktoren handelt, wusste ich auch nicht, welche Adresse (adress="1.2.3") ich hier angeben soll und habe sie daher einfach weg gelassen. So weit, so gut ...
upDown, stopMove und das Anfahren einer definierten Position funktionieren einwandfrei, nur die Rückmeldeadresse (0/3/21) liefert keine Werte.
Ich habe das schon fast so befürchtet ...

Im Logfile ist es auch ersichtlich, dass der Bus hier keine oder keine brauchbare Rückmeldung liefert: Gibt es denn trotzdem eine Möglichkeit festzustellen, auf welcher Position die Rolladen-Gruppe aktuell steht?

Gruß,
Roland

Aaaaalso...

So macht man das nicht

Das Erste ist mal, Du darfst Rückmeldeadressen nicht auf einer GA zusammenfassen. Rückmeldeadressen sind immer(!) exklusiv.
Da ein KommunikationsObjekt immer nur auf einer GA senden kann, darfst Du auch keine weiteren GA eintragen, bzw. das nutzt dann nichts.
Da Rückmelde GA allgemein lesbar sind, kommt es sofort zu einem Konflikt, wenn mehrere Kanäle auf derselben GA antworten.

Der zweite Punkt ist, dass Du natürlich eine knx GA zum Ansteuern verwenden kannst, dann aber bitte über die Szenensteuerung des Aktors. Ansonsten hast Du nämlich das Problem, dass unterschiedliche Läden (Länge des Ladens) bei gleichem Befehl (z.B. 50%) auf unterschiedliche Höhe fahren.

Üblich ist eher, die Beschattung einer Fassade diskret zu erledigen, heißt, Du steuerst über openHAB jeden Laden separat an. Da meist unterschiedliche Höhen angesteuert werden müssen, kann man z.B. die Sollhöhe in einer Hashmap speichern und dann alle Läden in openHAB gruppieren. Schau mal hier oder im englischen Forum, da gibt es zuhauf Beispiele.

Zu Deiner Thing Definition muss ich auch noch ein paar Worte verlieren

Grundsätzlich kann man GA beliebig Things zuordnen, da es ja keinen festen Zusammenhang gibt. Man könnte ein einziges Thing mit allen Channels zu Schalt-, Dimm-, Motoraktoren, Sensoren usw. anlegen. Natürlich gibt es dann keine physikalische Adresse.
Man kann alle Channel streng den Devices zuordnen, dann kann man (muss aber nicht!) die physikalische Adresse mit angeben.

Der Parameter fetch=true bewirkt, dass das Device regelmäßig nach Daten befragt wird. Ohne physikalishce Adresse ist der Parameter sinnlos. Aber selbst mit gesetzter physikalischer Adresse ist die Funktion mit Vorsicht zu genießen, sie ist experimentell und liefert auch nur bei bestimmten Devices ein Ergebnis (Maskenversion, Hersteller, Seriennummer... so Zeugs halt).

pingInterval ist ebenfalls auf die physikalische Adresse angewiesen, damit openHAB das Gerät regelmäßig anpingt. Auch diese Funktion ist eher nice to have (das Device wird dann offline angezeigt, falls es nicht auf den Ping reagiert hat).

readInterval sollte standardmäßig nicht gesetzt werden, da der Parameter ein zyklisches Einlesen der lesbaren GA dieses Things bewirkt. Normalerweise wird man aber zyklisches Senden oder Senden bei Änderung im Device aktivieren. Es gibt einige wenige Senoren, die kein zyklisches Senden unterstützen. Nur für diese Devices ist der Parameter nützlich.

Ich habe bei mir die Things pro Device organisiert, ein weiteres Thing mit allen "virtuellen" GA (zu denen es also kein Device gibt, welches für die GA zuständig ist, z.B. Szenen) und ein weiteres Thing, in dem die die zyklisch abzufragenden GA stehen habe (dieses Thing ist allerdings leer...)

Wenn Du auf den einzelnen Rollladenkanälen die Rückmeldung haben willst (ja, das willst Du ), musst Du die zweite GA mit einem + angeben, so: Aber wie gesagt, für die Gruppe geht das nicht, dieses Beispiel ist also nur ein Beispiel...

Wenn Du die Gruppe nicht in knx anlegst, sondern in openHAB, kann die Gruppe den zuletzt gesendeten Status abbilden (alternativ kannst Du den Status des Items gezielt über eine Rule setzen, des geht dann auch mit der knx Gruppe).

Hallo,
vielen Dank für deine sehr ausführliche und aufschlussreiche Antwort!
Wenn ich dich richtig verstanden habe, soll ich also die "Gruppen"-Rückmeldeadresse im ETS und im Thing wieder löschen, da sie
1.) eh nicht funktioniert
2.) zu Konflikten im Bus führen kann
Gut. Mache ich.

Das Thema mit der Szenensteuerung kann ich mir in meinem Fall jedoch sparen, da ich zufällig im ganzen Haus lauter gleich lange Rollläden habe. D.h. ich fahre immer eine ganze Hausseite auf den selben Prozentwert. Das funktioniert momentan bereits einwandfrei.

Für mein eigentliches Problem, nämlich festzustellen, ob die Rolläden einer bestimmten Hausseite noch nach unten verfahren, oder bereits oben sind, wenn die Sonne die Hausseite "gewechselt" hat, habe ich mittlerweile eine bessere Lösung gefunden:
Ich versuche jetzt nicht mehr den aktuellen Prozentwert der GA abzufragen (was ja nicht funktionieren kann), sondern ich "merke" es mir einfach mittels einer Boolean-Variable, sobald ich die Rollläden mittels "UP" ganz rauf fahre.
Das hat zudem den Vorteil, dass OpenHab diese Hausseite dann "in Ruhe lässt" und nicht bei jedem Zyklus (momentan alle 15Min) die Rollläden versucht nach oben zu fahren.
Das funktioniert tadellos.

Bei den einzelnen Rolladenkanälen habe ich übrigens bereits ein "+" drin. Das hatte ich zu Beginn auch bei der RolladenGruppe drin, aber dann mal versuchsweise entfernt. Natürlich hat auch das nicht funktioniert ...

Gruß,
Roland