Timberwolf Server (aka "New Generation") grober Termin?

[Chris M.]

Da die Schnittstelle nun im "neuen" Thread gelandet ist, kann ich ja fragen ohne den Thread zu kapern:

Ich habe einen IP-Router und einen klassischen TP-UART (RS232). D.h. wenn ich das nun richtig verstehe, würde ich mit dem neuen WG auch hier eine neue (weitere...) KNX-Schnittstelle benötigen?

[StefanW]

Hallo Robert,

Die Namespaces beziehen sich auf die globalen Variablen im hash, die natürlich eindeutig sei müssen oder ist dies anders gemeint?

Ja, so ist das gemeint. Im bisherigen WG liefen alle Plugins im Kontext eines großen PERL-Modules und damit im gleichen Namespace (möglicherweise drücke ich mich hier nicht ganz richtig aus, bin kein PERL-Spezialist).

Geplant ist: Im WireGate der neuen Generation soll man sich entscheiden können, ob alle Plugins im gleichen Docker Container oder in jeweils verschiedenen Docker Containern (oder Mischformen) gestartet werden. Dies hat den Vorteil, dass man die verschiedenen Container an den Einsatzzweck, zusätzliche Bibliotheken anpassen kann.

Danke für die ausführliche Info. Das klingt sehr gut und ermöglicht weiterhin auch etwas mehr als nur Logik.

Richtig, wenn man mal verstanden hat, wie man sich einen Container baut (das kann ja auch in einer VM vorgenommen werden) dann ist fast alles möglich.

d.h.aus dem wunderground plugin kommt das Wetter => Beschattung nur bei Heiter oder Teilweise bewölkt.
Auch den Windalarm habe ich aus wunderground abgeleitet, würd ich aber so nicht empfehlen.

Wenn es nach mir geht, dann werden wir das Thema "Einbeziehung Wettervorhersage" in unsere Logik-Module mit einbauen. Das ist zumindest ein für später angedachter Optimierungsschritt. Dazu müssen wir uns noch Gedanken machen, auch über eine langfristig verfügbare Datenquelle.

Ich gehe mal davon aus, dass ich ETS 5.5 dafür brauche.

Richtig, ab 5.x ist zunächst ausreichend, aber irgendwann braucht es dann auch ab 5.5

Hatte ich zwar nicht am Plan, aber andererseits liegt mir die 3f ohnehin im Magen, da Win10 wartet und irgendwann muss man nachziehen,

Ja. Es hängen wohl noch sehr viele an der 3f.

Eigentlich stammt die ETS 3er Version aus dem Zeitraum 2004 bis 2010 und ist veraltet. Vermutlich haben jedoch sehr viele Professionals in dem Zeitraum angefangen und die ETS 3 war für lange Zeit das Hauptwerkzeug. Wenn man einmal den Umgang mit einem Werkzeug sehr genau kennengelernt hat, dann steigt man oft nur ungern um.

Ich denke aber auch, dass irgendwann die Zahl moderner Komponenten, insbesondere durch KNX Secure, eine Größenordnung erreichen, dass der Migrationszwang auf die ETS ab 5.5 stetig größer wird.


lg

Stefan

[mfd]

Verschieben wäre eine gute Idee, sonst geht es (mir) hier (auch) wie eingangs erwähnt:

Nachdem hier mittlerweile gefühlt jedes zweite Thema mit dem Verweis auf das "Wiregate New Generation" endet (oder kommt das nur mir so vor?)

Hinweis: Die betreffenden Einträge wurden aus dem Thread "Old Generation..." hierher verschoben! [StefanW]

[StefanW]

Hallo Jürgen, eine gute Frage!

kann man diesen TP-UART2 auch als eigenständige standalone Schnittstelle betreiben

Nein, dies ist keine eigenständige USB-Schnittstelle (weil es an einem Prozessor fehlt der Emi / cEmi taugliche Software hätte).

oder funktioniert der nur zusammen mit dem neuen Wiregate 2XXX?

