KNX 2.x Binding verfügbar!

[alltime]

ok, ich habe die Lösung gefunden. Mein IP Interface hat keine Bus-Adresse bzw. ich kenne sie nicht , darum musste ich folgendes auskommentieren:
localSourceAddr="0.0.0"

seit dem geht es.

[alltime]

Ich habe das KNX Interface passend zum Wiregate. Soweit ich weiß hat das keine Beschränkungen. Ich werde nochmal mit den Reconnects rumspielen und weiter testen.

[magenbrot]

alltime wieviele gleichzeitige Tunnel beherrscht dein KNX IP-Router? Vielleicht ist der am Limit?

[udo1toni]

Kann ich so bei mir nicht beobachten, allerdings ist meine autoReconnectPeriod auch auf 30 eingestellt.
Ich bin mir auch ziemlich sicher, dass ein ständiges Wiederverbinden maximal die Bekämpfung eines Symptoms ist.
Wenn knx sauber aufgebaut ist, sollte es eigentlich gar nicht zu Verbindungsabbrüchen kommen...

[alltime]

Seit ich Openhab2 upgedated habe und das KNX Binding 2.0 verwende, kann ich mit der ETS keine Geräte mehr programmieren, wenn der Openhab2 Server angeschlossen ist. Alles andere funktioniert.

Dies ist ein Ausschnitt meiner Einstellungen in knx.things:

