KNX 2.x Binding verfügbar!

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

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

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.

[mawa]

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.

Gibt es eigentlich eine Möglichkeit, eine PaperUI Konfiguration als Things und Items zu exportieren / ausgeben zu lassen?
Wenn ich mich in ein neues Binding einarbeite, nutze ich oft erstmal PaperUI, aber dauerhaft will ich alles in den Config-Files haben.

[Höhlenbär]

Gibt es eigentlich eine Möglichkeit, eine PaperUI Konfiguration als Things und Items zu exportieren / ausgeben zu lassen?
Wenn ich mich in ein neues Binding einarbeite, nutze ich oft erstmal PaperUI, aber dauerhaft will ich alles in den Config-Files haben.

Ja das würde mich auch interessieren.

Ich habe auch mal probehalber in der Paper UI Items angelegt. Wo werden die denn gespeichert in dem Items Ordner ist nichts zu finden?
Und in dem Things Ordner auch nicht. Ein CSV Export/Import wäre der Hammer

[irgendwer]

Meint ihr es lohnt sich die physischen Geräte auch einzeln als Thing anzulegen? Ich hatte es erstmal nach Themen getrennt (Steckdosen, Licht, Rolläden, Temperatursensoren etc jeweils als eigenes Thing), aber nicht weiter auf die KNX Geräte herunter. Ich überlege noch was ich davon habe. Wenn ich es jetzt beim Umstige nicht mache, mache ich es später wohl auch nicht mehr.

[udo1toni]

Meint ihr es lohnt sich die physischen Geräte auch einzeln als Thing anzulegen?

Die Gruppierung pro echtem Gerät erscheint mir sehr sinnvoll, wenn die Busadresse des Busankopplers eingetragen ist, kann openHAB erkennen, wenn das Gerät nicht mehr mit dem Bus verbunden ist. Ich habe zur Zeit Spätdienste, so dass ich bei mir noch nicht über einen ersten Test hinausgekommen bin, aber ich habe einen Taster, der sich ab und zu aufhängt (so 2 bis 3 mal im Jahr...), wäre nett, das loggen zu können bzw. dann sofort Nachricht zu erhalten, und nicht erst, wenn meine Frau vergeblich versucht, im Bad das Licht einzuschalten.

Gibt es eigentlich eine Möglichkeit, eine PaperUI Konfiguration als Things und Items zu exportieren / ausgeben zu lassen?

Nein, die gibt es bisher leider nicht.
openHAB merkt sich diese Sachen in einer xml-Datei (ich glaube, es war xml). Es gab schon mehrfach Fragen, ob nicht ein Tool sehr hilfreich wäre, welches die Konfiguration dann in Textfiles bereit stellt. Allerdings hat das - bis auf die Möglichkeit, die Konfiguration über einen Editor zu ändern - keinen Vorteil. Man kann die xml-Datei(en) genauso als Backup sichern, um später das System wiederherzustellen, zur Laufzeit liest openHAB die Textfiles genauso in den Speicher ein wie die xml-files. Während man die Konfiguration über Texteditor gewinnt, verliert man gleichzeitig die Möglichkeit, über die UI zu konfigurieren.
Speziell bei knx ist es - zumindest mit dem derzeitigen Stand - unerheblich, ob ich die Erstkonfiguration manuell über Paper UI/HABmin oder über *.things Dateien vornehme (mal abgesehen vom Rahmen für Bridge und Things, die sind über die UI ja schon vorgegeben). Allerdings wäre es ja auch möglich, entsprechende Templates für alle OH2 Bindings in VSCode zu hinterlegen - dann ginge auch diese Arbeit leichter von der Hand.

[Höhlenbär]

Es gab schon mehrfach Fragen, ob nicht ein Tool sehr hilfreich wäre, welches die Konfiguration dann in Textfiles bereit stellt. Allerdings hat das - bis auf die Möglichkeit, die Konfiguration über einen Editor zu ändern - keinen Vorteil

Ja das wäre es tatsächlich zum Beispiel in einer CSV kann man schnell per Copy/Paste Items anlegen und hat, wie ich finde, einen bessern Überblick, über die Items.
Viele kommerzielle Programme leben ja auch vor, dass zum Beispiel Datenpunktlisten exportiert werden können. Die Konfiguration in der Datei war für mich absolut Ok und übersichtlich. Das war recht einfach zu erlernen und schnell durch zu kopieren. In einer GUI ist es leider nicht so möglich. Ich habe erst vor kurzem zu Openhab gewechselt und war davon beeindruckt und es war durch die Struktur einfach zu erlernen. Manifestiert war alle Items sind in dem Ordner Items zu finden. Egal ob SNMP, KNX oder die Lokalen Items. In eine Rule waren die auch schnell rein kopiert. Das empfand ich als Vorteil. Aber vielleicht habe ich auch den Weg noch nicht erkannt der zum Erfolg führt und es wird einfacher. Die wichtigste Frage ist muss ich alle Items jetzt neu über die GUI anlegen, oder kann ich die Items Datei im Ordner liegen lassen. Vermutlich nicht oder ?

