KNX 2.x Binding verfügbar!

[kkreuzer]

Hallo zusammen,

ich habe mich hier schon lange nicht mehr blicken lassen, aber heute will ich es mir nicht nehmen lassen: Nach einer Wartezeit von einigen Jahren haben wir endlich ein neues KNX-Binding für openHAB 2! Ein paar Infos finden sich in meinem Announcement im Forum und natürlich in der Dokumentation.

Ich würde mich über Eurer Feedback freuen und hoffe, dass es einige von Euch ausprobieren. Zumindest mit IP-Interface funktioniert es bei mir super stabil und ich habe es bereits im produktiven Einsatz - ihr sollt also keine Versuchskaninchen sein ;-).

Viele Grüße,
Kai

P.S.: Am Montag (19.3.) bin ich auf der L+B - wer Lust hat, mich dort zu treffen, kann mir gerne eine PM schicken!

[novamax]

Das sind ja gute Nachrichten - Ich habe es auch gerade drüben gelesen.

Was ich noch nicht so ganz verstehe (Neulingsuseralarm), ist die Aufteilung zwischen Things und Channels in der Doku. Ich muss in knx.things Adress-genau jedes einzelne Gerät unter things {...} als channel definieren, und dann nochmal in den knx.items Zeile für Zeile aus z.B. "light" ein "light [%]" machen und ein Icon zuweisen? Mehr scheint ja in der knx.items nicht zu passieren. Das war irgendwie in 1.9 simpler. Oder muss ich mich mit KNX 2.0 - Ich wage es nicht auszutippen - jetzt gar nicht mehr um die Config-Dateien kümmern?

[irgendwer]

In der .things Datei musst du die Things erstellen und die GAs zuweisen. Die Aktoren müssen dabei nicht angelegt werden (Doku: "This is however an experimental feature very prone to the actual on the KNX bus").

Um die Config Dateien musst du dich nicht unbedingt kümmern, das geht auch in der PaperUI. Wobei ich der Meinung bin das die Textbasierte Variante schneller ist.

[udo1toni]

Die Aktoren sollen schon angelegt werden - ein Thing repräsentiert ein Hardware Device, das entspricht also einem Aktor, einem Taster, usw... Ich bin mit nicht sicher, ob man auch einfach alle Channel unter einem einzigen Device anlegen kann, dann betrachtet man knx als Ganzes als ein großes Device, aber ein Thing braucht man ziemlich sicher.
Man kann (muss aber nicht) die Busadresse des Devices hinterlegen. Da kommt sofort der erste Vorteil zutage, man kann nämlich sehen, falls ein einzelner Aktor vom Bus getrennt wurde, und man kann auch darauf reagieren (z.B. Thing OFFLINE -> Alarmmeldung)
Soweit ist da auch nichts experimentell. diese Zeile: "This is however an experimental feature very prone to the actual on the KNX bus." bezieht sich ausschließlich auf die Funktion fetch. Damit können weitere Informationen aus dem Device ausgelesen werden, der Hersteller, die BCU-Version, Firmwarestand, bis hin zur Liste der Kommunikationsobjekte und verbundener GA. Letztere Informationen könnten, wenn das dann mal mit allen Systemen funktioniert, zur Auto Discovery und Autokonfiguration genutzt werden. Bisher sehe ich bei mir allerdings nur die minimalen Informationen, aber ich habe bisher auch erst ein Device eingebunden. Trotzdem eine sehr nette Funktion.

Die Konfiguration kann nun komplett über Paper UI erfolgen, wenn man das denn so haben möchte, der Weg über die Textdateien steht jedoch uneingeschränkt zur Verfügung. Der Vorzug gegenüber OH1 ist, dass die Channel-Schreibweise einheitlich ist, während die alten Binding-Konfigurationen sehr unterschiedlich formuliert wurden - die Abstraktion zum Binding passiert nun in den Things.
Das kommt natürlich erst zum Tragen, wenn in ferner Zukunft alle OH1 Bindings auf OH2 umgestellt sind.

