[Beantwortet] [V4.8 IP1] Kann die APDU der KNX-IP-Schnittstelle höher gesetzt werden?

[jhaeberle]

Hi,

ich habe eine Reihe an OpenKNX-Komponenten verbaut, für die nun Firmware-Updates anstehen. Dazu bietet OpenKNX ein PowerShell-Skript an, um die Daten über ein IP-Interface auf ein Gerät zu übertragen. Coole Sache. Aber…

Aus der Interface-Konfig der ETS entnehme ich eine APDU von 55. Die definiert die Packetgröße. Mit dieser Einstellung bekomme ich eine Transferrate von ~110 Byte pro Sekunde daher. Maximal möglicher Wert wäre wohl 254, was vielleicht nicht zum fünffachen, aber doch zu einer erheblich höheren Transferrate führen würde.

Ist das korrekt oder kann ich die Paketgröße vom Wolf irgendwo hoch schrauben?

Dann… ich stelle fest, wenn ich so ein Update über das Interface auf den Bus schicke und dann über die ETS eine Programmierung starte, bricht das Update ab und auch die ETS-Programmierung schlägt fehlt. Darf das sein? Wenn ja: Wozu habe ich dann am TWS so viele Interfaces, wenn die nicht gleichzeitig benutzt werden können?

Danke, Gruß
Jochen

[StefanW]

Hi Jochen,

die APDU des Timberwolf Servers ist durch den zertifizierten KNX-Chip im Timberwolf Server auf diese 55 begrenzt, das lässt sich nicht höher schrauben, da "in Silicon" festgelegt.

Zu Abbrüchen uns unbekannter Software kann ich nix sagen.

lg

Stefan

[StefanW]

Hi Mods,

kann das jemand in den KNX Bereich verschieben bitte,

Merci

[Parsley]

Hi Jochen,

Bitte wie immer die Version im Titel nicht vergessen.

(Ja, auch wenn es hier ein Hardware Thema sein mag, bitte einfach immer die aktuell installierte TWS Softwareversion in den Titel.)

[ms20de]

Zur Information, weil es anscheinend hier ein paar Unklarheiten gibt:

APDU

Die Angabe „55 Byte APDU“ bezeichnet lediglich die maximale Größe eines sendenden Telegramms. Solch große Telegramms werden in der Regel nur für Spezialanwendungen wie Updates benötigt.
Ein korrekt implementiertes Update-Programm sollte damit problemlos umgehen können, da es die maximale APDU abrufen und die Daten in mehrere Telegramme aufteilen kann.
Durch die zusätzlich erforderlichen Telegramme entsteht ein gewisser Overhead, da jedes Telegramm Informationen wie Typ, Ziel-PA, Länge usw. enthält. Dieser Overhead reduziert die maximale Übertragungsrate. Nach unserer Erfahrung liegt die vergleichsweise geringere Geschwindigkeit jedoch an der Gründlichkeit unseres KNX-Stacks: Die IP-Seite bestätigt den Versand erst, wenn das Telegramm tatsächlich auf dem TP-Bus übergeben wurde. Andere Hersteller akzeptieren offenbar das Risiko eines möglichen Telegrammverlusts für eine höhere Übertragungsrate.

Telegramme, die von anderen Geräten mit maximal möglicher APDU gesendet werden, können vom Timberwolf Server vollständig gelesen und verarbeitet werden. Es gibt keine Einschränkungen, die verhindern würden, dass längere Telegramme verarbeitet werden.


TP-Schnittstellen

Am Timberwolf Server können zusätzliche TP-Schnittstellen angeschlossen werden. Diese dienen zur Aufzeichnung von Telegrammen für die Analyse von TP-Linien.

Die Besonderheit: Diese Schnittstellen können auch beschädigte Telegramme sowie ACK-Bestätigungen empfangen und aufzeichnen. Wir nennen diesen Modus Real-Busmonitor, der extrem hilfreich ist, wenn in einer KNX-Anlage ungewöhnliche Probleme auftreten.
Im Real-Busmonitor-Modus kann die Schnittstelle keine Telegramme versenden und daher nicht als IP-Tunnel genutzt werden. Eine Umschaltung in den IP-Tunnelmodus wäre technisch möglich, würde uns jedoch in direkten Wettbewerb mit IP-Linienkopplern bringen, die ebenfalls Tunnel anbieten.

Viele Grüße,
Matthias

[jhaeberle]

Hallo Matthias,

sehr aufschlussreich, danke! Ich hatte mich auch schon gewundert, wieso hier die Telegrammgröße anscheinend einen derart massiven Einfluss auf die Geschwindigkeit zu haben scheint. Abgesehen vom Protokolloverhead ergibt das tatsächlich nicht wirklich Sinn.

Jedenfalls aber komme ich mit meinem TWS auf Übertragungsrarten von rund 110 Byte/sec, andere schaffen bis über 500Byte/sec. Und dann brechen mir 4 von 5 Versuchen wegen Timeout-Fehlern ab…

Gruß
Jochen

[StefanW]

Hi Jochen,

das KNX Tunnel-Protokoll ist relativ komplex. Ich lese nun "PowerShell-Skript"? Weißt Du, ob die noch einen Treiber für KNXnet/IP nutzen?

lg

Stefan