Dieser funktioniert zusammen mit unserem eigenen KNX-TP-Stack. Dieser Stack ist auf allen neuen WireGate Servern mit KNX Unterstützung enthalten, also bei den Hutschienen-Modellen der 9xx Serie, als auch beim Desktop-Modell der 2xxx Serie.

Unsere neue USB TP-UART Schnittstelle funktioniert also mit allen neuen WireGate Servern mit KNX-TP-Stack. Das ist nicht auf den 2xxx beschränkt.


BTW: Ich glaube die letzten zig Einträge haben eher mehr mit der neuen Generation, als mit der alten Generation zu tun. Wenn gewünscht, kann ich das gerne verschieben.


lg

Stefan

[heckmannju]

Hi Stefan,

kann man diesen TP-UART2 auch als eigenständige standalone Schnittstelle betreiben oder funktioniert der nur zusammen mit dem neuen Wiregate 2XXX?
Viele Grüsse
Jürgen

[Robert_Mini]

Wir stellen eine Basis Image zur Verfügung, dass die für Plugins grundsätzlich wichtige Laufzeitumgebung enthält. Also eibd, wiregated (abgespeckt) und PERL und ein paar Libs dazu. Über die Console kann man dann ein oder mehrere Plugins pro Container starten. Ein oder mehrere Plugins deswegen, falls sich zwei Plugins Daten aus dem gleichen Namespace teilen.

Die Docker-Images lassen sich erweitern. Man loggt sich dort ein, hat quasi containerweite Root-Rechte und kann sich die Pakete installieren.

Mit Docker kann man darüber hinaus sehr viel mehr machen, darin dürfte so ziemlich alles laufen, was derzeit an Projekten verfügbar ist (2xxx Server): Smarthome.py, OpenHab, Edomi.

Die Namespaces beziehen sich auf die globalen Variablen im hash, die natürlich eindeutig sei müssen oder ist dies anders gemeint?

Danke für die ausführliche Info. Das klingt sehr gut und ermöglicht weiterhin auch etwas mehr als nur Logik.
zB: Nachdem meine Wetterstation im Moment auf Reparaturreise ist, übernimmt das WG vollständig die Kontrolle.
d.h.aus dem wunderground plugin kommt das Wetter => Beschattung nur bei Heiter oder Teilweise bewölkt.
Auch den Windalarm habe ich aus wunderground abgeleitet, würd ich aber so nicht empfehlen.

Denke das wunderground.pl hat eher Bastelcharakter und lässt sich am WG-NG nur über den Docker/Plugin umsetzen.
Gleiches gilt für Mittelwertbildung etc. vermute ich, daher bin ich für diese flexible Option dankbar, auch wenn ich mit Unix eher nicht am Hut habe (Perl macht mir aber richtig Spaß).

Robert, Du bist wegen der vielen Plugins ohnehin für einen Test eingeplant, ich komme dann noch auf Dich zu. Außerdem haben wir noch das Hall of Fame Projekt, das wir machen müssen.

lg
Stefan

Sehr sehr gerne!!
Ich gehe mal davon aus, dass ich ETS 5.5 dafür brauche. Hatte ich zwar nicht am Plan, aber andererseits liegt mir die 3f ohnehin im Magen, da Win10 wartet und irgendwann muss man nachziehen, da ist ein zu großer Sprung vermutlich ein Nachteil.

Es ware aber aus meiner Sicht falsch diese Kosten dem WG-NG anzulasten, aber das muss jeder mit sich selbst entscheiden.
Ihr zwingt ja keinen zum Aufstieg, wie du ja schon mehrfach geschrieben hast.

Ich sehe eine moderne Hausautomation eben als evolutionäres Thema, das nicht 15 Jahre ruht und dann mit viel Aufwand erneuert/upgedatet werden muss.

Danke und lg
Robert

[StefanW]

Ich betreibe z.Z. an meinen WG eine KNX IP-Schnittstelle auf der ich auch über WG auf die ETS zugreife.
Braucht man dann auch den neue TP-UART für das WG2.00?

Ja. Der neue WireGate Server ist ein KNX-TP Gerät.

Zur Erklärung:

