[Gelöst] [V1.5 RC 8] - KNX-Problem aus OpenHAB Container - Ausbleibende Confirmations

[gbglace]

Die Telegrammwiederholung ist eine Sicherheitsfunktion und nein die löst nicht erst im Sekundenbereich aus, so lange will ja niemand nach nem Druck auf nen Taster auf das Licht warten.

Sofern OH ACK sendet ist das ganze nur ein Symptom. Ursache ist bei Dir also die instabile Verbindung KNX zu IP, weil dann das ACK fehlt. Da die ETS auch Offline-signalisiert scheint es auch kein spezifisches OH Problem zu sein. Gibt es bei Dir eine komplexere LAN Infrastruktur als nur ne Fritze? Nicht auszuschließen, dass da irgendwelche Parameter nicht mit dem TWS harmonisieren.

[Robert_Mini]

Was mir noch auffällt:
Port 3674 in der ETS - hat die TWS KNX Schnittstelle nicht Port 3700?

Eventuell ist das der knxd der „Eigenentwicklung“?

Lg
Robert

[gbglace]

Robert meinst die ETS läuft dann indirekt über dem OH-Container? Müsste sie dann aber nicht auch die IP-Adresse vom OH-Container haben?

[StefanW]

Hallo Peter,

Ich bin aber verwundert das das Telegramm bereits nach weniger als 20 ms nochmal gesendet wird. Sind die KNX-Timeouts nicht eher im Sekundenbereich?

Nein, bei KNX TP ist das ACK (oder NACK oder BUSY) binnen 1,51 - 1,61 ms auf den Bus zu senden.

KNX ist ein sehr einfaches Protokoll das für 8 Bit Microconteoller entworfen wurden, so wie diese vor 30 Jahren (!) zur Verfügung standen. Da gibt es keine Sequenznummern die sich die Prozessoren merken sollten und komplexe Software die dann spätere Wiederholungen anfordert.

==> Jedes Paket ist sofort zu Acknowledgen, ansosnten wird bis zu dreimal wiederholt.

Wie sehe ich im KNX-Busmonitor des TWS ob ein Telegramm acknowleged wurde oder nicht? Ein Haken bei "Show ACK" hat nur Einfluss auf die r/a Telegramm-Paare aber nicht auf die w Telegramme.

Nicht in Deiner technischen Konstellation (soweit bekannt).

Diese Pakete wie ACK / NACK / BUSY werden NICHT im Stack hochgereicht und können daher von den Busmonitoren nicht gesehen werden, da diese i.d.R. im "virtuellen Busmonitor Mode" arbeiten, d.h. es ist in dieser Betriebsart kein echter Busmonitor, da nur verarbeitete "Digest" Pakete angezeigt werden.

Wenn Du im Timberwolf Busmonitor alles auf dem Bus sehen willst, musst Du eine weiteres Interface (Timberwolf USB TP-UART) anstecken und dieses nicht im Applikation-Mode benutzen, sondern als Logger. Dadurch wird der TP-UART Chip in den RAW-Mode geschaltet und der Busmontior in den "Real-Busmonitor-Mode". Dann sieht man auch die ACK / NACK / BUSY.

Bei KNX handelt es sich doch um einen Bus. Ein Busteilnehmer generiert ein Telegramm (z.B. mit einem neuen Helligkeits- oder Temperaturwert). Alle Busteilnehmer sehen das Telegramm, können es auswerten oder auch ignorieren. Aber die Teilnehmer die das Telegramm nutzen senden demjenigen der das Telegramm generiert hat nach meinem Verständnis keine Bestätigung.

Doch, in der gleichen Linie schon.

Es spielt keine Rolle wie viele Busteilnehmer den neuen Sensorwert auswerten. Es können 0 oder 10 sein.

Nun, bei 0 gibt es kein Acknowledge, bei 10 wird einer mit dem ACK anfangen und die anderen 9 sehen das (daher auch das auf 100 us enge Zeitfenster) und senden selbst nichts.

Das sieht im Busmonitor immer gleich aus.

Da du sehr vermutlich keine KNX Interface im "Real Busmonitor Mode" laufen hast, werden Dir diese Telegramme auch nicht angezeigt.

Es gehört zu den Besonderheiten des Timberwolf Servers, dass man mehrere KNX-Interfaces anstecken kann. Eines kann im Applikationsmodus laufen und das andere im Real-Busmonitor-Mode. Mit dem Busmonitor klemmt man sich dann auf das im Real-Busmonitor-Mode und sieht alles auf dem Bus, jede Störung, jedes Problem.

Allerdings bestätigt der Bus dem Teilnehmer das erfolgreiche Absenden des Telegramms. Soweit mein Verständnis eines Bus. Ich dachte bisher das das auch auf KNX zutrifft.

Wer ist den der Bus? Der Bus besteht aus zwei Drähten, einer 29 V Spannungsversorgung und einer Drossel (welche die Kurzschlüsse beschränkt, mit denen die Devices kommunizieren). In diesem Grundaufbau gibt es NIX aktives, das etwas macht.

