[Codebeispiel] Suche Beispiel für das neue KNX bindung in Verbindung mit einem Router?

[lo4dro]

Hallo,

in der Doku gibt es nur ein Beispiel zum Tunnel. Ich habe allerdings einen Router.
Meine alte Konfig sieht so aus.

# KNX gateway IP address
# (optional, if serialPort or connection type 'ROUTER' is specified)
#ip=10.101.1.96 #Physikalische Adresse
ip=224.0.23.12 #Multicast Adresse default

# Local KNX Binding bus address.
# Use it, when two or more openHAB Instances are connected to the same KNX bus.
# (optional, defaults to 0.0.0)
busaddr=1.1.100

# Ignore local KNX Events, prevents internal events coming from
# 'openHAB event bus' a second time to be sent back to the 'openHAB event bus'.
# Note: To send back events second time is a Bug, but for backward compatibility, the behavior is not changed.
# For new installations, its recommend to set "ignorelocalevents=true"
# (optional, defaults to false)
ignorelocalevents=true
# KNX IP connection type. Could be either TUNNEL or ROUTER (optional, defaults to TUNNEL)
# Note: If you cannot get the ROUTER mode working (even if it claims it is connected),
# use TUNNEL mode instead with setting both the ip of the KNX gateway and the localIp.
type=ROUTER

# KNX gateway port (optional, defaults to 3671)
# Note: If you use eibd, setting to 6720
port=3671

meine neue so:

