ElabNET Technik Forum

Hallo zusammen,

Wenn ich das richtig verstehe kann ich beim TW960Q 3Tunnel nutzen, also einmal die integrierte Schnittstelle + 2 WG KNX TP-UART USB, richtig?

Ist das eine Limitierung durch die Hardware, weil der TW sonst überlastet wäre, oder ist das einfach Softwaremäßig limitiert, um sich vom TW2600 abzugrenzen?

Mir geht es im Prinzip darum, dass ich eine Hauptlinie und 3 weitere Linien für EG, OG und Garten habe. Und da der TW diese tolle Funktion der Linienüberwachung/ -aufzeichnung bietet, hätte ich das auch gern für jede Linie extra genutzt, ohne jetzt alle Linienkoppler auf Durchzug zu stellen.

Jetzt hab ich grad mal in den Shop geschaut wie viel die TP-UART kosten, dass wenn ich mal wieder genug Asche beisammen hab, ich mir diese gönnen kann. Dabei bin ich über die Limietierung gestoßen. Hab ich bestimmt vorher schon gelesen, bloß bis jetzt mir noch nie Gedanken gemacht .

Falls das nur eine Softwaremäßige Limietierung ist, besteht später vielleicht die Möglichkeit sich weiter Tunnel freischalten zu lassen, natürlich gegen eine entsprechende Aufwandsentschädigung?


Was mich auch noch interessieren würde, wenn jetzt Beispielsweise eine Hauptlinie und eine Nebenlinie vorhanden sind und der TW960Q mit der internen Schnittstelle mit der HL verbunden ist und mit einem TP-UART mit der NL. Jetzt soll z.b. mit einem Schalter der NL das Licht welches am TW am DMX hängt geschaltet werden. Muss dann der Linienkoppler diese Telegramm zur HL durchlassen, oder geht das über den TP-UART zum TW?

Momentan hängt mein DMX-Gateway in der HL und somit müssen die entsprechenden KO‘s im Koppler immer durchgelassen werden. Und da die Applikationen meines momentanen DMX-Gateway so super Toll mit der ETS funktioniert (nämlich gar nicht ), muss ich die KO‘s immer von Hand in eine Dummy Applikation ziehen. Und ab und zu passiert es halt mal, dass Mann das mal vergisst, und man sich wundert warum es nicht funktioniert . Naja alles eigentlich nicht so wild, mich interessiert eigentlich nur wie das beim TW funktioniert?


Gruß Ben

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmWenn ich das richtig verstehe kann ich beim TW960Q 3Tunnel nutzen, also einmal die integrierte Schnittstelle + 2 WG KNX TP-UART USB, richtig?

Nein.

Der Timberwolf Server 950/960 unterstützt mit der integrierten KNX-Schnittstelle bereits 25 gleichzeitige Tunnel-Connections.

Man kann am TWS 950/960 drei KNX Interfaces gleichzeitig betreiben (und damit womöglich x mal 25 Tunnel, je nach Interface-Typ, aber letzeres, also das x mal ist noch nicht versprochen)

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmIst das eine Limitierung durch die Hardware, weil der TW sonst überlastet wäre, oder ist das einfach Softwaremäßig limitiert, um sich vom TW2600 abzugrenzen?

Nö.

Alle internen Interfaces, egal ob bei 350 / 950 / 960 / 2500 / 2600 können jeweils 25 gleichzeitige KNXnet/IP Tunnel Connections.

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmMir geht es im Prinzip darum, dass ich eine Hauptlinie und 3 weitere Linien für EG, OG und Garten habe. Und da der TW diese tolle Funktion der Linienüberwachung/ -aufzeichnung bietet, hätte ich das auch gern für jede Linie extra genutzt, ohne jetzt alle Linienkoppler auf Durchzug zu stellen.

Bitte nicht verwechseln, ein Tunneling Interface ist kein Router. Wenn es nur um das Aufzeichnen geht, wirst Du insgesamt drei Interfaces am TWS 950 anstecken können und kannst dann zwei davon als reine Logging-Interfaces aufzeichnen.

Das ist ein hammergeiles Feature übrigens, das kann unseres Wissens kein anderer Server (und hat viel Kopfzerbrechen in der Entwicklung bereitet)

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmJetzt hab ich grad mal in den Shop geschaut wie viel die TP-UART kosten, dass wenn ich mal wieder genug Asche beisammen hab, ich mir diese gönnen kann. Dabei bin ich über die Limietierung gestoßen. Hab ich bestimmt vorher schon gelesen, bloß bis jetzt mir noch nie Gedanken gemacht .