• Der eibd für sich ist klasse, er erlaubt über fast jedes lokale oder remote Interface - sogar via KNXnet/IP und damit IP-Schnittstellen - sich mit dem KNX zu verbinden - und dabei selbst eine KNXnet/IP Schnittstelle oder gar Router zu sein.
• Allerdings ist der eibd nicht per ETS konfigurierbar, der eibd-Router kennt keine Filter und die API des eibd basiert auf GA.
• Soweit man sich an diese Limitationen hält, ist sehr viel möglich, wie man am ursprünglichen WireGate Server und vielen späteren Projekten, die ebenfalls auf dem eibd (oder dem knxd als dessen Fork) basieren, sehen kann.

Sobald jedoch die Anforderung kommt "per ETS konfigurierbar" oder "objektbasiert" oder gar "zertifiziert" was alles andere mit einschließt, dann muss das Design des Stacks anders aussehen. Um es vereinfacht auszudrücken, ein KNX-TP-Stack ist an eine KNX-TP-Schnittstelle gebunden. Es gäbe theoretisch die Möglichkeit auch einen reinen KNX-IP-Stack zu bauen, dies ist jedoch hier nicht implementiert. Das mag in ferner Zukunft anders aussehen.


lg

Stefan

[NetFritz]

Hallo
Ich betreibe z.Z. an meinen WG eine KNX IP-Schnittstelle auf der ich auch über WG auf die ETS zugreife.
Braucht man dann auch den neue TP-UART für das WG2.00?
Gruß NetFritz

[Jockel]

Super, danke für die Klarstellung. Dann ist das für mich alles prima, am neuen "TP-UART" wird es nicht scheitern!

[StefanW]

Kann ich nur den alten TP-UART nicht weiter nutzen,

Richtig, weil es gibt künftig ein technisch neueres Modul, das zudem einen ca. 15% höheren Durchsatz bietet:


Diese Version des TP-UART ist vorgesehen / notwendig:

• Als zusätzliches Interface zum neuen WireGate auf der Hutschiene (das ansich bereits einen KNX-Anschluss enthält). Dies ist interessant, wenn man weitere Linien hat. Dadurch kann man auf jeder Linie separat loggen und per IP zugreifen
• Als erstes und weiteres KNX-TP Interface zum neuen WireGate im Desktopgehäuse. Auch hier Unterstützung mehrere Linien möglich.

oder brauche ich zukünftig, neben dem Wiregate, eine zusätzliche IP-Schnittstelle zum KNX-Bus,

Nein. Der neue WireGate Server ist ein zertifiziertes KNXnet/IP Interface ("IP Schnittstelle") mit - je nach Ausführung bis zu 100 Tunnel gleichzeitig. Das IP-Interface kann hierbei über mehrere lokale TP-UART-Interfaces mehrere Linien bedienen. Mithin kann das neue WireGate in größeren Anlagen gleich mehrere IP-Schnittstellen einsparen.


lg

Stefan

[Jockel]

Die Entscheidung, dass wir die bisherigen TP-UARTS in Zukunft nicht mehr unterstützen können ist am Ende eine finanzielle. Der Aufwand, um unserem Stack die alten TP-UART beizubringen und das ebenfalls zertifizieren zu lassen kostet soviel, dass am Ende die Unterstützung der alten TP-UARTs mehr kosten würde, als diese noch Wert sind. Oder kurz: es macht für die Kunden keinen Sinn, hundert Euro für Kompatibilität auszugeben um eine Hardware zu unterstützen die einen Restwert von ca. 50 EUR hat. Ich denke, das würde Kunden noch mehr enttäuschen, wenn Sie für Kompatibilität zu alter Hardware diesen Aufpreis bezahlen sollten.

Ich bin mir nicht sicher, ob ich das richtig verstehe. Kann ich nur den alten TP-UART nicht weiter nutzen, oder brauche ich zukünftig, neben dem Wiregate, eine zusätzliche IP-Schnittstelle zum KNX-Bus, da das Wiregate diese Aufgabe nicht mehr übernehmen kann?

[StefanW]

Hallo,

Ist eventuell auch schon eine Einbindung der eKey-Home/Multi Fingerprint per deren UDP-Adapter geplant?

