KNXnetIP Tunneling und die Antoworten auf einen ReadRequest

[BliBlaBlo]

Hallo,
ich hab folgendes Problem.... Ich habe einen Weinzerl 730 und schicke ihm einige Read Anfragen. Das ganze mache ich von meinem iPhone aus, dass mittles VPN verbunden ist. Komischerweise geht es wenn ich 3G aktiviert habe wunderbar, bei einer Verbindung mittels GPRS nicht immer.
In den meisten Fällen funktioniert alles wunderbar, aber hin und wieder will er mir einfach keinen Status zurückgeben. Dann bekomme ich immer nur Service Confirmations (MessageCode 0x2E) zurück, anstatt von Service Indications (MessageCode 0x29) die dann den jeweilige Status dabei hätten.
Hat jemand vielleicht schon mal das gleiche Problem gehabt? Bzw hat eine Idee woran es liegen könnte?

Danke und Lg

[swenga]

Was bitte ist denn ein Read Request? Laut KNXnet/IP Wireshark plugin sind gueltige Service Type Identifier:
0x0201 SEARCH_REQUEST
0x0202 SEARCH_RESPONSE 0x0203 DESCRIPTION_REQUEST 0x0204 DESCRIPTION_RESPONSE 0x0205 CONNECT_REQUEST 0x0206 CONNECT_RESPONSE 0x0207 CONNECTIONSTATE_REQUEST 0x0208 CONNECTIONSTATE_RESPONSE 0x0209 DISCONNECT_REQUEST 0x020A DISCONNECT_RESPONSE 0x0310 DEVICE_CONFIGURATION_REQUEST 0x0311 DEVICE_CONFIGURATION_ACK 0x0420 TUNNELLING_REQUEST 0x0421 TUNNELLING_ACK 0x0530 ROUTING_INDICATION 0x0531 ROUTING_LOST_MESSAGE fragt sich, Swen

[BliBlaBlo]

Oh, ok... hab mich da ein bisschen falsch ausgedrückt.
Ich schicke einen TUNNELLING_REQUEST (0x0421), der im cEMI Telegramm das er schickt, eine Gruppenadresse nach deren Status abfragt.Macht das so mehr Sinn?
Lg

[swenga]

Grad nochmal drueber nachgedacht und da ist es mir ebenso aufgefallen, du meinst die Abfrage innerhalb des CEMI. Sorry, die Sache mit dem Wald und den Bäumen....

Hast Du mal parallel einen ETS-Monitor mitlaufen lassen und kannst sagen was auf dem TP passiert?

mfg Swen

[BliBlaBlo]

Die ETS zeigt mir an dass ein Read gekommen ist und dass auch eine Response gekommen ist (in der ETS kann ich auch den entsprechenden Status richtig sehen) nur wird halt diese Response nicht wirklich gesendet.
Aber wie gesagt, nur bei VPN Verbindung und wenn ich auf meinem Telefon 3G deaktiviere und dann auch nur mehr GPRS Empfang habe. Mich wundert es halt dass das mit meiner Verbindung zu tun hat... Und es geht meistens gut, nur halt hin und wieder nicht.
Kann es da einen Grund geben dass ich dann nur mehr Service Confirmations (MessageCode 0x2E) anstatt von Service Indications (MessageCode 0x29) bekomme?

Lg und Danke

[swenga]

Hallo,

liegen da evtl. timeouts dazwischen? bei gprs staut sich das ja wohl eher als bei umts. Jetzt wirds schwierig: Kannst Du den IP-Verkehr am IF mal mitloggen und da die Verzoegerungen zwischen TP und IP-Message ermitteln?

mfg Swen

[BliBlaBlo]

Werd ich mal versuchen sobald ich wieder in der Firma bin...
Kannst du mir aber vielleicht ein bisschen genauer erklären was ich da loggen soll?

Bezüglich des Staus von GPRS... wie ist da gemeint? Dass der interne Buffer vom KNX Gateway nicht reicht um die Nachrichten zu speichern bevor sie gesendet werden können? Das glaube ich nämlich nicht, da wenn ich keine Service Indication bekomme ja stattdessen Service Confirmations erhalte.

lg

[NilsS]

Vielleicht hats was mit der MTU zu tun
http://www.meinews.net/mtu-t245370.html

[swenga]

MTU glaub ich eher nicht, die Tunneling-Pakete sind bloss ein paar Bytes gross. Möglicherweise geht aber die Sequenz von Tunneling Request und Ack verloren. Und da ist die Schnittstelle empfindlich.
Bitte mal auf einem Rechner ETS und den Wireshark laufen lassen (dann hast du gleiche Zeitstempel) und dann mal verfolgen, wann eine korrekte Antwort auf dem TP als verkorkste Antwort auf dem IP landet. Dann an der Stelle im IP mal die Historie betrachten, ist da vielleicht ein Tunneling request noch nicht ge-Ackt worden?

mfg Swen

[BliBlaBlo]

Hallo,
neues Jahr, selbes Problem

also,
alles was ich schicke (mit der ETS kann ich sehen dass da alles ankommt) wird mir auch beantwortet. Es geht also nichts irgendwo verloren.

Was mir eben auffällt ist, dass über GPRS viel mehr cEMI Pakete zurück kommen die eine Service Confirmation (MC 0x2E) darstellen aber keine Data Indication (MC 0x29).
Hier mal ein Sample eines cEMI Paketes das zurückkommt:

2e 00 9c d0 db 00 40 05 01 00 00

Kann da irgendjemand daraus was ablesen?

Was ich nicht wirklich verstehe ist, warum das genau gleiche über eine schnelle Verbindung funktioniert und über eine sehr langsame nicht.
Kann das was mit dem Timing zu tun haben?

Lg und ein schönes neues Jahr

[Lipovac]

KNX Tunneling Request

Hallo everyone.
My Deutsch is not good, so I did't find a way to post a new thema so I must use this way.I am working with some KNX devices, and I want to control my instalation from my PC over IP(with some simple application).I have implemented a heart beat monitoring, and when I establish a communication channel with connect Request I trayed to turn light on with tunneling Request but nothing happends(I did't get any answer from Router, and Router dont't forward that request to KNX bus). I dont know what is the problem(search request/response, connect request/response, connection state request/response, disconnect request/response works good, but when I send description request I receive response with extremly incorrect information). My tunneling request looks like this 06 10 04 20 00 15 04 channelID(that I receive in connect response) 00(when I send request for the first time sequence counter is 00) 00 11 00 BC E0 00 00 10 02 01 00 81 (for light on on group address 2/0/2, and 80 for light off on group address 2/0/1). If anyone know what might be a problem please help me.
Thank You.