Die ACKs kommen entweder von den Teilnehmern, welche die GA mit einem ihrer Objekte (nach Programmierung durch die ETS) assoziiert haben oder von Linienkopplern / Bereichskopplern.

Ja, die in den Screenshots sichtbaren GAs haben zum Zeitpunkt des Fehlers keinen Abnehmer, da OpenHAB nicht in der Lage ist den Tunnel zum TWS aufzubauen. Fahre ich allerdings OpenHAB zu einem Zeitpunkt herunter wenn wieder "alles läuft" (nach Neustart des TWS), dann habe ich diese Vervierfachung nicht obwohl "in die Luft" geschrieben wird.

Das ist der Punkt an dem wir ansetzen müssen. Dazu unten mehr.

Nach meinem Kenntnisstand ist es in KNX nicht Pflicht dass für ein geschriebenes Telegramm mindestens ein Busteilnehmer vorhanden ist der das Telegramm auswertet.

Kein ACK / NACK / BUSY bedeutet eben dann die gesehenen Telegrammwiederholungen, weil das sendende Device (Spezifikationskonform) von einem Fehler auf dem Bus ausgeht und daher das Telegramm wiederholt.

Oder stehe ich hier auf dem Schlauch? Wie gesagt, es handelt sich doch um einen Bus.

Ich weiß nicht was Du meinst. Ein Bus bedeutet nur, dass alle Teilnehmern an einer Leitung hängen.


Folgender Wunsch:

- OpenHAB herunterfahren und unten lassen
- Timberwolf Server durchstarten
- ETS im Tunnelmode mit dem Server verbinden
- Das längere Zeit so stellen lassen, ggfls. Verbindungstest mit der ETS ausführen

Wir wollen damit sehen, ob das beobachtete Verhalten - hier die Schnittstellenfehler mit der ETS - etwas mit OpenHAB zu tun haben.

Peter, wir nehmen die Sache sehr ernst und wir haben deswegen auch eine "Sondersitzung" der Entwickler gehabt. Bevor wir das näher untersuchen müssten wir aber wissen, in wie weit das OpenHAB eine Rolle spielt, daher machen wir hier einen Versuch und lassen es einfach aus und beobachten, ob sich am Verhalten der Tunnel etwas ändert. (Begründung: Es wurde die rein hypothetische Vermutung gehäußert, dass OpenHAB wegen der TunnelDisconnects immer wieder weitere Tunnel eröffnet und diese dann irgendwann ausgeschöpft sind und daher auch die ETS keinen freien Tunnel mehr bekommt). Wir diskutieren hierzu intern auch eine intensivere Protokollierung und auch Darstellung der Tunnelverbindungen auf der Oberfläche.

lg

Stefan

[StefanW]

Port 3674 in der ETS - hat die TWS KNX Schnittstelle nicht Port 3700?

Nicht unbedingt, die 3674 ist hier völlig in Ordnung

Stefan

[Matze76]

@peti69, wie sieht denn die Config-Datei deines KNX-Bindings aus? Hat der Parameter localSourceAddr den Wert "0.0.0" oder hast du ggf. eine Adresse drin, die vielleicht jetzt mit einer der TWS-Schnittstellen-PA´s kollidiert?

[gbglace]

Wir diskutieren hierzu intern auch eine intensivere Protokollierung und auch Darstellung der Tunnelverbindungen auf der Oberfläche.

Unabhängig des Problems, ein sehr interessantes feature. hier noch mehr Infos zu bekommen was gerade auf den 25 Tunnels so läuft.

Gern als FR in Release 1.x gesehen (x ^= 5)


Ansonsten sehr schöner Beitrag mit den vielen Hintergundinfos zum KNX, sicher für viele viel Neues dabei gewesen.

[peti69]

Hallo Stefan,

vielen Dank für Deine ausführlichen Erläuterungen. Ich habe viel neues dabei gelernt.

Meine Anmerkungen und Gedanken rund um den "Bus" in meinem vorigen Beitrag waren eher abstrakter Natur und haben ihren Ursprung in der Software-Architektur. Dank Deiner Erläuterungen habe ich jetzt verstanden dass der KNX auf den unteren Layern (TP) anders funktioniert als ich es bisher beim Begriff Bus gewohnt war. Mir ist auch klar geworden dass das was man im KNX-IP-Tunnel-Protokoll und im "einfachen" (virtual Mode) KNX-Busmonitor sieht nur die halbe Wahrheit ist.

Nun, bei 0 gibt es kein Acknowledge, bei 10 wird einer mit dem ACK anfangen und die anderen 9 sehen das (daher auch das auf 100 us enge Zeitfenster) und senden selbst nichts.

Heisst dass das ein Write-Telegramm für eine GA die nur von einem Tunnel-Client (und keinem TP-Busteilnehmer) ausgewertet wird nie ein ACK erhält? Oder sendet der Tunnel-Server (z.B. TWS) unabhängig von der GA immer ein ACK?

