KNX 2.x Binding verfügbar!

[marzoel]

Hallo,

ich starte seit meinem letzten Versuch von vor ein paar Jahren einen zweiten Anlauf mit openhab. Kann es wirklich sein, dass diese 4 Bit relativen Dimmersignale immer noch nicht richtig funktionieren? Mein Schalter beherrscht leider nur relatives Dimmen mit INCREASE/DECREASE/STOP. Ich wollte das Signal in einer 'rule' auswerten und dann an den eigentlichen Dimmer über ein anderes Protokoll weiterleiten. Leider triggert die 'rule' mit 'received update' nur auf das STOP-Signal, welches als UNDEF erkannt wird. Gibt es vielleicht als Alternative die Möglichkeit den Rohwert selbst auszuwerten?

[udo1toni]

Welches Binding verwendest Du? Wenn Du knx2 einsetzt, musst Du, um die Schaltbefehle in openHAB zu empfangen, einen Channel vom Typ dimmer-control verwenden. Dann allerdings gibt es kein received update, sondern nur ein received command. Ich hab schon lange nicht mehr getestet, was da als Befehl reinkommt, eigentlich dürfte es nur INCREASE/DECREASE geben. Siehe auch bei github die Definition von IncreaseDecreaseType.java

received update -> der Status wurde aktualisiert.
changed -> der Status hat sich geändert.
received command -> es wurde ein Befehl empfangen.

Ein Dimmer hat grundsätzlich einen Status vom Typ Number, eine Zahl zwischen 0 und 100. Man kann erzwingen, dass der Status als OnOffType zurückgeliefert wird. Der Befehl wird aber nie als Status abgespeichert, es sei denn, er ist vom gleichen Typ, sprich, wenn Du eine 50 als Befehl schickst, landet die 50 (vermutlich) im Status, aus einem OFF wird eine 0, aus einem ON eine 100. INCREASE oder DECREASE jedoch können nicht als Status gesetzt werden.

[marzoel]

udo1toni Vielen Dank!
Ich nutze das neue KNX2-Binding. Mit dem dimmer-control-Item bin ich weiter gekommen. Durch die Angabe der Frequenz im Thing klappt auch das relative Dimmen. Leider habe ich noch nicht geschafft, dass der ON/OFF- bzw. Dimm-Status zurück auf den knx-Bus gesendet wird (auch nicht wenn ich ihn explizit als read request anfordere). Wie kriegt man das hin? Mein Versuch siehe unten tut nicht...

Type dimmer-control : knxDimmer "Test" [ switch="1/2/36+1/2/39", position="1/2/38+1/2/40", increaseDecrease="1/2/37", frequency =200 ]

rule"controldim"
when
Item knxDimmer received command
then
logInfo("Dimmer command: ",receivedCommand.toString )
if (receivedCommand ==INCREASE)
...
elseif (receivedCommand ==DECREASE)
...
elseif (receivedCommand ==ON)
knxDimmer.sendCommand(ON)
elseif (receivedCommand ==OFF)

...
end

[udo1toni]

Ich bin jetzt ein wenig verwirrt. Dein Dimmer ist doch gar kein knx Dimmer?

Der Wandtaster kann Langzeit/Kurzzeit senden. Im Taster musst Du also sowas konfiguriert haben:

Kurzer Tastendruck -> GA 1/2/36 (ON/OFF, DPT1.001)
Langer Tastendruck -> GA 1/2/37 (INCREASE/DECREASE, DPT3.007)
Rückmeldung ON/OFF vermutlich 1/2/39

Das bedeutet dann, dass Du den Dimmer-control Channel so konfigurieren musst:

Type dimmer-control : knxDimmer "Test" [ switch="1.001:1/2/39+1/2/36", increaseDecrease="1/2/37", frequency=200 ]

Da Dein Dimmer kein knx Dimmer ist, bekommst Du den Status auch nicht von knx, sondern schickst den Status auf den Bus. Entsprechend muss die GA, über die Du den Status senden möchtest, als erstes angegeben werden.
Durch einen Bug im knx2 Binding ist die Angabe des DPT zwingend, sobald mehr als eine GA pro Parameter angegeben wird (switch="1.001:1/2/39+1/2/36" funktioniert, switch="1/2/39+1/2/36" funktioniert nicht.)

[marzoel]

vielen vielen Dank. Jetzt funktioniert mein Dimmer.
Mein Taster sieht so aus:

