KNX Binding mit einem Thing -> kein Effekt

[schokole]

Hi zusammen,

leider habe ich nichts im Forum gefunden, und so langsam habe ich keinen Schimmer was ich noch probieren kann.

Die Umgebung:
openHAB 2.5
Docker-Container auf Synology DS218+

An sich läuft openHAB stabil. Meine Echos werden erkannt und ich kann sie auch in openHAB nutzen.

Leider bekomme ich nichts in Verbindung mit dem KNX-Bus hin.
Ich habe es versucht über die Oberfläche zu konfigurieren, aber ging nicht, daher jetzt per Files. Das hier ist die knx.things:

Bridge knx:ip:bridge [
ipAddress="224.0.23.12",
portNumber=3671,
localIp="192.168.XXX.XXX",
type="ROUTER",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="0.0.0"
]{
Thing device flur [
address="1.1.1",
fetch=true,
pingInterval=300,
readInterval=3600] {
    Type switch : flurlicht "Flurlicht" [ ga="0/1/40+<0/4/40" ]
    }
  
Thing device kueche [
address="1.1.1",
fetch=true,
pingInterval=300,
readInterval=3600] {
Type switch : kuechenlicht "Kuechenlicht" [ ga="0/1/60+<0/4/60" ]
    }
}

So.
Dann habe ich Bilder angehängt aus meinem ETS. Die GA gibts und ist verbunden (das Licht geht von den Schaltern aus an).
Im PaperUI ist alles "grün", mich hat nur die Address 0.0.0 des Bindings / KNX IP-Routers verwundert (siehe Screenshot).
Im Events-LOG sieht alles gut aus, aber im openHAB-LOG steht:

Giving up reading datapoint 0/4/40, the number of maximum retries (3) is reached.

Also ist da was nicht erreichbar - nur wo der Fehler liegt wird nicht geloggt (INFO und WARN werden beispielsweise geloggt).

Ich bin ziemlich ratlos und bin kurz davor eine VirtualBox mit Debian von meinem Win10 Rechner als Test zu nehmen - aber nur, wenn hier auf die Schnelle helfen kann - schon mal Danke vorab

Beste Grüße

Schoko

PS: Habe noch die Antwort des Gruppenmonitors auf die Status-Gruppenadresse hinzugefügt

[udo1toni]

Also, bei knx ist grundsätzlich weniger mehr. Das heißt, alles Parameter, von denen Du nicht exakt weißt, was sie bedeuten (und sie sehr bewusst entsprechend konfigurierst), solltest Du möglichst gar nicht konfigurieren, also auf dem default Wert lassen. Was hast Du für einen knx/IP Router?

Ein eindeutiger Fehler ist die doppelte Vergabe der selben physikalischen Adresse. Für die ersten Schritte solltest Du besser so konfigurieren:

Bridge knx:ip:bridge "knx Bridge" [
    type="ROUTER",
    // ipAddress="224.0.23.12", <- Default Wert
    // portNumber=3671,         <- Default Wert
    localIp="192.168.XXX.XXX" //, <- letzter Wert, braucht kein Komma
    // readingPause=50,         <- Default Wert
    // responseTimeout=10,      <- Default Wert
    // readRetriesLimit=3,      <- Default Wert
    // autoReconnectPeriod=1,   <- illegaler Wert, bitte vorerst auf Default lassen
    // localSourceAddr="0.0.0"  <- Default Wert
 ]{
    Thing device flur "knx Flur"[
        // address="1.1.1",  <- das muss eine reale physikalische Adresse sein!
        // fetch=true,       <- kann Probleme machen
        // pingInterval=300, <- nur sinnvoll mit physikalischer Adresse
        // readInterval=3600 <- nur bei bestimmten Devices sinnvoll
     ] {
        Type switch : flurlicht "Flurlicht" [ ga="0/1/40+<0/4/40" ]
    }
    Thing device kueche "knx Küche" [
        // address="1.1.1",  <- die physikalische Adresse muss eindeutig sein!
        // fetch=true,
        // pingInterval=300,
        // readInterval=3600
     ] {
        Type switch : kuechenlicht "Küchenlicht" [ ga="0/1/60+<0/4/60" ]
    }
}

Alles, was ich auskommentiert habe, ist überflüssig und kann im Zweifel weg. Das sieht dann so aus:

Bridge knx:ip:bridge "knx Bridge" [
    type="ROUTER",
    localIp="192.168.XXX.XXX"
 ]{
    Thing device flur "knx Flur"[] {
        Type switch : flurlicht "Flurlicht" [ ga="0/1/40+<0/4/40" ]
    }
    Thing device kueche "knx Küche" [] {
        Type switch : kuechenlicht "Küchenlicht" [ ga="0/1/60+<0/4/60" ]
    }
}