[DiMa]

Wie kann ich denn das neue KNX-Binding installieren? In der Paper-UI wird mir nur 1.11.0 angezeigt.

[agh]

Moin, funktioniert das Switch UG_Heizung "Licht Heizungsraum" (gUG) {knx="1/1/1+<1/7/1"} jetzt nicht mehr?
Nach einem Update Openhab 2.3 Build 1231 geht meine KNX Anbindung nicht mehr. Die knx.cfg wird auch nicht mehr geladen. Offensichtlich gibt es jetzt nur noch die neue Version. Das bedeutet, dass ich alles neu machen muss. Dies habe ich auch nicht in der Paper UI gesehen sondern nur in HABmin.
Ohne Vorwarnung die alte Version einfach rauszuwerfen ist unfair.

Die neue Version habe ich auch schlichtweg nicht verstanden und finde sie zu kompliziert, wenn ich jetzt alle KNX Adressen in eine Datei.thing schreiben muss und nicht wie vorher z.B. proEtage.item.

[agh]

und sollte das alte KNX Binding wieder eingebunden werden - was ich hoffe -, kann ich dann beide nutzen und langsam umsteigen?

[agh]

Ich verstehe es nicht.
aus dem Beispiel:
KNX.thing readInterval=3600 ] { Type switch : demoSwitch "Light" [ ga="3/0/4+<3/0/5" ] KNX.item Switch demoSwitch "Light [%s]" <light> { channel="knx:device:bridge:generic:demoSwitch" }
Wenn ich diesem Beispiel folge, muss ich jede, wirklich jede GA in der Thing-Datei hinterlegen um sie in der Item.Datei noch einmal auf zurufen und sie z.B. einem Switch zuzuweisen. Folglich mache ich die ganze Arbeit zweimal und gewinne nichts an Übersicht im Gegenteil.
Das der Switch dann genauso heißen kann wie in der Thing-Datei macht es nicht unkomplizierter.

Derzeit habe ich meine Item pro Etage und in der Datei pro Raum sortiert, weiß also ziemlich schnell, wo ich was anpassen muss. Zukünftig müssen mehrere Dateien geändert werden. So habe ich es verstanden. Liege ich falsch?

[kkreuzer]

Ohne Vorwarnung die alte Version einfach rauszuwerfen ist unfair.

Das ist weiterhin vorhanden und wird auch nicht entfernt, siehe meine Antwort hier: https://community.openhab.org/t/open...d-1231/41956/8

[kkreuzer]

Wie kann ich denn das neue KNX-Binding installieren? In der Paper-UI wird mir nur 1.11.0 angezeigt.

Dann nutzt Du vermutlich die 2.2.0 Release Version von openHAB. Das neue Binding ist vorerst nur im 2.3 SNAPSHOT enthalten (und wird final mit dem 2.3 Release verfügbar). Falls Du apt nutzt, müsstest Du auf das unstable Repo wechseln.

[agh]

Danke, in der Paper UI war das nicht gesetzt, hat ja auch immer funktioniert.

[kkreuzer]

Um die Config Dateien musst du dich nicht unbedingt kümmern, das geht auch in der PaperUI. Wobei ich der Meinung bin das die Textbasierte Variante schneller ist.

Ich stimme beidem zu. Das neue Binding unterstützt alle UI Konzepte, es ist also möglich, sowohl die Things im Paper UI zu definieren als auch die Links zu den Items anzulegen. Da KNX üblicherweise doch eher komplex bzgl. der Konfiguration ist, vermute ich, dass die textuelle Variante über *.things Dateien für die meisten Leute zu bevorzugen ist. Die Links lassen sich aber durchaus recht komfortabel danach auch übers Paper UI anlegen und verwalten.

[udo1toni]

Ich verstehe es nicht.
aus dem Beispiel:
KNX.thing readInterval=3600 ] { Type switch : demoSwitch "Light" [ ga="3/0/4+<3/0/5" ] KNX.item Switch demoSwitch "Light [%s]" <light> { channel="knx:device:bridge:generic:demoSwitch" }
Wenn ich diesem Beispiel folge, muss ich jede, wirklich jede GA in der Thing-Datei hinterlegen um sie in der Item.Datei noch einmal auf zurufen und sie z.B. einem Switch zuzuweisen. Folglich mache ich die ganze Arbeit zweimal und gewinne nichts an Übersicht im Gegenteil.
Das der Switch dann genauso heißen kann wie in der Thing-Datei macht es nicht unkomplizierter.

Derzeit habe ich meine Item pro Etage und in der Datei pro Raum sortiert, weiß also ziemlich schnell, wo ich was anpassen muss. Zukünftig müssen mehrere Dateien geändert werden. So habe ich es verstanden. Liege ich falsch?

Nicht ganz. Bisher musste pro Item im Binding jede GA angegeben werden. Dies passiert nun im Channel (des Thing). Das Item wird nur noch mit einem Channel verbunden.
Die Abstraktion zur Hardware passiert also in der things-Datei, während in der items-Datei die Verbindung eines items zu einem oder auch mehreren Channels erledigt wird.

Da die Anbindung in OH1 schon sehr gut funktioniert hat, wird das vielleicht als Rückschritt empfunden, weil es plötzlich zwei Dateien sind, wo vorher eine reichte, aber zum einen funktioniert das OH1 knx Binding nicht bei jedem problemlos (von doppelten Telegrammen bis zu ständigen Verbindungsabbrüchen), zum zweiten kommt ja auch Funktionalität hinzu. Ich denke, es wird nicht mehr lange dauern, dann muss man die GA nicht mehr abtippen, sondern allenfalls noch den Channels zuordnen (welches Rückmeldeobjekt gehört zu welchem Schaltobjekt?) - es wird vielleicht auch eine Datenbank geben, in der alle verfügbaren Devices eingetragen werden können, so dass selbst diese Zuordnung automatisch erfolgen kann. Mit der fetch-Funktion kann jetzt bereits der Hersteller und die Firmwareversion ausgelesen werden, auch das Vorhandensein eines Devices kann überprüft werden (interessant z.B. wenn man Alarmschleifen über knx anbinden möchte).

Wer mit der alten Version keine Problem hat, kann ja auf unbestimmte Zeit ohne Probleme die Legacy-Version installieren (Das Feature muss nur aktiviert werden).

[agh]

Da ich nicht ganz falsch liege, wo ist der Vorteil? Die Doku gibt leider nicht soviel her, dass es mir ermöglicht alles zu erkennen.

Es wird doch nicht einfacher, sondern unübersichtlicher und komplizierter vor allem wenn jede GA mehrfach definiert werden muss. Dabei spielt es keine Rolle, ob die Daten in einer DB stecken oder nicht.

Nach meiner Sicht der Dinge sollte nur KNX das Thing sein und mein Item nach dem Motto Switch XYZ " was auch immer" {channel="knx:ip:uid:ga=1/1/1, ......} gestaltet werden können (oder geht das auch? Wenn ja, fehlt es in der Doku). Natürlich will man mit Variablen oder symbolischen Zuordnungen arbeiten. Diese "Zuordnungsliste" habe ich immer in der ITEM-Datei gesehen.

[novamax]

OK, das ergibt Sinn. Auf den ersten Blick scheint es nicht attraktiv, die gleichen Daten in zwei Dateien zu führen und dazu diverses doppelt tippen zu müssen und jede Änderung an zwei Orten nachhalten zu müssen. Da fragt man sich schon nach dem Mehrwert... Aber natürlich ist so ein Voll-Umstieg (hoffentlich) schon auch erstmal ein Invest in Effekte in der Zukunft...