Ja, zwar nicht kurzfristig, aber die Thematik wurde schon ein paar Mal angefragt. Grundsätzlich sind wir für alles zu begeistern, wofür ausreichend Kunden Interesse zeigen.

Direkt über den auch von ekey genutzen RS485 Bus dürfte ja nicht gehen da ekey das Protokoll sicher nicht offen legt.

Keine Ahnung. Hat das schonmal jemand nachgefragt?

Der von ekey angekündigte KNX-Adpater entspricht leider nicht ganz den Erwartungen die viele in den gesetzt hatten und eine Verknüpfung mit den Logiken des Wiregate NG würde vieles ermöglichen.

OK, zur Bewertung des Feature-Requests sind genauere Informationen hilfreich. Je besser aufbereitet, erklärt und schmackhaft gemacht, desto höher die Wahrscheinlichkeit der Umsetzung und außerdem ist dann - bei anschließender Teilnahme am Beta-Test - die diesbezügliche Lizenz für den "Feature-Paten" gratis.

Mithin: Schreib uns bitte an support at wiregate dot de mit "WireGate / Vorname Nachname: Feature Request WG-NG zu eKey-Home/Multiprint UDP Adapter"

Gerne gesehen hierbei: Erklärung zur Aufgabenstellung, damit mögliche Features (also die Wertsteigerung), mindestumfang der Implementierung, dazu optionale Zusatzmodule, Zeichnungen von Administrationsoberflächen, Hinweis auf Wettbewerbsprodukte und bekannte Stärken / Schwächen. Weil dann müssen wir das nicht alles selbst recherchieren und sparen uns Zeit, womit das Feature sich leichter und günstiger realisieren lässt.


lg

Stefan

[ralfs1969]

Ist eventuell auch schon eine Einbindung der eKey-Home/Multi Fingerprint per deren UDP-Adapter geplant? Direkt über den auch von ekey genutzen RS485 Bus dürfte ja nicht gehen da ekey das Protokoll sicher nicht offen legt.
Der von ekey angekündigte KNX-Adapater entspricht leider nicht ganz den Erwartungen die viele in den gesetzt hatten und eine Verknüpfung mit den Logiken des Wiregate NG würde vieles ermöglichen.

[StefanW]

Welche ETS wird denn vorausgesetzt?

Derzeit basiert die Applikation zum WireGate New Generation auf der ETS 5.x

Selbstverständlich wissen wir, dass viele Kunden und insbesondere SI und Integratoren noch gerne mit der ETS 3 arbeiten. Wir haben das auch lange abgewägt, sind aber zu folgendem Schluss gekommen:

Mittlerweile kommen nun die neuen Sicherheits-Erweiterungen wie "KNX Net/IP Secure" und "KNX Data Security" auf den Markt und wir arbeiten auch bereits an ersterem. Andere Anbieter auch. Für die Nutzung und Konfiguration dieser neuen Sicherheits-Erweiterungen muss zwingend die ETS ab Version 5.5 verwendet werden. Schon auf kurze Sicht hin (halbes Jahr) werden vermutlich insbesondere die SI und professionellen Integratoren sich damit konfrontiert sehen, dass Kunden die Implementierung der neuen Security-Erweiterungen einfordern. Der Aufwand, die Applikation für die ETS 3.x zu erstellen - wir haben 1000 Objekte - ist für die letztlich nur noch kurzfristige Nutzbarkeit zu teuer. Teuer bedeutet: Würde auf den Preis aufgeschlagen werden. Ich denke dass die meisten den Aufpreis nicht bezahlen wollen, deshalb haben wir das gestrichen.

Die Entscheidung ist nicht leicht, weil uns die Vorteile der ETS 3 von manchen sehr leidenschaftlich vorgetragen wurden. Falls wir noch einen gangbaren günstigen Weg finden, dann würden wir den auch nutzen.

lg

Stefan

[nipponichi]

Die KNX-Funktion basiert auf einem eigenen zertifizierten KNX-Stack der per ETS konfiguriert wird.

Welche ETS wird denn vorausgesetzt? (Wäre dann evtl noch ein ETS-Upgrade einzuplanen?) Danke.