knx1 --> knx2

[EdgarWallace]

Ich habe mich nach diesem Beitrag gerichtet, um endlich einmal auf das knx2-Binding zu migrieren (unter OH2.8 als Docker): https://zukunftathome.de/knx-2-bindi...ion-von-knx-1/

Ich habe nicht vor, die knx-Devices abzubilden, sondern möchte so schnell und einfach wie möglich umstellen. Daher habe ich erste einmal die knx.thing Datei erstellt (ich poste hier beispielhaft mal einen Switch):

Bridge knx:ip:bridge [
type="TUNNEL",
ipAddress="192.168.178.100",
portNumber=3671,
localIp="192.168.178.22",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=60, //optional, do not set <30 sec.
localSourceAddr="0.0.0"
] {
Thing device generic [
// address="1.0.181",
fetch=true,
pingInterval=300,
readInterval=3600
] {

Type switch:        Schalter_Entry                "Schalter_Entry"        [ga="8/0/71+<8/3/71"]

Dann habe ich meine default.items modifiziert:

Switch    Schalter_Entry          "Schalter_Entry"         (Lights)                ["Lighting"]    { channel="knx:device:bridge:generic:Schalter_Entry" }

Im Anschluß habe ich dann das knx1-Binding gelöscht und das knx2-Binding installiert. Das knx/ip-Gateway war auch online. Dann habe ich das Generic-Device erstellt, ohne IP-Adresse.

Es funktioniert aber nichts und ich sehe auch nicht irgendetwas bezüglich knx im LOG.

[udo1toni]

Da Du ein generic Thing verwendest, darfst Du keinen der Thing-Parameter setzen. address gehört zwingend zu einem festen Device. fetch bezieht sich zwingend auf ein festes Device, genau wie pingInterval, auch dieser Parameter ist zwingend auf ein festes Device bezogen. readInterval als letzter Parameter ist der einzige Parameter, der nicht vom Device abhängt. Aber gerade dieser Parameter sollte keinesfalls für ein generic Thing gesetzt werden.
readInterval bewirkt das zyklische Auslesen aller als lesbar markierten GA. Damit wird der Bus zyklisch maximal belastet. Es gibt nur einen Grund, diesen Parameter zu setzen, und das ist, wenn einzelne Devices nicht dazu gebracht werden können, von sich aus bei Wertänderung (oder zyklisch) den Status zu senden. Dann, und nur dann, sollte man von openHAB aus nachhelfen. Wenn man mit generic Things arbeitet, sollte man mindestens solche GA in ein eigenes Thing auslagern, um die Read Requests auf ein erträgliches Maß zu reduzieren.

der Begriff "generic" ist an dieser Stelle ein Name und darf innerhalb einer Bridge auch nur einmal verwendet werden. Solltest Du mehrere generic Things definieren wollen, musst Du sie unterschiedlich benennen, also z.B. generic1, generic2 usw., aber letztlich sind die Namen beliebig, solange sie sich an die Konventionen halten (Name beginnt mit Buchstabe, erlaubte Zeichen sind die Buchstaben des englischen Alphabets, die Ziffern 0-9 und der Unterstrich, Groß/Kleinschreibung wird berücksichtigt).

Notwendig sind für die Bridge nur der Parameter type und bei type TUNNEL die Paramaeter ipAddress und localIp, alle anderen Parameter sollte man möglichst (mindestens zunächst) weg lassen.
Dein erster Channel sähe dann so aus:

Bridge knx:ip:bridge [
    type="TUNNEL",
    ipAddress="192.168.178.100",
    localIp="192.168.178.22"
 ] {
    Thing device generic []
    {
        Type switch: Schalter_Entry "Schalter Entry"        [ ga="8/0/71+<8/3/71" ]
    }
}

Die Konfiguration beinhaltet sowohl die knx IP Bridge als auch das generic Thing sowie den ersten Channel des Things. Nach einem Neustart von openHAB muss die Bridge online sein, das Thing ist ohnehin online, und der Channel muss auf Status der GA 8/0/71 und 8/3/71 genauso reagieren, wie er einen Schaltbefehl von openHAB auf die GA 8/0/71 senden muss.

Wenn man über die things Dateien konfiguriert, sollte man nach Änderungen an der Datei openHAB neu starten, um ischerzustellen, dass die Änderungen auch in openHAB angekommen sind (alternativ müsste man zumindest in Paper UI kontrollieren, dass Bridge und Things exakt so konfiguriert sind wie erwünscht.)

[EdgarWallace]

Vielen herzlichen Dank für die Hilfe, ich habe einen Anfangserfolg. Sehe ich das korrekt, dass ich dennoch alle Channel in der PaperUI unter dem generic Device definieren muß? Ich war davon ausgegangen, dass das mit dem Textfile erledigt wäre...

[udo1toni]

Nein, in Paper UI musst Du nichts mehr machen, das ist mit dem Textfile erledigt.
Wenn nun allerdings Bridge/generic Thing und/oder Channel nicht in Paper UI auftauchen, dann hast Du einen Fehler in der Textdatei.

[EdgarWallace]

Noch einmal vielen Dank Udo. Ich bin gerade wieder zurück und habe den Fehler erkannt. Die Datei hieß nicht knx.things, sondern knx.thing.

[udo1toni]

ja, gern genommener Fehler.

[EdgarWallace]

Genau, kleine Ursache, große Wirkung. In der PaperUI habe ich dann anschließend zwei Generic Devices gehabt und das manuell eingepflegte Device löschen können. Jetzt habe ich noch die folgenden Effekte:

1.) Das KNX/IP Gateway ist jetzt doppelt erfasst - solle ich das untere Device löschne?
Bildschirmfoto 2020-09-15 um 09.01.06.jpg

2.) Die im Gegensatz zu den Type switch sind weder Dimmer, noch Rollershutter korrekt erfasst worden:
Bildschirmfoto 2020-09-15 um 09.01.46.jpg Bildschirmfoto 2020-09-15 um 09.01.29.jpg


Ist da dann doch manuelles Nacharbeiten angesagt? Hier mal zwei Beispiele aus der knx.things:

Type rollershutter:    Shutter_Oliver_Balcony            "Shutter_Oliver_Balcony"            [ga="8/4/2,8/4/8"]
Type dimmer:        Bed_Wall                        "Bed_Wall"                            [ga="8/0/11+<8/3/11, 8/1/11, 8/2/11+<8/6/11"]

[udo1toni]

Ja, das liegt daran, dass sowohl Rollershutter als auch Dimmer andere Bezeichnungen erwarten. Du weißt aber schon, dass es eine offizielle Dokumentation der Addons gibt, oder? Die ist sogar direkt aus der Paper UI verlinkt, aber zur Sicherheit hier nochmal, für den Dimmer Typ: https://www.openhab.org/addons/bindi...el-type-dimmer (rollershutter ist unmittelbar drunter).

[EdgarWallace]

Vielen Dank Udo, ja klar, hatte ich vorher alles durchgelesen, hier im Forum und die Doku, aber die Feinheiten bei Dimmer und Rollershutter habe ich dann leider übersehen. Danke für Deine Zeit.

[udo1toni]

Immer gerne