KNX 2.x Binding verfügbar!

[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]

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]

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?

[henfri]

Danke.
werde es probieren!

[udo1toni]

Ja, den Unterschied kann man direkt in der Versionsnummer sehen. Die erste Ziffer steht für OH1 oder OH2 Binding.
Weiterhin gibt es bei einem OH1 Binding in Paper UI kein Thing. Bis auf den Eintrag in der Liste der Bindings ist ein OH1 Binding in Paper UI "unsichtbar".

Alle GA, die zu einem Channel gehören, werden gemeinsam angegeben, getrennt durch ein Plus-Zeichen. Die Konfiguration ist in Paper UI identisch zur Text-Konfiguration, nur dass in Paper UI einzelne Felder zu sehen sind, während in der knx.things Datei eine Zeile pro Channel üblich ist. (Es gibt auch Channel, die mehrere Eigenschaften vereinen, z.B. ein Rolladen kennt normalerweise mindestens 3 Eigenschaften, Langzeitbefehl, Kurzzeitbefehl und absolute Position (diese ankommend und abgehend). das sieht dann so aus:

Rollladenaktor 1. Kanal	GA	DPT
Langzeit	1/1/1	1.008
Kurzzeit	1/1/2	1.008
Position anfahren	1/1/3	5.001
Rückmeldung Position (lesbar, L-Flag gesetzt)	1/1/4	5.001

Das sieht in openHAB so aus:

Type rollershutter: ch1 "Rollladen 1" [ upDown="1/1/1", stopMove="1/1/2", position="5.001:1/1/3+<1/1/4" ]

Eigentlich sollte die Angabe des DPT unnötig sein, aber es gibt einen Bug in knx2, durch den der DPT nicht optional ist, sobald man mehr als eine GA angibt.
Das Kleiner-als-Zeichen (<) bedeutet, dass openHAB beim Start einen Read Request auf diese GA schickt. So sollte der Status von Anfang an korrekt angezeigt werden.
Ein einfacher Schalter hat auch eine Rückmeldung, aber der Channel hat nur ein Feld für die GA:

Type switch: ch1 "Schalter 1" [ ga="1.001:0/0/1+<0/0/2" ]

Die Regeln sind aber die gleichen. Auch hier ist die Angabe des DPT wegen des Bugs zwingend.

[henfri]

Hallo,

ich hatte "binding-knx - 2.3.0" ausprobiert. Das sollte dann doch knx2 sein, oder?
Wie gebe ich denn die hörende Adresse an?

Gruß,
Hendrik

[udo1toni]

knx2 ist vollständig über Paper UI konfigurierbar. Man sollte sich aber für eine Variante entscheiden, also entweder alles per knx.things Datei oder alles per Paper UI.

[henfri]

Hallo,

kann man die
listeningGA auch über das Web-Interface setzen, oder geht das nur über die Konfigurationsdateien?

Gruß, Hendrik

[udo1toni]

Wenn sich das Item im Log ändert, ist alles gut (naja, die Frage ist natürlich, warum das in Paper UI nicht korrekt angezeigt wird...)
Grundsätzlich ist es egal, ob Du ein Switch Item oder ein Contact Item verwendest. Das Contact Item kennt die Zustände OPEN, CLOSED und NULL, während die Zustände für Switch Items OFF, ON und NULL sind (NULL nur der Vollständigkeit halber...)

Paper UI Control ist als UI zum Bedienen eher ungeeignet. Man kann die Oberfläche nicht konfigurieren, es gibt etliche Darstellungsfehler (unter anderem auch, dass der Refresh unter bestimmten Umständen nicht funktioniert). Die Control Sektion ist eher als Testmöglichkeit gedacht, um mal schnell zu schauen, ob die Items schon das tun, was sie sollen. Ich bin mir auch nicht sicher, ob hier intensiv vorhandene Fehler beseitigt werden.

Für die tägliche Nutzung sollten stattdessen entweder Basic UI oder HABpanel genutzt werden. Basic UI wird über die Sitemaps konfiguriert (das geht bisher nur über Textdateien), HABpanel wird über einen grafischen Editor konfiguriert, der in HABpanel eingebaut ist. HABpanel bietet weitgehend freie Konfiguration, dafür sollte man sich aber schon mit html und Konsorten auskennen, während Basic UI, nun ja, eher Basic ist, dafür ist die Beschreibung aber sehr leicht verständlich, wenn man sich mal damit befasst hat. Sitemaps werden auch für iOS und Android App gebraucht (wobei es da auch Apps von Drittanbietern gibt, die aus der Reihe tanzen).

Wenn man für die Darstellung eines "Readonly" Items nicht das Default oder Switch Widget verwendet, sondern das Text Widget, gibt es keine Schaltflächen. Dabei ist es unerheblich, welchen Itemtyp man verwendet.
Dies ist eine minimale Sitemap mit zwei Widgets, die beide das selbe Item anzeigen:
daheim.sitemap

sitemap daheim label="Zuhause" {
    Frame label="Ein Kasten" {
        Switch item=mySwitch // Mit Schaltfläche
        Text item=mySwitch // Ohne Schaltfläche
    }
}

[fritzrichter]

Stoße gerade auf ein weiteres Problem!
Ich habe alle meine Fensterkontakte jeweils über dezentrale ABB Universal-Eingänge (ABB US/U4.2 Universal-Schnittstelle). Diese senden laut Gruppenmonitor beim Öffnen/Schließen 1.001 GA Signale. In OpenHab 2 kann ich diese nicht als "Contacts" zum laufen bringen. Verwende ich jedoch einen "Switch", dann funktioniert es. Aber ich möchte ja keinen Switch sondern lediglich eine Anzeige ohne Schreib-Möglichkeit. Habe in Foren gelesen, dass es irgendwas mit OpenClose und OnOff zutun haben soll, aber verstehen tu ich es aktuell noch nicht.

Ich habe auch die Datentypen in der ETS umgestellt, sodass diese jetzt erfolgreich als 1.019 senden. OpenHab logt diese Events auch erfolgreich:

2018-06-18 21:50:40.639 [vent.ItemStateChangedEvent] - SensorEGKamin_Fenster changed from CLOSED to OPEN

Dennoch ändert sich auf der Seite "Control" nichts...

[fritzrichter]

Macht Sinn... Besten Dank für die Antworten!

[udo1toni]

Naja, das kommt darauf an. Bei knx2 hast Du die Wahl, ob Du den gesamten Bus als ein Device betrachtest, oder jedes reale Device einzeln als Thing anlegst.
Bei letzterer Variante ist es dann das einfachste, ein zusätzliches Device anzulegen (das steht dann quasi für openHAB als Device). Für dieses Device kannst Du natürlich keine physikalische Adresse angeben, entsprechend bleiben die eckigen Klammern leer. Wahlweise kannst Du den Channel auch bei jedem anderen Device angeben, letztlich gibt es keine echte Abhängigkeit, sondern nur eine organisatorische.

[fritzrichter]

udo1toni vielen Dank für deine Antwort! Das werde ich nachher gleich mal ausprobieren. Eine Frage stellt sich mir dennoch. In dem neuen KNX2 Binding, muss ich die Channel ja einem Device zuordnen. Du sagtest ja selbst, es gibt nicht "das eine device", zu welchem Device packe ich dann mein number-control?

[udo1toni]

Es handelt sich um einen number channel, Du musst auch den DTP mit angeben. Allerdings haben Szenen bei mir bisher nicht richtig funktioniert, weil sie fälschlicherweise als Float übergeben werden (und openHAB kommt damit nicht zurecht - schon witzig, weil es ja openHAB ist, was da Float drauß macht). Aber vielleicht ist das auch schon gefixt, ich hab in letzter Zeit wenig Gelegenheit gefunden, weiter zu probieren,
Da es im Normalfall kein Device gibt, welches für die Szene zuständig ist, sollte der Channel eigentlich vom Typ number-control sein, so dass openHAB hier Befehle entgegen nimmt. Kann aber sein, dass es in diesem Fall egal ist.

Weiterhin ist es wichtig zu wissen, dass knx auf dem Bus die Szenen von 0-63 durchnummeriert, während man z.B. in ETS überall 1-64 zu sehen bekommt (oder 1-32 statt 0-31). Die Szene 1 wird also als Szene 0 über den Bus gesendet.
Entsprechend musst Du in openHAB auf die Szene 4 reagieren, wenn es in ETS die Szene 5 ist, denn openHAB verwendet die native Zählung von 0-63.

[fritzrichter]

Mal ne Frage an die Experten:
Ich habe einen KNX-Taster, der eine Szene "Gute Nacht" (Szene Nr. 5, GA: 0/7/5) sendet. Entsprechende Aktoren schalten dann überall das Licht aus, die Raffstores werden runtergefahren etc.

Mit OH und dem KNX2-Binding möchte ich nun auf dieses Szenen-Event lauschen und entsprechend dann weitere Aktionen durchführen (z.B. HEOS Lautsprecher ausschalten).

Kann mir jemand sagen, wie ich auf dieses Szenen-Event lausche? Was für ein Thing/Device/Item benötige ich um auf die Szene Nr. 5 auf der GA zu reagieren?