Nur die bisher erhältlichen USB-TP-UART REG Module sind auf einen Tunnel limitiert. Für die internen Interfaces gilt das nicht.

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmFalls das nur eine Softwaremäßige Limietierung ist, besteht später vielleicht die Möglichkeit sich weiter Tunnel freischalten zu lassen, natürlich gegen eine entsprechende Aufwandsentschädigung?

Ist durch die HW (genauer durch die Vorschriften der KNX Assoc. die nun erfordern, dass jeder Tunnel eine eigene PA bekommt) limitiert. Der dort verbaute KNX Chip kann nur eine PA verwalten.

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmWas mich auch noch interessieren würde, wenn jetzt Beispielsweise eine Hauptlinie und eine Nebenlinie vorhanden sind und der TW960Q mit der internen Schnittstelle mit der HL verbunden ist und mit einem TP-UART mit der NL. Jetzt soll z.b. mit einem Schalter der NL das Licht welches am TW am DMX hängt geschaltet werden. Muss dann der Linienkoppler diese Telegramm zur HL durchlassen, oder geht das über den TP-UART zum TW?

Nun, der Timberwolf Server ist kein Router oder Linienkoppler. Über diese Funktion denken wir nach, haben wir aber heute noch nicht (und ist jetzt nicht versprochen, das wird sich nach Stückzahlen entscheiden und nach der Nachfrage durch die Kunden)

Derzeit beherrschen wir eine gleichzeitige Applikation, wir überlegen jedoch auch mehrere gleichzeitige Applikationen zuzulassen, je eine pro Linie.

Damit könnte man tatsächlich auch auf mehreren Linien ein Kommando per GA entgegennehmen. In der ETS hätte man dann MEHRERE Timberwolf Applikationen mit unterschiedlicher PA (so wie man von einem Schaltermodell mehrere haben kann, nur dass dies dann "virtuelle TWS" wären).

Allerdings ist die Frage, ob dieses Feature nicht den meisten Kunden mehr Knoten im Gehirn macht als nützlich ist. Eine Anlage soll auch wartbar sein durch jemand anderes und da ist zuviel Koplexität kontraproduktiv.

stonie2oo4 hat geschrieben: ↑Mo Jan 07, 2019 6:00 pmMomentan hängt mein DMX-Gateway in der HL und somit müssen die entsprechenden KO‘s im Koppler immer durchgelassen werden. Und da die Applikationen meines momentanen DMX-Gateway so super Toll mit der ETS funktioniert (nämlich gar nicht ), muss ich die KO‘s immer von Hand in eine Dummy Applikation ziehen. Und ab und zu passiert es halt mal, dass Mann das mal vergisst, und man sich wundert warum es nicht funktioniert . Naja alles eigentlich nicht so wild, mich interessiert eigentlich nur wie das beim TW funktioniert?

Ich bin nicht sicher, ob ich das richtig verstehe. Die Dummy-Applikation ist auch in der HL? Oder der "NL"?


lg

Stefan

StefanW hat geschrieben: ↑Di Jan 08, 2019 12:20 amBitte nicht verwechseln, ein Tunneling Interface ist kein Router. Wenn es nur um das Aufzeichnen geht, wirst Du insgesamt drei Interfaces am TWS 950 anstecken können und kannst dann zwei davon als reine Logging-Interfaces aufzeichnen.

Das ist ein hammergeiles Feature übrigens, das kann unseres Wissens kein anderer Server (und hat viel Kopfzerbrechen in der Entwicklung bereitet)

Vergiss dass was ich zu den Tunnelverbindungen geschrieben hab. Hab da wohl was durcheinander gebracht
Um es richtig zu stellen, die Frage sollte Lauten: Wie viele WG KNX TP-UART USB kann man an den TW960 anschließen?
Und da hast du ja geschrieben 2 zusätzliche, also insgesamt 3, wie es eben auch im Shop steht. Dadurch dass ich 4 Linien habe, wollte ich wissen ob diese Limitierung nur Softwaremäßig ist, da man ja am TW2600 insgesamt 12 Interfaces betreiben kann. Oder ob es in Zukunft vielleicht die Möglichkeit gibt ein TP-UART mehr am TW960 zu betreiben.
Manchmal sollte man erstmal richtig nachdenken und dann dass richtige Fragen, sorry für die Verwirrung.