Bridge knx:ip:bridge [
    ipAddress="224.0.23.12",
    portNumber=3671,
    type="ROUTER",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="1.1.100"
] {
    Thing device generic [
        address="1.1.101",
        fetch=true,
        pingInterval=300,
        readInterval=3600
    ] {
...
...

wenn das stimmt könnte man es in der Doku mit aufnehmen?

[udo1toni]

Wenn Du ein einziges (virtuelles) Device für den gesamten Bus verwendest, sollte weder address noch fetch=true noch pingInterval angegeben werden. Diese Angaben sind komplett hardwarebezogen und können mit einem virtuellen Device nicht korrekt funktionieren.

readInterval sollte nur dann gesetzt werden, wenn es nicht vermeidbar ist, und dann bitte nur für einzelne Channel (sprich, man sollte die Channel, die es betrifft, zumindest in einem weiteren virtuellen device zusammen fassen.)

Die knx.cfg geht in der Bridge auf, das sieht erst mal ganz ok aus.

[lo4dro]

Danke für deine Antwort.
Mit diesem "Thing device" bin ich noch am Knobeln.

Wenn ich das jetzt richtig Verstanden habe, dann baut man pro Aktor einen "Thing device"
Unter den Aktor kommen dann die GAs die den Aktor beeinflussen / steuern.

Ist eine Taster (Sensor) auch ein Thing device? (z.B. Raum Temperatur)
Bei einem Taster (Sensor) darf ich keine weiter GAs definieren?

Bridge knx:ip:bridge [
    ipAddress="224.0.23.12",
    portNumber=3671,
    type="ROUTER",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="1.1.100"
] {
    Thing device Schaltaktor 1 [
        address="1.1.51",
        fetch=true,
        pingInterval=300
    ] {
        Type switch ....
        .......
      }
}
{
    Thing device ROLLAKTOR ABB 1 [
        address="1.1.52",
        fetch=true,
        pingInterval=300
    ] {       
    Type rollershutter ....
        ......
      }
...
}

[udo1toni]

Du hast die Wahl, wie Du knx betrachtest:

• Entweder Du siehst das gesamte knx-System als ein großes virtuelles Gerät - dann legst Du nur ein generic Thing an, mit massenhaft Channels (bitte dann keine Parameter für das Thing angeben, also den Block zwischen den [ ] einfach leer lassen).
• Oder Du legst für jedes Device am knx Bus ein eigenes Thing an. Dann kannst Du davon profitieren, dass openHAB die Geräte regelmäßig anpingen kann, Du bekommst eine Online/Offline Anzeige pro Device. Die Funktion ist übrigens unabhängig von der Anzeige, wenn also ein Gerät Offline angezeigt wird, heißt das nicht, dass ein Schaltbefehl ins Nirwana geht.

Was die Definition der Channel betrifft, gibt es zwangsläufig eine Überlappung der GA bei Aktoren und Schaltern. Der korrekte Aufbau sollte folgendermaßen aussehen:

1. Alle Aktoren anlegen, je Kanal sowohl die Schalt-GA als auch die Rückmelde-GA eintragen. Bei Dimmern kann die ON/OFF-Rückmelde-GA entfallen, dafür dann dort sowohl Absolutwert setzen-GA als auch Absolutwert-Rückmelde-GA angeben. Gleiches gilt sinngemäß für alle anderen Aktor-Arten.
2. GA, für die es keine echte Rückmeldung vom Bus gibt (z.B. Szenen-GA) werden in openHAB als Type *-control angelegt - dann gerne in einem der Schalter, der diese GA sendet.
3. Sensor-GA (z.B. RTR Ist-Temperatur) wird für den jeweiligen Sensor definiert und ebenfalls als Type *-control definiert.
4. GA, die nicht eindeutig einem Schalter, Sensor oder Aktor zuzuordnen sind, werden in einem virtuellen Thing (Stichwort "generic") zusammengefasst. Das wäre z.B. Uhrzeit und Datum, welches von openHAB an den Bus geschickt wird, da es hier meist mehrere Empfänger gibt.

Jede GA sollte möglichst nur einmal in der knx.things-Datei vorkommen, wobei es auch Ausnahmen von dieser Regel gibt. Ich habe das Verhalten unter knx2 noch nicht getestet, aber in knx1 war es so, dass Telegramme, die von einer GA empfangen wurden, immer nur auf einem (dem 1.) Item gelandet sind, wenn die GA mehrfach mit Items verknüpft war. Dieses Verhalten ist auch logisch erklärbar und entspricht den Regeln des knx Busses. Auf openHAB-Seite sollte es auch unnötig sein, GA mehrfach zu nutzen, mit einer Ausnahme, nämlich, wenn man Jalousien hat und bei diesen nicht nur die Behanghöhe, sondern auch den Winkel einstellen möchte. Da die Kurzzeit-GA zum Stoppen der Fahrt gebraucht wird, muss diese doppelt angegeben werden (also bei zwei Channels). Das funktioniert trotzdem, denn die GA wird ja (ausschließlich) zum Senden verwendet.

Eine weitere Funktion ist der readInterval, über den alle GA eines Things, welche als lesbar (<) gekennzeichnet sind, periodisch ausgelesen werden, anstatt nur beim Systemstart. Dieser Parameter sollte nur dann gesetzt werden, wenn es keine andere Möglichkeit gibt (z.B. ein Sensor hat keine Option, periodisch zu senden oder auch bei Wertänderung zu senden, oder er sendet dann zu selten/zu häufig) - und logischerweise keinesfalls bei einem generic Thing, wo diese Funktion dann periodisch den gesamten Bus abfragen würde - mit entsprechender Last.

[lo4dro]

Hallo,

ich habe endlich wider Zeit gefunden das umzusetzen.
Es ist schon sehr genial für jeden Aktor ein einzelnes Thing zu definieren.
Die Übersicht wird deutlich erhöht.

Allerdings werden bei mir alle Aktoren im Status "UNKNOWN" angezeigt.
An was kann das liegen?

  [COLOR=#d4d4d4]{[/COLOR]
  [COLOR=#569cd6]Thing[/COLOR][COLOR=#d4d4d4] device generic [/COLOR][COLOR=#ce9178]"Platzhalter"[/COLOR][COLOR=#d4d4d4] [[/COLOR]
  [COLOR=#d4d4d4]] [/COLOR]
  [COLOR=#d4d4d4]    { [/COLOR]
 ...
[COLOR=#d4d4d4]    }[/COLOR]
  [COLOR=#569cd6]Thing[/COLOR][COLOR=#d4d4d4] device SWITCHFLUR [/COLOR][COLOR=#ce9178]"Lichtschalter Merten FLUR"[/COLOR][COLOR=#d4d4d4] [[/COLOR]
  [COLOR=#d4d4d4]address[/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#ce9178]"1.1.2"[/COLOR][COLOR=#d4d4d4],[/COLOR]
  [COLOR=#d4d4d4]fetch[/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#569cd6]true[/COLOR][COLOR=#d4d4d4],[/COLOR]
  [COLOR=#d4d4d4]pingInterval[/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#b5cea8]300[/COLOR]
  [COLOR=#d4d4d4]][/COLOR]
  [COLOR=#d4d4d4]    {[/COLOR]
  [COLOR=#d4d4d4]    }[/COLOR]
 }

[udo1toni]

Hast Du openHAB2 schon mal neu gestartet?

[lo4dro]

ja schon mehr mals

[udo1toni]

Dann scheint das durch den Router nicht anständig durch zu laufen. Ich habe nur ein popeliges knx/IP-Gateway, da funktioniert es ohne Probleme. Testweise könntest Du fetch = false setzen. der Online-Status ist nur vom pinginterval und angegebener address abhängig.