KNX 2.x Binding verfügbar!

[udo1toni]

Du hast hinter dem type="TUNNEL" kein Komma stehen, also werden eventuell alle weiteren Parameter nicht korrekt berücksichtigt.

Wie immer auch hier der Hinweis: Code bitte immer als Code markieren, da die Forensoftware sonst eventuell auch Änderungen am Text vornimmt. Die Farben sind nett bei schwarzem Hintergrund, hier stören sie nur. Einfach den kompletten Text nach dem Einfügen markieren und jegliche Formatierung mit der entsprechenden Schaltfläche (Unterstrichenes T mit kleinem tiefergestellten x) entfernen. Das sieht dann so aus: (ich hab noch Leerzeichen ergänzt)

Bridge knx:ip:bridge "KNX/IP Interface" [
    type="TUNNEL"
    ipAddress="192.168.0.101", /*Ip des Interfaces*/
    portNumber=3671,
    localIP="192.168.0.110", /*Raspberry Openhab IP*/
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="15.15.242" /*Tunnel IP des Interfaces*/
] {
    Thing device generic [
    ] {
        Type switch : AlleLichter_gLicht "Alle Lampen" [ ga="0/4/0" ]
        Type switch : Licht_EG_Kueche "Licht Küche Hinten" [ ga="0/0/3+<0/0/19" ]

        Type dimmer : Dimm_EG_Wohnzimmer "Dimmer Wohnzimmer" [ position="5.001:0/0/33+<0/0/30", increasedecrease="3.007:0/0/7", switch="1.001:0/0/10+<0/0/22" ]

        Type rollershutter : Shutter_EG_Windfang1 "Windfang Hinten" [ upDown="2/0/0,2/0/5", position="5.001:2/0/36+<2/0/45" ]

Default Werte müssen nicht gesetzt werden, also kann z.B. portNumber weg gelassen werden, genau wie readingPause, responseTimeout und readRetriesLimit.
autoReconnectPeriod sollte nicht kleiner als readResponseTimeout gesetzt werden. Gerade wenn man grundsätzliche Probleme mit der Verbindung hat, sollte man hier erstmal mindestens 30 Sekunden eintragen, verringern kann man das dann immer noch.
localSourceAddr ist auch eine typische Fehlerquelle. Am besten erstmal weg lassen oder auf 0.0.0 setzen.
localIp ist falsch geschrieben (das p muss klein sein)
Am Schluss fehlt eine schließende geschweifte Klammer (vielleicht nur, weil der Code nur ein Ausschnitt ist?)
Bei Licht_EG_Kueche könnte es sein, dass Du zwingend den DPT mit angeben musst (ga="1.001:0/0/3+<0/0/19") (dazu gibt es einen Issue, der im aktuellen Nightly schon gefixt sein sollte)
Bei Dimm_EG_Wohnzimmer ist der Parameter increaseDecrease falsch gerieben, außerdem ist die Reihenfolge ungewöhnlich, auch wenn das keine Rolle spielen sollte.

[hutzebutze]

Danke, wie peinlich wegen dem Komma. Bestimmt 50 mal drüber gelesen. Immerhin zeigt er jetzt in der Paper UI beide Things online. Aber per sitemap oder Habpanel geht leider noch nichts. Port usw habe ich nun weg gelassen. Die localSourceAddr habe ich noch nicht verändert. Da ist doch eine freie Tunnel Adresse an meinem knx IP Interface gemeint, oder nicht?

[maschninka]

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

Was meint Ihr, ist nun das neue Binding Produktions-tüchtig? Andersrum gefragt: würdet Ihr es empfehlen bei einer neuen Installation auf KNX2 zu setzen oder doch lieber zu KNX1 greifen?

Zum Einsatzzweck: ich würde gerne SONOS mit KNX verheiraten, eventuell auch noch Alexa.

Danke schon mal für euere Anworten

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

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

[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

[DiMa]

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

Läuft bei mir ohne Probleme.

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

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

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

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

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

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.

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

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