Die physikalische Adresse ist nicht zwingend notwendig, wenn, muss es aber die korrekte sein. Niemals ein Device als mehrere Things (mit angegebener physikalischer Adresse) anlegen! Ein Thing soll ein Device repräsentieren. Ein Thing kann beliebig viele Channel haben. Es ist sinnvoller, Things nach Geräten zu benennen, nicht nach Orten (ich habe das an anderer Stelle hier im Forum ausführlich erläutert). Die Channel hingegen kann man gerne nach Funktion benennen (also z.B. kuechenlicht), wobei ich persönlich es auch hier vorziehe, die Channel nach der Physik zu benennen und nur im Label einen Bezug zur Funktion herzustellen.
Sind die mit < markierten GA tatsächlich lesbar (d.h. das L-Flag ist gesetzt)?

[schokole]

Vielen Dank für deine sehr klare und ausführliche Nachricht!

Mein KNX IP-Router ist:
MDT KNX IP Router SCN-IP100.02

Ich muss gestehen, dass ich das Beispiel aus dem Buch Heimautomation von Stefan Heinle genommen habe und nur meine IPs etc geändert habe.
Mit der gestrippten Version habe ich ein anderes Verhalten und leider noch nicht das gewünschte Verhalten.

Was ist gleich?
Die Artefakte in PaperUI sind grün und scheint soweit alles zu passen
Egal wie ich die Schieberegler in PaperUI verändere, passiert einfach nichts. Es ist auch nichts im Gruppenmonitor in ETS sichtbar.

Was ist neu?
Im Log werden die beiden Fehlermeldungen ("Giving up reading datapoint") nicht mehr ausgegeben. Wobei es nicht richtig funktioniert.
Denn wenn ich PaperUI aufrufe und das Licht bereits an ist, wird es in PaperUI als ausgeschaltet angezeigt.

Sind die mit < markierten GA tatsächlich lesbar (d.h. das L-Flag ist gesetzt)?

:
Ich habe sie im ETS ausgelesen und bekomme die Ergebnisse auf den Bus:
2020-11-18 09_10_39-Window.png
Das L-Flag ist jeweils im KO des Schalters für den Status gesetzt:
2020-11-18 08_56_47-Window.png
Müsste passen oder?

Ich würde dann meine Things noch umbenennen, damit diese nicht nach Räumen sondern nach Geräten benannt werden.
Du hast geschrieben, dass du das an anderer Stelle bereits beschrieben hast, gerne schaue ich mir das an. Nur kenne ich den Beitrag nicht...


Vielen Dank im Voraus!

Schoko

[udo1toni]

Hast Du mehrere Linien? Sind evtl. im knx Router Filterlisten aktiv?

[schokole]

udo1toni, das war es!!
Ich kann mir gerade nicht wirklich erklären, weshalb es so eingestellt war, aber nun kann ich alles in OpenHAB schalten.

Habe die Things und Items umbenannt. Die Things heißen wie die Aktoren und die Items wie die Aktion, also beispielsweise:
Thing = schaltHager_1_1_2
Switch = ch_2_wz_essenlicht
Item = 10FachSchalterHager112Ch2WzEssenlicht
In dieser art hattest du es empfohlen, oder?

So bekomme ich schon viel hin. Dir nochmals vielen Dank!!

Welche Quellen (Buch / Tutorial / Schulung) empfielst du mir, wenn ich mich weiter in die Materie einarbeiten will?

Beste Grüße

Schoko

[udo1toni]

Habe die Things und Items umbenannt. Die Things heißen wie die Aktoren und die Items wie die Aktion, also beispielsweise:
Thing = schaltHager_1_1_2
Switch = ch_2_wz_essenlicht
Item = 10FachSchalterHager112Ch2WzEssenlicht
In dieser art hattest du es empfohlen, oder?

Öh. Ja, so in etwa. Bei mir hieße der Channel aber nur ch2, dafür das zugehörige Label "Licht Wz Essen" und das Item hieße dann WzLichtEssen, auf Itemebene interessiert mich ja nicht mehr, was für Hardware dahinter hängt.

So bekomme ich schon viel hin. Dir nochmals vielen Dank!!

Gerne

Welche Quellen (Buch / Tutorial / Schulung) empfielst du mir, wenn ich mich weiter in die Materie einarbeiten will?

Ich kenne nur das Buch von Marianne Spiller, welches allerdings auch schon älter ist (die Halbwertszeit für IT-Anwendungsliteratur bemisst sich ja an der Updatefrequenz der Anwendung...) - trotzdem ist das Buch sicherlich immer noch sehr zu empfehlen.
Tutorials habe ich mir nie angetan, ich bin ja schon "etwas" länger dabei (seit Version OH1.0...) entsprechend hätte ich höchstens ein paar
Details für mich mitnehmen können, hätte aber auf der anderen Seite sicherlich ständig mit den Augen gerollt...