Wie oben erwähnt gibt es neben OpenHAB auch meine Eigenentwicklung die einen Tunnel zum TWS direkt aufbaut. Dieses Stück C++ Software (genannt weaver) stellt ein konfigurierbares Gateway zu MQTT, HTTP(S) und seriellen Devices (Thies Clima Sensor und optischer Auslesekopf für Stromzähler) zur Verfügung. Es könnte also auch der Auslöser sein. Ab und zu werden die L-Data.req vom TWS nicht innerhalb von 10 Sekunden beantwortet. Aktuell sendet weaver dann ein DISCONNECT REQUEST (Wiederholungen sind aktuell nicht implementiert). Im Anschluss daran wird dann mit einem CONNECTION REQUEST versucht die Verbindung wieder aufzubauen. Gelingt dies nicht wird der Versuch nach einer Minute wiederholt. Nach erfolgreichem CONNECTION RESPONSE wird alle 30 Sekunden ein CONNECTION STATE REQUEST gesendet. Der TWS schickt manchmal ca. alle 15 Minuten ein DISCONNECT REQUEST. Bisher konnte ich dabei leider keine Regelmäßigkeit erkennen. Der Grund ist mir daher unbekannt. weaver reagiert dann wie oben mit einem erneuten CONNECTION REQUEST das im Normalbetrieb auch positiv vom TWS beantwortet wird.

Folgender Wunsch:

- OpenHAB herunterfahren und unten lassen
- Timberwolf Server durchstarten
- ETS im Tunnelmode mit dem Server verbinden
- Das längere Zeit so stellen lassen, ggfls. Verbindungstest mit der ETS ausführen

Wir wollen damit sehen, ob das beobachtete Verhalten - hier die Schnittstellenfehler mit der ETS - etwas mit OpenHAB zu tun haben.

Den Ansatz kann ich gut verstehen. Allerdings übernimmt OpenHAB in meinem Haus sehr viel an Steuerungsfunktionen (Heizung, Warmwasser, Zirkulation, Alarmanlage, ...). Deshalb ist ein Abschalten eher schwierig. Wäre ein anderes Vorgehen denkbar? Vom weaver könnte ich Euch Trace Logs mit Hex Dumps der UDP-Nachrichten zur Verfügung stellen. Bei OpenHAB bin ich mir nicht sicher ob es ein Low Level Tracing gibt. Aber das lässt sich herausfinden. Kann man aus den internen Logs des TWS keine Rückschlüsse ziehen?

Wir diskutieren hierzu intern auch eine intensivere Protokollierung und auch Darstellung der Tunnelverbindungen auf der Oberfläche.

Das wäre super.

(Begründung: Es wurde die rein hypothetische Vermutung gehäußert, dass OpenHAB wegen der TunnelDisconnects immer wieder weitere Tunnel eröffnet und diese dann irgendwann ausgeschöpft sind und daher auch die ETS keinen freien Tunnel mehr bekommt).

Es sind bei mir 4 Tunnel in der ETS für den TWS konfiguriert. Ich meine mich erinnern zu können dass ich einmal in der Fehlersituation OpenHAB und weaver heruntergefahren hatte und die ETS sich trotzdem nicht zum TWS verbinden konnte. Beim nächsten Eintreten des Fehlers werde ich das überprüfen. Ich hatte auch den Fall dass die ETS mitten in der Applikationsprogrammierung mit einem Fehler ausgestiegen ist.

Viele Grüße,
Peter

[peti69]

Hallo @Matze76,

... wie sieht denn die Config-Datei deines KNX-Bindings aus? Hat der Parameter localSourceAddr den Wert "0.0.0" oder hast du ggf. eine Adresse drin, die vielleicht jetzt mit einer der TWS-Schnittstellen-PA´s kollidiert?

in meiner openhab.cfg (ich nutze noch OpenHAB 1) steht knx.busaddr auf 1.1.253. Ich glaube aber dass der TWS dass ignoriert und stattdessen die mit der ETS programmierte Adresse verwendet. Eventuell überprüft der TWS aber auch die übermittelte Adresse und akzeptiert sie, wenn sie aktuell frei ist. Zumindest beobachte ich im TWS/ETS-Busmonitor dass die in den Tunnel-Clients konfigurierten Adressen meistens nicht überschrieben werden. Nach meinem Verständnis kann es keine PA-Kollisionen (mehr) geben. Vielleicht kann uns @StefanW das im TWS implementierte Verhalten bzw. die dazugehörige KNX-Spezifikation erläutern.

Viele Grüße,
Peter

[gbglace]

Heisst dass das ein Write-Telegramm für eine GA die nur von einem Tunnel-Client (und keinem TP-Busteilnehmer) ausgewertet wird nie ein ACK erhält? Oder sendet der Tunnel-Server (z.B. TWS) unabhängig von der GA immer ein ACK?

Das kommt auf die Qualität der Tunnel benutzenden Software an ob die ein ACK generiert. Der TWS wird es nicht tun, da die tunnelkonsumierenden Elemente ja nicht mit einer ETS-Applikation auf den TWS programmiert wurden. Der TWS-KNX-Stack bzw. jede KNX-Schnittstelle weiß gar nicht, dass das IP-Gerät auf eine GA reagieren sollte.