[jhaeberle]

sorry, nein, das weiss ich nicht.

[starwarsfan]

Hallo miteinander

Ich lese nun "PowerShell-Skript"? Weißt Du, ob die noch einen Treiber für KNXnet/IP nutzen?

Ich finde leider gerade den Thread nicht wieder, aber AFAIR setzen die Powershell-Scripte von OpenKNX eine Installierte ETS voraus und benutzen dann die Treiber direkt von dort...

[gbglace]

Ist schon was OT. Ja die Generierung und Signierung der ETS Applikation lässt OpenKNX die ETS selbst machen. In den bisher ausgerollten ETS Versionen ist zur allgemeinen Abwärtskompatibilität diese Funktion enthalten da die Applikationen passend zu einer ETS2 z.B. das benötigten.

Auf diesem Wege hat der geneigte Open-KNX User eine lizensierte gekaufte Software auf seinem Rechner und bekommt von Open-KNX nur Daten und Skripte um die Software zu nutzen. Das dabei dann eine KNX-Prod Datei rauspoltert ist ein Effekt dabei. Für einen gewerblichen Anbieter sicher nichts was die KNXA akzeptieren würde. Aber für denjenigen der als Enduser-Lizenznehmer der ETS diesen Werkzeugkasten geliefert bekommt eine darstellbare Lösung. Daher gibt es die Open-KNX "Applikationen" auch nur in dieser Rohversion die man erst zur KNX-prod quasi kompilieren lassen muss.

Klaus Gütter war auch sehr überrascht wie die Jungs das hinbekommen hatten, das die ETS die Dinger ohne diese Ausrufezeichen generiert.

Aber auch da muss OpenKNX in Zukunft sich was neues ausdenken, da die zukünftigen ETS wohl diese Abwärtskompatibilität verlieren werden und die KNXA vorsieht das es grundsätzlich keinen Import externer KNX-Prod Dateien mehr geben wird. Sprich Import ausschließlich nur noch via KNX-Online-Katalog. Das ließe sich zwar zuletzt auch noch als Barriere umschiffen, da man der ETS die Online-Katalogquelle auch als http ohne s Seite vorgaukeln konnte. Also man sich mit etwas Skripterei sich selbst als Shop darstellen konnte aus dem man dann eben die frisch erzeugte KNX-Prod dann geladen hätte.

Aber ich denke das werden die in der ETS auch noch zu fixen wissen, bevor es nur noch aus dem Katalog in eine ETS geht.

Bis dahin muss man sehen das man als Open-KNX Gerätebetreiber sich ne ETS6 auf dem Rechner behält dann da sich die Applikation erzeugen lässt und dann in ein Projekt importiert und dann dieses Projekt in die ETS V7 oder höher konvertiert und da wieder ins andere Projekt zieht. Denn eine gültige Signatur hat diese Applikation ja (kein fehlendes Ausrufezeichen).

Das obengenannte Powershellskript ist eine Alternative die genutzt wird um das zu emulieren was MDT Enertex und CO it ihren DCAs zum Firmwareupdate anbieten. Open-KNX hat da halt keine DCA in der ETS, sondern dieses Skript und mittlerweile auch eine KNX-Toolbox als UI drumrum, um den Geräten auch via BUS ein Firmware-Update zu verpassen. Die ETS hat ja auch dafür bestimmte Kommunikationskanäle und Protokolle auf dem Bus. Das haben die Kollegen da entsprechend auch für sich nachgebaut zu nutzen. Die KNX-Specs sind da doch recht gesprächig wenn man sich da mit Lust und Laune reinließt.

Am Ende versucht man da halt relativ große Telegramme zu generieren um eben die teilweise recht umfangreichen Firmwares da in brauchbarer Zeit in die Geräte zu bekommen. Die eine Sorte Open-KNX Geräte die eine IP-Seite haben haben da natürlich nicht dieses Problem, da es dann dort IP-Seitig den Weg ins Gerät findet.

Klar kann man die Geräte auch alle vom KNX abklemmen und dann per USB Betanken aber so manche UP-HW oder Melder an hohen Decken ist da nur schwer für geeignet.

Aber ja die ganze KNX Programmiererei ist da schon keine Kleinigkeit. Das Team hat da derzeit glaube drei sehr tief drin steckende Progger, die sich das auch noch aufteilen am Start. Einen Applikationsguru, einen ETS Kommunikationsguru und einen IP-Protokoll Meister. Mit dem Einsatz an Freizeitstunden den die da aufgebracht haben muss man als kommerzielles Unternehmen schon was an Luft haben sich da so einen Stack hinzustellen und Applikationen usw. zu bauen.
Man darf da auch nicht annehmen das auch bei Größen wie Gira / MDT wirklich mehr Leute in der Firma sitzen, die KNX Applikationen und ETS Kommunikation programmieren können.

Für mehr Plauderei zu dem Thema empfehle ich den Stammtisch Wiesbaden, da findet man eigentlich immer mehrere Leute aus der Open-KNX Truppe oder Nürnberg, wobei letzterer dann eher von den HW-Kreativen besucht wird. Die haben doch wirklich immer wieder neue Entwicklungen dabei. ich bekomme da immer wahnsinnig viele neue Ideen was ich da noch ins Haus basteln könnte.