[LEFT][COLOR=#111111][FONT=Courier][SIZE=12px]Kurzer Tastendruck -> GA 1/2/36 (ON/OFF, DPT1.001)
Langer Tastendruck -> GA 1/2/37 (INCREASE/DECREASE, DPT3.007)
Status ON/OFF -> 1/2/39
Status Dimmen -> 1/2/40 DPT5.001[/SIZE][/FONT][/COLOR][/LEFT]

Der Channel nun wie folgt:

Type dimmer-control : knxDimmer "Test" [ switch="1.001:1/2/39+1/2/36", position="5.001:1/2/40+1/2/38", increaseDecrease="1/2/37", frequency = 200 ]

Die letzte Kleinigkeit die mir noch fehlt wäre, daß ich die Status 1/2/39 und 1/2/40 auf dem KNX-Bus auch aktiv lesen kann. Openhab scheint bei mir aber auf einen READ vom Bus nicht zu antworten. Muss ich das noch gesondert konfigurieren?

[udo1toni]

Ah. Das heißt, Dein Taster zeigt den Dimmlevel an? Cool...

Read Requests an openHAB werden bisher leider nicht unterstützt, aber soweit ich verstanden habe, soll das kommen. Bis dahin bleibt nur, eine Rule zu schreiben, die alle paar Minuten aktiv den Status auf den Bus schickt.

[Heeman24]

Hallo zusammen, ich habe heute leider etwas zu blind das Update von 2.2 auf 2.3 durchgeführt. Leider nun mit KNX2. Leider aus dem Grund, weil ich mein ganzes System in liebevoller Kleinstarbeit zusammengebaut habe. Ich war zum Schluss immerhin soweit, dass ich mir eine komplette Beschattung, in Abhängigkeit der Temperatur, der Türöffnung, und des akt. Sonnenstands (Zeit) aufgebaut habe.
Leider funktioniert dies und meine anderen Rules nicht mehr, da ich leider nicht kapiere wie ich von vorgehen muss... Immerhin konnte ich über die PaperUI schon das KNX/IP Gateway als online. Ich habe gelesen, dass ich nun alle Lampen, Rollos,etc. neu als Thing anlegen muss. So sah eine Lampe bei mir bisher aus:

Switch Licht_EG_Wohnzimmer_Steckdose    "Stehlampe im Wohnzimmer"    (EG_Wohnzimmer, gAlleLichter)    [ "Lighting" ]    {knx="2/4/96+<24/4/81"} 

und so mein KNX.cfg file:

ip=192.168.178.73
type=TUNNEL
localIp=192.168.178.33
# ignorelocalevents sollte auf true gesetzt werden, auch wenn der Parameter leider nicht die volle Wirkung entfaltet
#ignorelocalevents=true
# die Busadresse ist die DeviceID auf dem knx Bus. Es muss eine ungenutzte Busadresse eingetragen werden,
# möglichst aus der Linie, in der das IP Interface angeschlossen ist. Wenn ignorelocalevents auf true gesetzt wird,
# muss auch eine Busadresse angegeben werden.
#busaddr=1.1.222

Kann mir jemand helfen? Ich wäre euch sehr dankbar

[azzkikrboy]

Hallo Heeman24,

das Problem hatte ich vor kurzem auch ... mittlerweile habe ich meine kompletten devices auf die neue Syntax umgebaut. Wenn der Groschen erst einmal gerutscht ist, dann ist es gar nicht mehr so kompliziert. Anders halt.

Ja, in KNX2.0 brauchst du immer Things und Devices und Channels. Da hat's bei mir auch gehackt. Ich habe mich dann dafür entschlossen EIN Thing pro Raum anzulegen und darunter alle möglichen devices.
@all: Was haltet ihr davon? Für mich ist dies am übersichtlichsten.

Also mal ein Beispiel für die .things Datei

Bridge knx:ip:bridge "KNX-Gateway" [
ipAddress="10.x.x.x.x",
portNumber=3671,
localIp="10.x.x.x.x",
type="TUNNEL",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=60,
localSourceAddr="0.0.0"
]
{
Thing device EG_Kueche [
fetch=true,
pingInterval=300,
readInterval=3600
]
}
Type switch : EG_Kueche_Schrank "Light" [ ga="1/1/3+<1/4/3" ]
Type switch : EG_Kueche_Band "Light" [ ga="1/1/1+<1/4/1" ]
Type dimmer : EG_Kueche_Insel "Dimmer" [ switch="1/1/0+<1/4/0", position="1/3/0", increaseDecrease="1/2/0" ]
Type rollershutter : EG_Kueche_RL1 "Shade" [ upDown="2/2/1", stopMove="2/1/1", position="2/4/1+<2/5/1" ]
Type rollershutter : EG_Kueche_RL2 "Shade" [ upDown="2/2/2", stopMove="2/1/2", position="2/4/2+<2/5/2" ]
}

Dazu dann die passende .items Datei

