ElabNET Technik Forum

oh weh... ich glaube ich habe den nächsten Blocker bei der vollständigen Migration

kann es sein daß man mit dem TW2400 und der derzeitig einzig verfügbaren Schnittstelle den Container nicht ans laufen bekommt da man kein KNX Zugriff des Containers mangels verfügbarem Tunnel hinbekommt?

Falls ja, wann gibt es denn für den TW2400 eine Schnittstelle mit mehr Tunnel? (und leider nein, ich habe noch am Wiregate eine serielle TPuart Schnittstelle, die sich nicht "umprogrammieren" lässt...)

Ja Tunnelverbindungen braucht es, eine je Docker. Die Beseitigung des Problems der IP-Kommunikation ersetzt keinen exklusiven Tunnel zum KNX.

Neben eines ggf. Mal wieder verfügbaren updatefähigen USB-TPUART oder einer Neuauflage bei Elabnet der HutschienenVersionen geht natürlich immer jedwede am Markt verfügbare IP-Schnittstelle. Für dieses Szenario ist der 2400-er ja auch primär geplant, Anschluss an KNX via IP.

Da man egal wie gut der TWS auch ist sowas wie eine Schnittstelle zum Bus gern doppelt haben kann lohnt es ggf einfach eine zu kaufen. Ich weiß nicht zu welchen Preisen Elabnet einen USB-TPUART entwickeln kann aber die Weinzierl732 auf 1 TE wäre mir jetzt wohl nicht zu teuer, um dafür endlich einen aufgeräumten Gerätepark zu haben.

tger977 hat geschrieben: ↑Fr Aug 16, 2019 10:56 pm hab mich auch an dem Container nun versucht, o.g. Hinweis scheint mir noch nicht in dem KB Artikel online zu sein. Vielleicht geändert aber noch nicht veröffentlicht?

Doch im ersten Satz:

Der Container ist als App mit Ein-Klick-Installation zu installieren. Das Passwort wird automatisch erzeugt und ist auf der APP Seite einzusehen.

Aber du hast recht, beim Zugriff mit WinSCP stand's noch falsch .

Danke
Robert

Hallo Andi,

tger977 hat geschrieben: ↑Fr Aug 16, 2019 11:25 pmkann es sein daß man mit dem TW2400 und der derzeitig einzig verfügbaren Schnittstelle den Container nicht ans laufen bekommt da man kein KNX Zugriff des Containers mangels verfügbarem Tunnel hinbekommt?

Insofern der einzig verfügbare Tunnel durch etwas anderes belegt ist, JA.

Diese Limitation wäre nicht technisch bedingt, aber während unserer Entwicklung wurden die KNX Spezifikationen geändert. Vorher (und hunderttausende verbaute "alte" KNX zertifizierte IP Tunneling Schnittstellen / IP Router / WireGate Server machen das heute noch in bestehenden Anlagen so) durfte man beliebig viele Tunnel über eine PA führen. Ab der Änderung musste es eine PA pro Tunnel sein und das war mit dem USB TP-UART nicht möglich, da diese keinen eigenen Prozessor hatte.

Da wir ein zertifiziertes Produkt haben wollten - schließlich hat man uns im alten Forum damals immer vorgeworfen, dass der WireGate Server "ja nicht zertifiziert sei" (wobei es HomeServer und Co auch nicht sind) - mussten wir uns den neuen Bedingungen beugen und mussten die - bereits implementierte Funktion - entfernen und die Anzahl der Tunnel auf eins begrenzen.

tger977 hat geschrieben: ↑Fr Aug 16, 2019 11:25 pmFalls ja, wann gibt es denn für den TW2400 eine Schnittstelle mit mehr Tunnel? (und leider nein, ich habe noch am Wiregate eine serielle TPuart Schnittstelle, die sich nicht "umprogrammieren" lässt...)

Die neue "Pro" Schnittstelle ist zwar fertig entwickelt, aber wir haben die Produktion noch nicht aufgelegt. Werden wir schon noch dazu kommen, aber ich kann jetzt keinen Termin nennen.

Allerdings von dem USB TP-UART Stick bekommen wir demnächst neue herein (sind schon unterwegs). Da könnten wir eigentlich einen Rücknahme-Deal anbieten. Muss ich mal darüber nachdenken und werde Euch dann schreiben (bzw. wäre auch mal wieder einen Newsletter wert. Damit könntet Ihr relativ kostengünstig auch 8 gleichzeitige Tunnel betreiben.

lg

Stefan

Ich hab's nicht ausprobiert, was aber gehen kann: wenn in einem Container ein knxd läuft (z.B. der CometVisu Container), dann sollte der den Tunnel nehmen können aber selber beliebig viele bereit stellen können.

Chris M. hat geschrieben: ↑Sa Aug 17, 2019 12:46 pm Ich hab's nicht ausprobiert, was aber gehen kann: wenn in einem Container ein knxd läuft (z.B. der CometVisu Container), dann sollte der den Tunnel nehmen können aber selber beliebig viele bereit stellen können.

Danke Chris, muss ich mich mal weiter mit beschäftigen und probiere ich dann mal aus sobald der Container erstmal grundsätzlich läuft!

da ich leider noch jede Menge Fehlermeldungen bekomme habe ich nun mal mit nur einem plugin (dem wichtigsten, da noch einige dutzend Logiken darin laufen) angefangen: dem Logikprozessor. Ich dokumentiere hier mal was ich an Erfahrung gesammelt habe...

Ich bekomme nach einem Neustart folgende Fehlermeldung, die offensichtlich vom prowl/NMA Sendemechanismus kommen: da das Nachinstallieren der Pakete irgendwie nicht funktionierte und ich auch kein prowl/NMA mehr im Einsatz habe, habe ich einfach die Subroutine sendprowl() komplett aus dem Code entfernt. Damit lief dann der Logikprozessor im Container auch!

Bei Bedarf kann ich die modifizierte Logikprozessor.pl gerne zur Verfügung stellen.

noch eine Frage zum Container: Kann man eigentlich den EIBD dieses Containers nicht auch als KNX Schnittstelle wie im original Wiregate nutzen und damit die Tunnelbeschränkung aufheben (ja, ist dann alles nicht mehr KNX Zertifizierungskonform, das wär mir aber für mein Haus egal...)?

Ein erster Versuch scheiterte gerade. Ich habe dem Container per macVLAN eine eigene IP verpasst und dann einfach mal in meinen EDOMI Container anstatt der IP vom Wiregate die neue IP vom wiregate plugin Container gegeben. Welche KNX Gateway ports muss ich dann nutzen? Ich habe sowohl den bisherigen port 3671 vom wiregate als auch den port 3674 von der TW Schnittstelle in allen möglichen Konstellationen in den beiden Containern versucht.

sollte das prinzipiell funktionieren oder geht das aus irgendwelchen Gründen gar nicht?

Hast auch den Netzwerktyp des TWS selbst auf MAC-VLAN umgestellt?

Dann sollte es vom Prinzip her funktionieren.

ja hab ich... Auf welchem port muss ich denn den eibd im wiregate container erreichen können? 3671, 3674,...?