StefanW hat geschrieben: ↑Di Jan 08, 2019 12:20 amIch bin nicht sicher, ob ich das richtig verstehe. Die Dummy-Applikation ist auch in der HL? Oder der "NL"?

Ja, Dummy-Applikation ist in der HL, sonst würden ja nicht die korrekten Filtereinstellungen gesetzt.

StefanW hat geschrieben: ↑Di Jan 08, 2019 12:20 amDamit könnte man tatsächlich auch auf mehreren Linien ein Kommando per GA entgegennehmen. In der ETS hätte man dann MEHRERE Timberwolf Applikationen mit unterschiedlicher PA (so wie man von einem Schaltermodell mehrere haben kann, nur dass dies dann "virtuelle TWS" wären).

Allerdings ist die Frage, ob dieses Feature nicht den meisten Kunden mehr Knoten im Gehirn macht als nützlich ist. Eine Anlage soll auch wartbar sein durch jemand anderes und da ist zuviel Koplexität kontraproduktiv.

Die ganze Frage kommt eigentlich daher, dass sich schon 1-2mal ein Linienkoppler bei mir aufgehangen hat und dann kein Licht mehr ging. Das ist halt das doofe am zentralen DMX-Gateway. Ich weiß, ich weiß, das über den TW umgehen zu wollen ist iwie von hinten durch die Brust ins Auge. Trotzdem hat’s mich einfach mal interessiert wie das beim TW funktioniert mit den extra Interfaces.

Also alles wie gehabt, TW kommt in die HL und Filtereinstellungen werden durch die verknüpften KO‘s in der TW-Applikation richtig gesetzt. Und die zusätzlichen TP-UART sind momentan „nur“ fürs Logging?

stonie2oo4 hat geschrieben: ↑Di Jan 08, 2019 5:26 pmDie ganze Frage kommt eigentlich daher, dass sich schon 1-2mal ein Linienkoppler bei mir aufgehangen hat und dann kein Licht mehr ging. Das ist halt das doofe am zentralen DMX-Gateway. Ich weiß, ich weiß, das über den TW umgehen zu wollen ist iwie von hinten durch die Brust ins Auge. Trotzdem hat’s mich einfach mal interessiert wie das beim TW funktioniert mit den extra Interfaces.

Was machst Du denn für Lichtaktionen auf Ebene KNX das die Buslast einen Koppler in die Knie zwingt?
Hast Du da eine Engine, die für Lichtsequenzen Unmengen KNX-Dimmwerte sendet?
Das braucht es ja mit der DMX-Steuerung vom TWS nicht mehr. Da hat man das ganz normale übliche auf der Ebene KNX also vom PM Licht an/aus. Soft-AN/AUS rechnet der TWS und schickt das auf den DMX. Davon wirst auf KNX-Seite nichts sehen. Denn die unmegenen Zwischenstatuswerte des Dimmvorgangs werden auch nicht auf den KNX- zurückgesendet.
Eine im KNX ausgeführte manuelle Dimmverstellung am Taster sollte ja auch kein Problem sein für die Buslast.
Eine Visu ist entweder in eigener HW auf der HL. Oder besser direkt aufm TWs oder in einem Docker des TWS, dann gehen deren Aktionen auch am KNX vorbei direkt durch den TWS Objecthandler in die DMX-Engine.

Szenen und Sequenzen startet man einfach über eine GA und der DMX-Controller im TW macht dann halt Disco im DMX-Bus. Auch bei Abspielen solcher Sequenzen wird es bewusst keine Statusrückmeldungen der einzelnen Dimmwerte auf den KNX-Bus geben.

Hallo,

stonie2oo4 hat geschrieben: ↑Di Jan 08, 2019 5:26 pmUm es richtig zu stellen, die Frage sollte Lauten: Wie viele WG KNX TP-UART USB kann man an den TW960 anschließen?

Es ist geplant, dass man insgesamt drei Schnittstellen betreiben kann, also zwei zusätzliche. Zunächst ist das für Logging gedacht.

Es ist eine Limitierung hinsichtlich der Vermutung, wieviel das Gerät leisten können wird. Es ist denkbar, dass dies erweitert wird, womöglich auch gegen Zusatzlizenz, weil der Testaufwand stark steigt. Aber warten wir ab, bis es soweit ist.

lg

Stefan

