KNX 2.x Binding verfügbar!

[udo1toni]

Hundere GAs in things und items einzuhacken ist doch einiges an Arbeit.

Ja, komplettes Autodiscovery wäre schon sehr angenehm.

Aber wie schon erwähnt: GA werden bei knx2 ausschließlich in den Channels eingetragen - ob nun über Paper UI oder in einer things Datei. Ich sehe jetzt wirklich nicht, warum das ein Rückschritt gegenüber knx 1 sein soll.
In den Items tauchen keine GA auf, dort sind nur Bezüge zu den vorhandenen Channels anzulegen. Wenn man VSCode verwendet, kann man recht bequem Channels als Items anlegen, für ein Thing alle Channels auf einen Schlag. Das relativiert die zusätzliche Tipparbeit schon mal etwas.

[irgendwer]

Der Entwickler des Bindings möchte auch eine advanced Version machen, welche das ETS Projekt einlesen und die Things automatisch importieren kann. Eventuell lassen sich sogar die items damit erzeugen. Ist aber bisher nur eine Idee. Damit würde aber nochmal vieles vereinfacht. Hundere GAs in things und items einzuhacken ist doch einiges an Arbeit.

[udo1toni]

vor allem wenn jede GA mehrfach definiert werden muss

Wo musst Du die GA mehrfach definieren? Mit knx2 werden die GA exakt einmal angegeben, nämlich pro Channel der Devices. In der *.items Datei wird ausschließlich der Channel angegeben, mit dem das Item verlinkt sein soll.

Mein nicht ganz bezog sich eher darauf, dass man natürlich nun für ein Item zwei Dateien hat, in denen Teile der Konfiguration liegen.

Die Konfiguration wird dadurch aber nicht zwingend unübersichtlich, eher im Gegenteil. Die Zuordnung der Channels zu den Things (also einzelnen Devices) erzwingt eine Struktur, die der Physik folgt. Die Items können weiterhin wild nach eigenen Kriterien sortiert sein, die Hardware ist aber logisch zusammengefasst. Mehrwert habe ich bereits oben erläutert.

Ich habe heute einen ersten Test begonnen (mein Produktivsystem läuft immer noch mit OH1.8) und mir gefiel auf Anhieb dieser Ansatz, die Hardware möglichst 1:1 in openHAB abzubilden, ohne jedoch die Flexibilität zu verlieren. Bisher wurden Verknüpfungen zwischen GA und Items in den *.items Dateien erledigt, nun geschieht das in den *.things Dateien. Bisher wurden mehrere Bindings hintereinander an die Items gebunden, nun bindet man Channels an die Items.

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

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

[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).

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

[agh]

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

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

[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

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

[agh]

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

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

[DiMa]

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

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