Binäreingang wird von OH nicht erkannt

[Norick]

Ich habe in der ETS einen Binäreingang TB352 HAGER verwendet welcher beim drücken des Tasters mit der Adresse 4/0/0 in der ETS erkannt wird.

klingel.png

Was nicht geht ist, dass OH 4.1.2 diesen Tastendruck nicht registriert und die Rule nicht triggert. Ich habe den Taster als "Contact" wie folgt:

Code: Alles auswählen

UID: knx:device:Bridge:980eca8d2c
label: KNX Device Binaereingang B4
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  address: 1.1.17
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:Bridge
location: Technik
channels:
  - id: B4_Chn1
    channelTypeUID: knx:switch
    label: Klingel OG
    description: null
    configuration:
      ga: <4/0/0

Unter den logs sehe ich nur folgendes:

Code: Alles auswählen

[WARN ] [nx.internal.client.AbstractKNXClient] - Giving up reading datapoint 4/0/0, the number of maximum retries (3) is reached.

Hier muss es wohl einen Zusammenhang geben. Kann mir bitte jemand weiterhelfen?

Danke!

[udo1toni]

Die Meldung hat nichts damit zu tun, dass openHAB den Kontakt nicht gemeldet bekäme
Stattdessen kann openHAB den Zustand des Kontaktes nicht auslesen, das < ist zu viel.
Weiter kommt es darauf an, wie das Device konfiguriert ist. Gewöhnlich ist so ein Binäreingang für einen Klingeltaster so eingestellt, dass er beim Drücken der Taste eine 1 (bzw. ON) sendet, und damit hat es sich dann. Beim Loslassen wird keine 0 gesendet.
In der Folge gibt es in openHAB kein changed Event. Falls Deine Rule also auf changed triggert, ist das die Erklärung für die Nicht-Funktion der Rule (insbesondere, falls das Item persistiert und per restoreOnStartup wiederhergestellt wird)

Korrekte Lösung: mach das < vor der GA weg und lasse die Rule per received update ON triggern.

Alternativ (schlechte Lösung!) kannst Du im Device einstellen, dass das Device beim Öffnen des Kontakts aktiv eine 0 sendet, sowie für das KO das L-Flag setzen und sicherstellen, dass 4/0/0 die HAUP-GA des KO ist, dann wird beim Loslassen das Item in openHAB direkt wieder auf OFF geändert und eine Rule, die auf changed to ON triggert, wird wunschgemäß funktionieren.
Ist halt aufwändiger und verursacht doppelt so viel Datenmüll

[Norick]

In der ETS ist der Taster so eingestellt, dass beim Drücken eine 1 und beim Loslassen eine 0 gesendet wird - rising edge ON, falling edge OFF
Im OH habe ich das "<" weggenommen wie du meintest. Leider funktioniert es so noch nicht.

Gewöhnlich ist so ein Binäreingang für einen Klingeltaster so eingestellt, dass er beim Drücken der Taste eine 1 (bzw. ON) sendet, und damit hat es sich dann. Beim Loslassen wird keine 0 gesendet.

In der Rule habe ich es jetzt so eingestellt:

Code: Alles auswählen

triggers:
  - id: "1"
    configuration:
      itemName: KNX_Device_Binaereingang_B4_Klingel_OG
      state: CLOSED
    type: core.ItemStateUpdateTrigger

Müsste ich dann doch auf deine Alternative und schlechtere Variante ausweichen? Das müsste doch so eigentlich funktionieren? In der ETS hätte ich auch die Möglichkeit den Taster nur auf rising edge ON zu setzen (oder OFF).

[udo1toni]

Du hast einen switch Channel angelegt, dieser liefert ON bzw. OFF-

Nun wäre die erste Frage, was für ein Itemtyp sich hinter KNX_Device_Binaereingang_B4_Klingel_OG verbirgt. Handelt es sich um ein Switch Item, so wird dieses Item ebenfalls die Status ON bzw. OFF liefern. Handelt es sich hingegen um ein Contact Item (welches OPEN bzw. CLOSED als Status liefert), so wird nichts passieren, da CLOSED und ON nicht das gleiche ist, genauso wie OFF und OPEN. Du musst in diesem Fall entweder das Item auf Switch ändern (= Item löschen und neu erstellen) und ON auswerten, oder den Channel als contact Channel anlegen (auch da musst Du leider den Channel löschen und neu erstellen).

Wenn es nicht zwingende Gründe für falling Edge gibt, kannst Du das sparen. Du willst ohenhin nur auf eine der beiden Flanken triggern, das ist meist die steigende Flanke, Der knx Bus sendet beim Betätigen der Klingel eine 1, die 1 kommt in openHAB an und wird als update ON signalisiert.
Ein zwingender Grund wäre, wenn Du die Dauer des Tastendrucks messen wolltest was sicherlich vorkommt, aber (beim Klingelknopf) eher unüblich ist.

Ob das Signal als Switch oder Contact ausgewertet wird, ist letztlich egal, es gibt Argumente für und gegen beide Varianten.

[Norick]

Vielen Dank - das war dann die Lösung zu meinem Problem. Ich habe es nun angepasst!