Die Meldung zum Label kann ich so ohne weiteres nicht nachvollziehen. Natürlich müssen sich die Label unterschieden, aber natürlich dürfen Teile des Labels auch gleich lauten. Für Gruppengraphen mussten sich die Labels aber schon immer voneinander unterscheiden, das hängt mit dem erzeugen der Legende zusammen. Eventuell ist das Wort "Temperatur" zu lang, wobei mir nicht bewusst wäre, dass es da Einschränkungen gäbe. Workaround wäre, die Label anzupassen
Ein Rollershutter Channel beinhaltet die Parameter upDown, stopMove und position, dafür braucht es keinen separaten number Channel.
Was sind das für Kontakte? Ein vollständiger Rollershuter (normaler Rollladen, keine Jalousie) sähe so aus:
Code: Alles auswählen
Thing device aktR4_Abs "Rollos4 Abstell" [
address="1/1/110",
fetch=false,
pingInterval=600,
readInterval=0
] {
Type rollershutter : ch1 "Dach Nord" [ upDown="0/1/65", stopMove="0/1/165", position="<10/0/50" ]
}
Und passend dazu das Item:
Code: Alles auswählen
Rollershutter DG_Norden_Roll "Rolll. Nord[%d %%]" { channel="knx:device:bridge:aktR4_Abs:ch1"}
Du kannst die Höhe jederzeit auch unabhängig in einem eigenen Widget anzeigen:
aber gewöhnlich wird man die Höhe direkt im zugehörigen Widget zum Steuern des Ladens anzeigen (schon damit das Icon die Höhe dynamisch anzeigt).
Da der Wert eine Ganzzahl sein sollte, wäre die Formatierung über %d sinnvoller als %.1f.
Bezüglich der Umschaltung der Betriebsart von openHAB aus:
Ich habe das ja oben erwähnt, und das Stichwort Triton lässt mich ebenfalls aufhorchen...
postUpdate() wirkt grundsätzlich
ausschließlich auf den Status eines Items und führt nicht dazu, dass dieser Status an den Bus geschickt wird.
sendCommand() wirkt grundsätzlich ausschließlich als Befehl und wird neben dem Trigger für die Rules auch an den Bus geschickt.
Das Standardverhalten von openHAB ist jedoch, aus einem
sendCommand() den "wahrscheinlichsten" neuen Status des Items zu "schätzen" und umgehend ein passendes
postUpdate() auszulösen.
Bei Systemen mit aktiver Rückmeldung des Status sollte man diese Funktion mittels Parameter
autoupdate="false" unterbinden.
Du verwendest in Deiner Rule
postUpdate() um das Gerät zu steuern, das hat unter openHAB1 so funktioniert, weil das knx1 Binding sich hier falsch verhalten hat.
Das knx2 (bzw. jetzt knx3) Binding verhält sich nun korrekt, das heißt, es wird grundsätzlich ausschließlich
sendCommand() zum Bus weitergeleitet und im Gegenzug löst ein Telegramm
vom Bus grundsätzlich ein
postUpdate() auf das(die) verlinkte(n) Item(s) aus.
Ich habe oben das Wort "grundsätzlich" inflationär benutzt, was daran liegt, dass ich es im juristischen Sinne verwende. "Etwas ist im Grundsatz so", bedeutet, dass es mindestens eine Ausnahme von dieser Regel gibt. Das ist auch hier der Fall.
Das knx2(3) Binding bietet nämlich zusätzliche Channeltypen. Es gibt
switch und
switch-control,
rollershutter und
rollershutter-control,
number und
number-control usw.
Hintergrund ist, dass damit die Richtung der Kommunikation umgekehrt verläuft. Das bedeutet dann, Telegramme, die von openHAB empfangen werden, werden als
sendCommand() an die verlinkten Items weitergegeben, umgekehrt sendet openHAB nun ausschließlich
postUpdate() an den Bus.
ABER! Bitte setze jetzt nicht einfach
switch-control Channel ein, so funktioniert das nämlich nicht. Der Punkt bei
*-control Channels ist, dass man damit von knx aus Geräte steuern kann, die in openHAB eingebunden sind, und zwar ohne zusätzliche Rules. Typisches Beispiel wäre ein knx Wandtaster, mit dem man eine HUE Lampe ein- und ausschalten möchte.
Mit
switch Channel: Die GA wird als Status gewertet, eine Rule in openHAB reagiert auf das Status Update und sendet ein
sendCommand() gegen das HUE Item.
Eine weitere Rule kann dazu verwendet werden, dem knx Bus auf einer anderen GA mitzuteilen, dass die HUE Lampe eingeschaltet ist. Die Rule muss die Status Änderung der HUE auswerten und per
sendCommand() an den entsprechenden Channel senden; eventuell wird man den Channel gar separat anlegen müssen, weil es sonst zu doppelten Updates kommt.
Mit
switch-control Channel: Status-GA und Steuer-GA werden gemeinsam eingetragen, wobei die Status-GA (die in Richtung knx verwendet wird) als erste GA angegeben wird (knx Regel: nur die erste GA eines KO kann senden).
Der
switch-control Channel wird mit dem selben Item verlinkt, welches auch mit der HUE-Lampe verlinkt ist. (dabei kann es sich ausdrücklich auch um ein Dimmer oder Color Item handeln). Ende.
Wenn openHAB den Tastendruck empfängt, wertet es den Tastendruck als Command und leitet dieses an alle verlinkten Items weiter.
sendCommand() wird vom HUE Channel ausgewertet und an die Lampe weitergeleitet. Die HUE Lampe meldet die neue Helligkeit als neuen Status.
postUpdate() wird vom knx
switch-control Channel erkannt und an knx auf der ersten GA gesendet (OFF für Status 0, ON für jeden anderen Status).
Also die normalen Channel für alles, was in knx zuhause ist und entweder seinen Status an openHAB meldet oder von openHAB gesteuert wird.
Die *-control Channel für alles, was in openHAB zuhause ist und von knx gesteuert werden soll (oder wo in knx der Status ausgewertet werden soll).
Zum Beispiel Zeit/Datum:
Ein virtuelles knx Thing (also eines ohne echte Hardware auf knx-Seite), dort folgender Channel:
Code: Alles auswählen
Thing device Virtuell "virtuelle" [ ] {
Type datetime-control : wochenzeit "Zeit und Tag" [ ga="10.001:15/7/10" ]
}
Die GA 15/7/10 ist z.B. in allen RTR mit Display und Wochenschaltuhr als Zeitquelle hinterlegt.
Ein Thing für NTP:
Code: Alles auswählen
Thing ntp:ntp:home "Lokale Zeit" [hostname="1.de.pool.ntp.org",refreshInterval=120, refreshNtp=30, locale="de_DE", timeZone="Europe/Berlin"]
Alle zwei Minuten wird der Channel mit einer neuen Zeit beschrieben; jedes dreißigste Mal holt sich das ntp Binding zuvor die genaue Zeit vom angegebenen Server.
Ein Item:
Code: Alles auswählen
DateTime Buszeit "Zeit und Tag" {channel="knx:device:bridge:Virtuell:wochenzeit",channel="ntp:ntp:home:dateTime"}
Das funktionierte unter openHAB1 quasi genauso, allerdings nur durch einen Fehler in der Software
