Ich muss mich da dann doch noch mal einschalten...
Punkt 1: Ein Prozentwert ist ein Prozentwert. Er geht per Definition immer von 0 % bis 100 %. Es gibt verschiedene Optionen, den Prozentwert in openHAB hinein zu bekommen. Dass gerne Dimmer Channel verwendet werden, hat vor allem "historische" Gründe, platt gesagt hat der Dimmer halt schon immer dafür funktioniert, anders sieht es mit Number Channels aus, dort gabe es häufig (aber eben nicht immer) Probleme mit dem Faktor. Ein Number Channel sollte 100 % eben als 1,0 abbilden, nicht als 100, das ist manchmal schief gelaufen.
In openHAB4 ist knx "Unit aware", das heißt, es kann mit dem Datentyp QuantityType umgehen.
Im DPT ist oft auch die Einheit kodiert, z.B. 5.001 -> 1 Byte Integer als Prozent (0 - 100, mithin eine Auflösung von etwa 0,4 % bzw. 25/64). Wenn man also den korrekten DPT angibt, sollte knx ein passendes QuantityType Item (Number:<Werttyp>, z.B. Number:Temperature) mitsamt Einheit befüllen. Im Fall eines Prozentwertes muss man also darauf achten, dass zum einen der korrekte DPT, zum anderen aber auch der passende Itemtyp (Number:Dimensionless) sowie auch die dazu passende Einheit (unit="%") und in der State Description das passende Pattern (%.1f %% - ergibt die Anzeige des Prozentwerts mit einer Nachkommastelle und dem Prozentzeichen) gesetzt sind, sonst funktioniert das Ganze nicht.
Punkt 2: das < Symbol vor einer GA: Dieses Symbol hat exakt die Bedeutung, dass diese Gruppenadresse lesbar ist, also auf Read Requests reagiert. Es gibt durchaus GA, die auf Read Requests reagieren, aber ebenfalls auf Schreibbefehle reagieren, entsprechend bedeutet < NICHT, dass openHAB nichts an diese GA sendet.
Standardverhalten von openHAB ist, dass openHAB beim Systemstart jeder mit < markierten GA einen Read Request sendet. Dieser wird bis zu 3 mal gesendet, falls er nicht beantwortet wird (es gibt dazu extra einen Parameter in der Bridge - readRetriesLimit)
Es gibt ältere Devices, die nicht in der Lage sind, bei Wertänderung oder alternativ zyklisch eine GA zu senden, sondern zwingend auf einen Read Request warten. Ausschließlich für solche Devices gibt es die Möglichkeit, die Read Requests zyklisch zu senden (Parameter readInterval im Thing).
openHAB verhält sich ansonsten sehr ähnlich wie andere knx Komponenten, es gibt für jedes KommunikationsObjekt eine "Haupt-GA" (das ist immer die erste GA in einem KO). Wenn ein KO senden darf (das Ü-Flag ist gesetzt), dann wird ausschließlich auf der Haupt-GA gesendet, alle weiteren mit einem KO verknüpften GA dienen ausschließlich dem Empfang. Die Parameter eines knx Channels kann man sich als KO vorstellen, auch hier wird ausschließlich auf der ersten GA gesendet. Beispiel:
Code: Alles auswählen
Type rollershutter : ch1 "Kanal 1" [ upDown="1/1/1",stopMove="1/1/2",position="1/1/3+<1/1/4" ]
Die Notation ist alt, aber gut lesbar
Kanal 1 ist ein Kanal eines Rollladenaktors. Es gibt ein KO für Aufwärts/Abwärts (Langzeit), ein zweites KO für Aufwärts/Abwärts (Kurzzeit) und ein drittes KO (eigentlich sind das sogar zwei KO, weil openHAB hier bidirektional arbeitet) für die absolute Position.
Man kann also über 1/1/1 den Befehl für hoch/runter erteilen, über 1/1/2 ebenfalls den Befehl für hoch/runter (nur dass hier die Fahrt nach einer einstellbaren Zeit gestoppt wird) und über 1/1/3 kann man eine Sollposition senden. Der Aktor wird beim Stoppen des Antriebs auf GA 1/1/4 die aktuelle Position senden. Bei Systemstart sendet openHAB auf 1/1/4 einen Read Request, um von Anfang an eine korrekte Anzeige zu gewährleisten.
Voraussetzung ist natürlich, dass das KO zum einen auf Read Requests reagieren kann (L-Flag gesetzt) und zum anderen die 1/1/4 auch als erste Adresse im KO eingetragen ist.
Außerdem darf nur ein KO auf der GA das L-Flag gesetzt haben, dies ist im Allgemeinen das KO, welches den Status repräsentiert.
In "echten" knx Devices kommt es häufiger vor, dass mehrere GA an ein KO zugewiesen werden, das ist in openHAB eher eine Ausnahme - abgesehen von der Rückmeldung, die aber nur in exakt einem Parameter angegeben wird. Hat man z.B. einen Dimmer Channel, so gibt es gewöhnlich zwei Rückmeldungen, nämlich neben dem aktuellen Dimmlevel auch noch der Schaltzustand des Aktors (also ON oder OFF). Man sollte keinesfalls beide Rückmeldungen dem Channel zuweisen, sondern immer nur die Rückmeldung mit der höchsten Genauigkeit verwenden, bei einem Dimmer also über Position.