[udo1toni]

Aber selbstverständlich kannst Du weiterhin alle Items ohne Ausnahme über *.items Dateien anlegen. Für ein OH2 Binding (knx2 ist ein solches) steht halt nicht mehr

{bindingname="bindingkonfiguration"}

sondern

{channel="logischer:pfad:zum:channel"}

am Ende der Item Definition.

Die GA können weiterhin textuell konfiguriert werden, nun halt in *.thing Dateien.
Die Konfiguration der Bridge erfolgt jetzt nicht mehr in knx.cfg sondern ebenfalls in einer *.things Datei - sinnvollerweise macht man das in einer Datei oder in einer Datei pro Binding. Damit ist die gesamte Hardware strukturiert abstrahiert.

[Höhlenbär]

Na dann ist ja alles in Butter ich warte nur noch auf die neue Schnittstelle, meine jetzige kann leider nur 1 Tunnel, dann werde ich das mal auf dem 2 System probieren.

[Höhlenbär]

Guten Morgen,

ich muss sagen ich habe es noch nicht verstanden. Im Beispiel steht das der Aktor mit der physikalischen Adresse angelegt wird. Soweit ok
Dem Aktor werden dann die Gruppenadressen zugeordnet richtig ?
Nun sind aber in der Regel mehrere Aktoren mit der gleichen Gruppenadresse verbunden. Muss dann diese Gruppenadresse immer allen Aktoren zugeordnet werden ?
Letztendlich sollte doch egal sein welcher Aktor die Gruppenadresse ändert wichtig ist das der Status in der Visu passt.Auch die Visu kann den Status der Gruppenadresse ändern.
Im Zweifel würde ich das so verstehen, dass ich die Topology aus der ETS hier noch einmal nachbilden muss. Und ändert sich dann nur dieGruppenadresse bei dem Objekt wo die physikalische Adresse übereinstimmt? Aber Aktoren senden ja in der Regel nicht sondern nur Sensoren. Ich habe grade nen Knoten im Kopf.

[udo1toni]

Innerhalb eines reinen knx Netzes mag es tatsächlich Aktoren geben, die ausschließlich über Zentral GA gesteuert werden. Spätestens die Rückmeldung ist exklusiv pro Kanal, wobei die Rückmeldung dann oft gar nicht, oder nur von einem der gesteuerten Kanäle ausgewertet wird.
Wenn man openHAB einsetzt, möchte man aber im Allgemeinen jeden Aktor einzeln steuern können. Das bedeutet nicht, dass die Gruppensteuerung über knx verloren geht, man muss nur zusätzlich exklusive GA in jedem Aktorkanal eintragen.
Wie erwähnt, die Rückmeldung ist ohnehin zwingend exklusiv pro Aktorkanal, auch darf nie mehr als ein Objekt pro GA das L-Flag gesetzt haben, um auf Read Requests zu antworten.
Jeder Aktorkanal sollte in einem Visusystem seinen Status aktiv melden, also über die Rückmeldeobjekte. Bei mir sind auch viele Taster mit dem Rückmeldeobjekt verknüpft, da nur so sichergestellt ist, dass die Toggle-Tasten den korrekten Befehl schicken, wenn ein Aktor z.B. über Szenen oder ZentralGA angesteuert wurde.

Die angesprochene Problematik ist also zum einen keine, abgesehn davon ist sie aber auch nicht OH2-knx spezifisch, sondern trifft auf ausnahmslos alle Visusysteme für knx zu.

EDIT: Ach so, man muss nicht zwingend alle GA eintragen, die einem Kanal zugeordnet sind... man sollte halt aufpassen, dass zumindest die Rückmeldung pro Kanal jeweils korrekt eingetragen und konfiguriert ist, dann spielt es keine Rolle, auf welcher GA ein Schaltbefehl eingeht.

[Höhlenbär]

Hallo Udo,

ich meinte das ein wenig anders. Also ich legen ein Thing an. Tastsensor x.x.x Taste1 GA 1.1.1
dann lege ich einen 2 Thing an einen Aktor y.y.y Kanal1 GA 1.1.1
Da habe ich die Adresse doch 2 mal?

[trexter]

Moin,

der Tastsensor sendet auf der GA 1.1.1 doch bloß.

Gruß,
Daniel

[Höhlenbär]

Ja das stimmt als meinst nur die Aktoren anlegen?