openHAB, KNX Binding, MDT-Sicherheitsmodul - Alarm T_Connect

[krak5]

Hallo zusammen,

ich habe folgendes Problem:
Bei mir läuft openHAB mit dem KNX Binding bereits seit längerem stabil. Jetzt ist bei mir seit kurzem das MDT Sicherheitsmodul mit eingezogen.
Leider geht das MDT Sicherheitsmodul in Verbindung mit openHAB in Alarm (blinkend - Programmierversuch blockiert). Wenn ich jetzt von openHAB etwas auf den Bus schicke kommt dies verzögert (5-60sek) an.

Folgendes wird mit im Busmonitor angezeigt, wenn openHAB 15.15.241 auf KNX z.B. 1.1.33 zugreift:

Sicherheitsmodul_T_Connect.jpg
Das Sicherheitsmodul unterbindet das spezifische Verbindungstelegramm T_Connect auf dem Bus, welches beim Programmierversuch im Verbindungsaufbau als erstes gesendet wird und geht somit in Alarm.

Meine Verbindung zu KNX:

Bridge knx:ip:bridge [
ipAddress="IP des MDT-Routers",
portNumber=3671,
localIp="IP der openHAB VM",
type="TUNNEL",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="0.0.0"
] {
Thing device D
[
address="1.1.6",
fetch=true,
pingInterval=300,
readInterval=3600
] {

Gibt es eine Möglichkeit wie T_Connect und T_Disconnect nicht von openHAB auf den Bus gelangt?
Kann man in der Verbindung zu KNX etwas anpassen?

Vielen Dank im Voraus,
Manu

Mein Setup:
- openHAB 2.5.11 (auf einem Intel NUC in einer VM)
- MDT IP Router
- MDT Sicherheitsmodul
- alle weiteren KNX Komponenten sind von MDT

[udo1toni]

Nein, da wirst Du das Sicherheitsmodul entsprechend konfigurieren müssen, dass openHAB eine sichere Anwendung ist.

Mir wäre auch nicht bekannt, dass das knx Addon in openHAB3 dahingehend irgendwie geändert wurde.

[wknx]

fetch=true,

Nimm das mal raus. Wahrscheinlich wird das Auslesen der Geräteparameter/Tabellen als Programmierversuch erkannt. (Siehe DeviceDescriptorRead in Deinem Screenshot)

[krak5]

Nein, da wirst Du das Sicherheitsmodul entsprechend konfigurieren müssen, dass openHAB eine sichere Anwendung ist.

Mir wäre auch nicht bekannt, dass das knx Addon in openHAB3 dahingehend irgendwie geändert wurde.

Hallo Udo,
das Sicherheitsmodul habe ich in allen verfügbaren Alarmauswahlen konfiguriert - das Modul unterbindet in jeder Auswahl das T_Connect (das Unterbinden von T_Connect ist auch die Ausgabe des Moduls, es soll das unbefugte programmieren unterbinden).
Warum nutz openHAB den Zugriff über T_Connect überhaupt?
Ich habe Testweise die Verbindung von Node-Red zu KNX überprüft - hier wird das T_Connect nicht benutzt.
Viele Grüße, Manu

[krak5]

Nimm das mal raus. Wahrscheinlich wird das Auslesen der Geräteparameter/Tabellen als Programmierversuch erkannt. (Siehe DeviceDescriptorRead in Deinem Screenshot)

Hallo wknx,

ich habe das fetch=true auskommentiert, gespeichert und openHAB neu gestartet - leider ohne Erfolg - T_Connect taucht weiterhin auf dem Bus auf 😞

Thing device D
[
address="1.1.6",
//fetch=true,
pingInterval=300,
readInterval=3600
] {

Ein Versuch war es Wert.
Sonst noch Ideen?
Viele Grüße, Manu

[wknx]

Sonst noch Ideen?

pingintervall wäre mein nächster Verdacht. Setzte den mal auf 0 zum deaktivieren, oder nimm die Adresse raus. Dann sollte nur noch Kommunikation auf GAs übrig bleiben.

Ich habe Testweise die Verbindung von Node-Red zu KNX überprüft - hier wird das T_Connect nicht benutzt.

Findet von Node-Red überhaupt irgendeine Kommunikation mit Geräteadressen statt?

[meti]

Vielleicht gefällt deinem Sicherheitsmodul ja nicht dass die Kommunikation von OpenHAB über 15.15.241 kommt - was ja über eine Tunnelverbindung auf 1.1.x eine ungültige Adresse ist. Versuch mal die Tunneladressen im KNX Router zu setzen.

Wahrscheinlich wird das Auslesen der Geräteparameter/Tabellen als Programmierversuch erkannt.

Sorry für das OT, aber mich würde interessieren was OpenHAB da alles ausliest - und wozu. Dachte immer das sei nur für ein "Gerät ist noch da"...

[holgerf]

Sofern die physikalische Adresse angegeben ist, setzt openHAB den Thing Status (ONLINE, ...) basierend auf einer Anfrage an diese Adresse. Das passiert denn periodisch (pingInterval). Ansonsten ist der Thing-Status eines Geräts immer ONLINE, solange die Schnittstelle ONLINE ist.
Das Ganze funktioniet dann auch nur, wenn deine Koppler die Kommuniktion an die physikalische Adresse nicht blockieren (sonst erscheint das Device als OFFLINE).

Ist zusätzlich fetch aktiviert, werden Informationen aus dem Gerät ausgelsesen (Hersteller, Firmware). Diese kann man dann über die UI unter Thing Properties einsehen (falls das Gerät etwas preisgibt).

Du kannst das Logging des KNX addons in

openhab-cli console
log:set TRACE org.openhab.binding.knx

erweitern. Dann siehst du besser, was im Detail passiert. Rückgängig machst du das dann mit

log:set DEFAULT org.openhab.binding.knx

.