KNX 2.x Binding verfügbar!

[novamax]

Den reinen Taster würde ich auch nicht als Aktor, sondern als Sensor einordnen (wie gesagt, es sei denn, er wird auch ausgelöst, um etwas " zu tun", also LED schalten o.ä.). Ich wollte erst auch die Adresse meiner Taster erfahren, bis ich verstanden habe, dass die keine haben, sondern ich Leeradressen auf Vorrat anlegen und auf die Taster legen lassen muss, die ich dann später am eigentlichen Aktor oder in einer Logik auswerten muss.

[udo1toni]

Du kannst die Taster natürlich auch mit konfigurieren, aber wenn Du keine GA exklusiv auf einem Taster hast (z.B. um über openHAB die Lautstärke von Sonos zu steuern), würde ich dort die Channel nicht konfigurieren. Dann kann man trotzdem sehen, ob ein Device offline ist (wenn man das Feature nutzen möchte).
openHAB interessiert sich eigentlich nur für Aktoren und Sensoren (im Sinne von Messwerten also z.B. Temperatur), Schaltzustände fragt man nicht am Taster ab, sondern am Aktor.

[trexter]

Moin,

ja, außer du möchtest am Tastsensor selber etwas schalten, wie eine Benachrichtigungs-Led zum Beispiel.

Gruß,
Daniel

[Höhlenbär]

Ja das stimmt als meinst nur die Aktoren anlegen?

[trexter]

Moin,

der Tastsensor sendet auf der GA 1.1.1 doch bloß.

Gruß,
Daniel

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

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

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.

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

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

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]

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.

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

[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

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