Bridge knx:ip:bridge [
ipAddress="192.168.178.26",
portNumber=3671,
localIp="192.168.178.68",
type="TUNNEL",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="0.0.0"
] {
//EG
Thing device Eingang [
readInterval=3600
] {
...

Habe ich etwas falsch eingestellt?

[udo1toni]

Uhrzeit und Datum funktioniert hier, wobei ich das nur kurz angetestet habe. Normalerweise kommt bei mir die Zeit aus openHAB heraus auf den knx-Bus, nicht umgekehrt.
Es gibt verschiedene DPT um Zeit und/oder Datum in knx zu übertragen, 10.001, 11.001 und 19.001(?), alle drei sind untereinander inkompatibel, und openHAB kann nicht selbsttätig entscheiden, welcher Typ der richtige ist. Das musst Du also eventuell mit angeben.
Weiterhin kann es notwendig sein, datetime-control als Channel Typ im Thing zu verwenden.

[hutzebutze]

Danke udo1toni. Ich hatte eigentlich alles richtig. Ein paar kleine fehler waren noch. Komma vergessen usw. Meine SD-Karte hatte einen Schaden. Musste alles frisch aufsetzen. Und wie ich dann im VS Codes auch noch die rest API unterstützung hin bekommen habe, wurden mir dann meine restlichen fehler gezeigt.
Interface ist online. Ich kann über Basic und Classic UI alles steuern und bekomme wohl auch feedback so weit ich das jetzt sehen konnte. App geht auch. Mich wundert es jetzt nur noch, dass die anderen knx things offline angezeigt werden. Nur das Interface zeigt es online. Aber scheint erst mal alles zu gehen. Was auch vorher nicht ging ist die Datum und Uhrzeitanzeige die ich von meiner Schaltuhr abrufen will.

[udo1toni]

Da ich selbst keine RGB Dimmer verwende, kann ich dazu nichts sagen, ich verfolge nur die Entwicklung des Bindings

[Julian0o]

der zuletzt hinzugekommene DTP 232.600 [RGB Dimmer, wird auch als HSB verwendet]

Hi, kann ich mit dem DTP 232.600 auch meine Tunable White Spots besser steuern? Aktuell habe ich dafür einen Dimmer und einen zusätzlichen Dimmer für die Farbtemperatur.

[udo1toni]

Welches knx/IP-Gateway nutzt Du? 0.0.0 als physikalische Adresse sollte dazu führen, dass das Gateway selbst entscheidet, welche Adresse openHAB erhält.

Wenn Du eine knx.things Datei verwendest (natürlich geht auch jeder andere *.things Name, aber es bietet sich an, Bridges, Things und Channel pro Hardware in eigene Dateien zu schreiben), ist es nicht notwendig, ja, sogar absolut schädlich, dies auch noch über Paper UI zu konfigurieren. Sämtliche Devices - Bridge und Thing(s) - sollten umgehend unter Paper UI -> Configuration -> Things auftauchen, die Bridge aus der Beispieldefinition unter dem Namen KNX/IP Interface, das zugehörige Thing hat kein Label, es könnte also sein, dass es tatsächlich unsichtbar bleibt. Definiere noch ein Label dazu:

Thing device generic "Mein Thing"[

dann taucht es unter diesem Namen in der Liste auf.
Die Channel kannst Du dann sehen, wenn Du das Thing aus der Konfiguration öffnest.
Natürlich sollte klar sein, dass dies nur lesbar ist. Keinesfalls solltest Du an dieser Stelle versuchen, etwas zu konfigurieren, wenn Du Bridge und Thing(s) über eine *.things Datei angelegt hast!

Das Anlegen der einzelnen Devices ist Tipparbeit. VSCode ist sehr mächtig, was paralleles Bearbeiten betrifft. Zum Beispiel führt <strg>+<alt>+Cursor hoch/runter dazu, dass der Cursor beginnt, in mehreren Zeilen gleichzeitig zu blinken. Wenn Du nun schreibst oder löschst, passiert das an allen Stellen gleichzeitig (sehr nett, um massenhaft gleiche Änderungen durchzuführen) - <ESC> beendet diesen Modus.
Ich habe meine Devices innerhalb 2 Stunden angelegt gehabt, zugegeben sind es auch nur ca.45 Stück mit ca. 170 Channels.

Die zugehörigen Items kannst Du bequem von VSCode erzeugen lassen. Dazu gehst Du in die zu erstellende *.items Datei an die Stelle, wo die Items hin sollen, klickst auf das openHAB-Plugin-Untermenü (linke Seite) und anschließend in der Things-Liste mit rechts auf das Thing, zu welchem Du Items erzeugen willst. Im Kontextmenü wählst Du den Punkt Create Items from Channels (natürlich werden die Items einen generischen Namen haben, der sich aus dem Namen des Things und den Namen der Channels zusammensetzt). Meine ca. 170 Items (knx betreffend) hatte ich innerhalb 3 Minuten erstellt. Die anschließende Arbeit besteht dann vor allem darin, Label anzupassen, Gruppen hinzuzufügen und allgemein die Formatierung zu verbessern, da VSCode die Formatierung nur anhand des aktuell ausgewählten Things ausrichtet. Trotzdem stellt dies in meinen Augen eine erhebliche Arbeitserleichterung dar.

Du kannst alternativ Bridge und Thing(s) auch komplett über Paper UI erstellen, aber da man die ganzen Adressen trotzdem eintragen muss, ist das eigentlich per *.things Datei sinnvoller (Stichwort Copy&Paste, Suchen&Ersetzen usw.)
Auch hier muss ich sagen, dass es sich ausgezahlt hat, dass ich meine GA vor einigen Jahren konsolidiert habe. Meine Ordnung ist hier:
Erste Stelle = Raumnummer (Außen ist ein Raum, raumübergreifende GA sind in einem eigenen Raum zusammengefasst - insgesamt bleibe ich unter 15 Räumen, also kein Problem)
Zweite Stelle = Typ (Schalten, Dimmen, Messen, Heizen, Rollläden...) auch hier komme ich auf weniger als 8 verschiedene Typen.
Letzte Stelle einzelne Funktion, soweit möglich auf der gleichen Nummer wie das Objekt, bei mehreren gleichartigen Devicekanälen innerhalb eines Raums ein Offset pro Kanal, also z.B. 1. Steckdose 0, 2. Steckdose 10, 3. Steckdose 20...)
Auf diese Art sind die GA ähnlicher Kanäle bis auf Details identisch, was bedeutet, dass ich ganze Things kopieren konnte und nur Einzelheiten ändern musste - Label des Things, Label der Channel, Teile der GA (zeilenübergreifend, siehe oben)

[hutzebutze]

Also da jetzt wieder meine Bridge offline sein soll, bin ich kurz vorm aufgeben. Ich werde nochmal die ganze Anleitung in der Dokumentation lesen. Ich bin jetzt total durcheinander da ich in verschiedenen Quellen lese. Binding über Paper UI installiert. Mit VScodes eine .things erstellt und in der .items die Adressen geändert. Warum muss ich dann in der Paper UI dann noch ein Thing für die Bridge und ein Thing "generic" erstellen? Oder ist das falsch? Ich sehe sonst meine Things nicht in der Paper UI. Müsste er sich das nicht aus der .things ziehen?
Dann werde ich wohl eine ganz neue items und things Datei anlegen. In der Things werde ich dann wohl auch jeden Aktor einzeln anlegen. Was wohl lange dauern wird. Für ne Abkürzung mit VScode bin ich zu blöd oder es geht nicht. Hab auch nicht so viel Zeit um mich da auch noch einzulesen.

In der Bridge muss ich meine Tunnel-Adresse eintragen. Mit 0.0.0 geht es nicht.

[DiMa]

Was meint Ihr, ist nun das neue Binding Produktions-tüchtig?

Läuft bei mir ohne Probleme.

[maschninka]

Es ist einfach so, dass die Konfiguration des knx2 Bindings anders verläuft als beim knx1 Binding. ....

Hallo udo1toni, Danke für deine Antwort

[udo1toni]

ich lese hier von vielen Problemen im Bezug auf OH2+KNX2.

Es ist einfach so, dass die Konfiguration des knx2 Bindings anders verläuft als beim knx1 Binding. Es gibt ein paar kleinere Kickligkeiten, weil knx2 strikter zwischen In und Out unterscheidet, was bedeuten kann, dass man zwei Channel verwenden muss, wo man mit knx1 mit einem Item auskommt. Außerdem habe ich schon mehrfach Fehlermeldungen gesehen, die eigentlich unsinnig sind - allerdings ohne die Funktion zu beeinträchtigen (z.B. wird angeblich versucht, Float auf einen Integer-DPT zu schreiben).

Allgemein kann ich sagen, dass knx2 stabil ist. knx1 hat mit doppelten Telegrammen zu kämpfen. Wenn dieses Problem bei Dir nicht auftritt, kannst Du ohne Probleme bei knx1 bleiben, allerdings wird das Binding irgendwann nicht mehr weiterentwickelt werden (der zuletzt hinzugekommene DTP 232.600 [RGB Dimmer, wird auch als HSB verwendet] wurde auch in knx1 integriert), es ist also auf jeden Fall sinnvoll, früher oder später umzusteigen.

[udo1toni]

Die localSourceAddr habe ich noch nicht verändert. Da ist doch eine freie Tunnel Adresse an meinem knx IP Interface gemeint, oder nicht?

Ich habe die Erfahrung gemacht, dass es eine freie physikalische Adresse sein muss. Wenn Du eine der Adressen des Gateway verwendest, kann es außerdem passieren, dass diese Adresse gerade belegt ist.
Wenn die Items korrekt gelinkt sind, müsstest Du die Things im Paper UI Control Bereich sehen (im other-Bereich, da Du kein Tag gesetzt hast). Siehst Du dort Werte?