ElabNET Technik Forum

Bei mir hat das partielle Programmieren des Timberwolf (vorher nur PA vergeben) mit der ETS 5 über einen MDT IP Router rund 9 Minuten benötigt. Evtl. geht es über die TW-KNX-Schnittstelle schneller, das hab ich noch nicht getestet.

Bei mir ähnlich lange, Programmierung über das Wiregate.

Durch Schnelligkeit zeichnet sich die ETS 5 aber auch one Timberwolf nicht aus...

tger977 hat geschrieben: ↑Sa Aug 25, 2018 3:32 pm"Die Schnittstelle konnte nicht geöffnet werden. Der Tunneling Server ist erreichbar aber er akzeptiert keine Verbindungen mehr zu diesem Zeitpunkt."

Derzeit sind wir noch auf einen (1) Tunnel pro Zeit limitiert.

==> Timberwolf Server mit ext. "TP-UART": Dieser KNX Buankoppler ist technisch auf einen (1) Tunnel limitiert

==> Timberwolf Server mit eingebauter KNX-Schnittstelle: Mit einer der nächsten Updates, wird der Server bis zu 25 gleichzeitige Tunnel unterstützen, derzeit ist es noch ein (1) Tunnel. Diese Tunnel PA-Adressen lassen sich dann in der Applikation vergeben.

In Deinem Fall hat irgenwas den Tunnel benutzt. Sobald dieser wieder frei wird, kannst Du diesen auch nehmen.

Hinweis: In einigen Monaten wird es eine erweiterte "Pro" Version des TP-UART geben, mit der dann auch mehr Tunnel möglich sind. Diese Version wird auch eine eigene Programmiertaste und eine vierte LED haben. Ist schon fertig, muss nur noch in die Produktion. Den Kunden mit den alten TP-UART wird ein Upgrade angeboten, wobei man die "alten" TP-UART durchaus für weitere Linien (soweit von der Server-Lizenz unterstützt) gebrauchen kann. Bitte nicht anfragen deswegem, wir werden das dann schreiben, sobald wir die erweiterte Version liefern können.

lg

Stefan

Hallo Stefan,

ok, jetzt weiss ich warum ich da plötzlich Probleme habe... Ich habe gestern abend den ersten EDOMI Dockercontainer erstellt und aktiviert. Offensichtlich hat dieser doch schon soweit funktioniert daß der Tunnel belegt wurde (etliches anderes funktioniert grad noch nicht)... Nachdem ich den Container gestoppt habe geht es nun.

Also ein(1) Tunnel geht bei mir wirklich nicht für ein Produktivsystem. Aber ihr seid ja schon an einer Lösung dran.

tger977 hat geschrieben: ↑Sa Aug 25, 2018 5:12 pmAlso ein(1) Tunnel geht bei mir wirklich nicht für ein Produktivsystem. Aber ihr seid ja schon an einer Lösung dran.

Ist uns auch völlig klar und von Anfang an - so vor sechs Jahren - war auch immer geplant, dass unser Server "mehr als genug" Tunnel haben soll. Das konnten wir dann auch und dann hat uns die Erweiterung des Standards um "KNX Data Security" einen Strich durch die Rechnung gemacht.

Bis vor etwa 18 Monaten war es noch erlaubt, beiebig viele Tunnel unter einer PA auszugeben (der eibd/knxd und ältere zertifizierte IP-Schnittstellen tun das heute noch). Mittlerweile ist das aber nicht mehr erlaubt, sprich, wird nicht mehr zertifiziert. Das machte einen Umbau von Stack und Interface nötig, der erheblich aufwendiger ist, als man sich das so vorstellt. Denn da waren die TP-UART schon fertig entwickelt und erstmal keine Ressorucen frei, das anders umzusetzen, weil andere Aufgaben anstanden.

Weil um die vielen PA zeitnah zu händeln (bei PA-zu-PA Paketen müssen die einzelnen PA ein Ack senden) haben wir uns für einen CoProzessor entschieden. Kling einfach, ist aber ein ziemlicher Aufwand, weil man einen weiteren Prozessor mit Schnittstellen hat der auch in Produktion und ggls. beim Kunden später geflashed werden können muss, das ist alles andere als trivial. Hat uns viele Mannmonate gekostet.

Jetzt, seit letzter Woche haben wir das nun im 2500er geschafft und mit BETA9 die Firmware für den (nun auch engebauten) CoProzessor ausgeliefert. Jetzt fehlt nur noch ein angepasster KNX-Stack und eine überarbeitete Applikation, dann kann man die vielen Tunnel auch benutzen. Hier muss man dann auch nur einmal die PAs vergeben. die Clients suchen sich die Tunnels dann selbst über ein Discovery-Protokoll heraus.

insofern tut das Dein Edomi-Container (Glückwunsch bei der Gelegenheit - und bitte auch für alle bereitstellen) auch schon.

lg

Stefan