// Küche
Switch EG_Kueche_Schrank  "Küchenschrank"     ["Switchable"]    { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Schrank" }
Switch EG_Kueche_Band       "Küchenband"         ["Switchable"]    { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Band" }
Dimmer EG_Kueche_Insel      "Küche [%d %%]"   ["Lighting"]         { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Insel" }
Rollershutter EG_Kueche_RL1 "Küche Rollladen [%d %%]"         ["Lighting"]     { channel="knx:device:bridge:EG_Kueche:EG_Kueche_RL1" }
Rollershutter EG_Kueche_RL2 "Küchentür Rollladen [%d %%]"   ["Lighting"].    { channel="knx:device:bridge:EG_Kueche:EG_Kueche_RL2" }

Damit sollte es funktionieren !

[zukunftathome]

azzkikrboy Ich habe mich dazu entschieden in der .things meinen Schaltschrank mit den Aktoren abzubilden. Das hat dann auch den Vorteil, dass ich den Status des Aktors auslesen kann.

Viele Grüße
Patrick

[udo1toni]

Grundsätzlich kannst Du auch die legacy Bindings aktivieren und das knx1 Binding installieren. Dann funktioniert die Installation erst mal wieder wie unter OH2.2. Das wäre natürlich nur, um etwas den Druck raus zu nehmen.
Leider gibt es nicht die Möglichkeit, die Items nach und nach umzuziehen, es geht nur knx1 oder knx2, nicht beides gleichzeitig.

Letztlich landet der Teil der Konfiguration, der vorher in der knx.cfg stand, in der Bridge-Konfiguration, die Thing-Ebene kommt dazu. Wahlweise einmal, (der gesamte Bus wird als ein Thing behandelt) oder per Device (mit dem Vorzug, die Hardware in Teilen monitoren zu können).
Natürlich kann man auch beliebig anders abbilden, wie azzkikrboy geschrieben hat, allerdings sollte man dann pingInterval und fetch ebenso weg lassen wie address, weil diese Parameter eben hardwarebezogen sind.
Die Channel beinhalten dann die Konfiguration, wie sie vorher in den Items direkt angegeben waren, in den Items wird stattdessen nun ein Link auf den Channel angegeben.

Der wichtigste Unterschied zu knx1 ist, dass die Channel eine Richtung haben.
Wenn openHAB eher als "Schalter" auftritt, also z.B. ein knx-Licht ein- und ausschalten soll, dann geht der Schaltbefehl in Richtung knx, aber nicht zurück, das heißt, wenn man einen Schalter in knx drückt, der das gleiche Licht schaltet, kommt in openHAB nur die Information an, dass das Licht nun eingeschaltet ist, aber nicht der eigentliche Schaltbefehl. Das wirkt sich dann so aus, dass Rules, die vorher problemlos mit received command getriggert wurden, plötzlich nicht mehr funktionieren. Dann muss man auf changed oder received update ausweichen.
Wenn man stattdessen von knx aus ein Licht steuern möchte, welches nur über openHAB erreichbar ist, muss man den Channel auf z.B. switch-control ändern, dann kommt der Schaltbefehl aus knx in openHAB an (dafür aber kein Status Update mehr). Dafür wird dann sendCommand() den Status auf knx-Seite setzen.

[Heeman24]

Danke euch drei schon mal für eure Hilfe. Ich habe nun testweise einfach mal die Daten von azzkikrboybei mir reinkopiert in der Hoffnung prinzipiell ein Gerät unter Things/Items angezeigt zu bekommen.

Bridge knx:ip:bridge "KNX IP Tunnel" [
    ipAddress="192.168.178.73",
    localIp="192.168.178.33",
    type="TUNNEL",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
]
{
Thing device EG_Kueche [
fetch=true,
pingInterval=300,
readInterval=3600
]
}
Type switch : EG_Kueche_Schrank "Light" [ ga="2/4/111+<24/4/95" ]
}

Nun erhalte ich unter Things das "KNX IP Tunnel" angezeigt.


Unter Items habe ich nun Folgendes:

// Küche
Switch EG_Kueche_Schrank  "Küchenschrank"   (EG_Wohnzimmer, gAlleLichter, gAlleLichterohneWZ)  ["Switchable"]    { channel="knx:device:bridge:EG_Kueche:EG_Kueche_Schrank" }

Es erscheint soweit auch in den richtigen Gruppen in der Sitemap, jedoch kann ich schalten wie ich will. Es reagiert nichts. Die Adressen vom Licht habe ich nur aus den alten Items ins Things kopiert. Sollte doch eigentlich funzen, oder habe ich einen Denkfehler?

[zukunftathome]

Die Konfiguration der Bridge passiert nur einmal ganz oben. Wenn du mehrere Things anlegst, wiederholt sich lediglich der Part mit { Thing device...... und dann natürlich die jeweiligen Devices.
Ich habe den Umzug meiner Installation unter https://zukunftathome.de/knx-2-bindi...ion-von-knx-1/ dokumentiert. Vielleicht hilft dir das ein wenig weiter

Viele Grüße
Patrick

[Heeman24]

Danke Patrick! Das werde ich mir jetzt mal reinziehen, ich habe schon gewusst, warum ich das Update erst im Urlaub anstoße... :-)
Auf deiner Seite war ich übrigens schon ein paar mal! Hat mir bereits bei dem ein oder andern Thema weitergeholfen.

Viele Grüße
Flo

[zukunftathome]

Super, freut mich, wenn es hilft Hab das Update auch eine Weile rausgezögert

[Heeman24]

Hallo Patrick, danke für deine Hilfe. Ich kann nun das erste Licht schalten, der Rest ist nun die Fleißaufgabe...
Der Fehler war übrigens - eine fehlende Klammer. Ich bin schon kurzzeitig verzweifelt, weil in der PaperUI nie das Thing auftauchte.