gbglace hat geschrieben: ↑Di Jan 08, 2019 7:10 pm Was machst Du denn für Lichtaktionen auf Ebene KNX das die Buslast einen Koppler in die Knie zwingt?

Eigentlich nichts besonderes, dass Elka DMX-Gateway sendet blos beim andimmen und abdimmen zig Statustelegramme.
Hier mal ein kleiner Mitschnitt aus meinem Büro von 2 LED-Stripes beim einschalten:


Hier noch die Einstellungen aus dem Gateway, 50 ist übrigens der kleinste Wert, danach gibts nur noch 0.
Auf Anfrage bei Elka warum man soviele Statustelegramme sendet, kam zurück, dass dies die Kunden so wünschen....

Jetzt kann man sich natürlich vorstellen was bei Alles-Aus und genügend Anzahl an Leuchten passiert.

Ich hatte am Anfang mal den Moving-Colors LBS in Edomi mit den Werten die ich im Forum gefunden hatte am laufen. Nach 2 min ging nix mehr, wirklich gar nix. Nach ausschalten des LBS kamen noch paar Minuten Telegramme hinterher, bis sich wieder alles beruhigt hat. Danach hab ich die Werte erstmal stark reduziert, Farbwechsel ist jetzt nicht mehr ganz so geschmeidig, aber der Rest vom Haus geht immerhin noch. Solche Farbwechsel hab ich übrigens momentan nur 2 Stück im Haus. Mit dem TW wird das natürlich wesentlich besser wenn solche Sequenzen einfach mit einem KO aufgerufen werden und der Rest läuft intern ab

Deswegen auch meine bitte im DMX-Thread die Telegrammrate "frei" einstellbar zu gestalten. Bzw. würde mir persönlich auch ein Staustelegramm bei erreichen der vorher gesetzten Helligkeit aussreichen anstatt 15 Stück pro Andimmvorgang.

Wenn die vorgegebene Zielhelligkeit erreicht ist, wird auch diese als Status ausgegeben. Aber alles was im Move passiert muss man nicht im KNX haben, dafür ist der einfach nicht ausgelegt.

Ahh das Elka donnert wirklich jeden Step quasi parallel auf den DMX und den KNX als Status. Uhh das ist heftig.

Ich denke da wird die TWS-Lösung wunder bewirken.

gbglace hat geschrieben: ↑Di Jan 08, 2019 8:24 pm Ich denke da wird die TWS-Lösung wunder bewirken.

Da freu ich mich schon riesig drauf

gbglace hat geschrieben: ↑Di Jan 08, 2019 8:24 pm Wenn die vorgegebene Zielhelligkeit erreicht ist, wird auch diese als Status ausgegeben. Aber alles was im Move passiert muss man nicht im KNX haben, dafür ist der einfach nicht ausgelegt.

Sehe ich genauso, wichtig ist der letzte Schritt, alles zwischendrin ist total überflüssig KNX seitig.

Guten Morgen,

stonie2oo4 hat geschrieben: ↑Di Jan 08, 2019 8:01 pmDeswegen auch meine bitte im DMX-Thread die Telegrammrate "frei" einstellbar zu gestalten.

Es gibt bereits JETZT in der TWS-Applikation einen Parameter für die GESAMTRATE des Timberwolf Servers. Dies, weil der Server mit seinem doppeltem Schreibpuffer so ziemlich einer der schnellsten Sender am Markt ist und eine Reihe von Linienkopplern das gar nicht schafft. Darum kann man die KNX-Telegramm-Datenrate bereits jetzt begrenzen (oder vom Default aus anheben).

stonie2oo4 hat geschrieben: ↑Di Jan 08, 2019 8:01 pmBzw. würde mir persönlich auch ein Staustelegramm bei erreichen der vorher gesetzten Helligkeit aussreichen anstatt 15 Stück pro Andimmvorgang.

Ich denke, das werden wir geschickt einstellbar machen, soweit sinnvoll. Wenn etwas in einer Sekunde hochdimmt, braucht niemand Zwischenwerte, wenn etwas über eine halbe Stunde hochdimmt (zum aufwecken oder als Sonnennachführung) mag es für jedes einzelne Prozent an Steigerung sinnvoll sein. Ich denke, eine Begrenzung auf x Telegramme pro Sekunde pro Dimmer (ich denke da an 1/3 Telegramme pro Sekunde pro Dimmer) sollte man einstellbar haben.

==> Wir berücksichtigen das

lg

Stefan