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:
Code: Alles auswählen
Type rollershutter : gS_Osten_Shutter "Rolläden Osten" [ upDown="0/3/18", stopMove="0/3/19", position="0/3/20+<0/3/21" ]
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).
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet