Enertex IP Interface

[Gaston]

Ich meinte das schon so: Das ist nur der Zertifizierungstest, zusätzlich kann man durchaus weitere Funktionen einbauen - machen andere Hersteller ja auch.

Funktionen hinzubauen und Verhalten änderen sind dabei zwei komplett andere paar Schuhe. Wenn Zertifizierte Geräte nur bei der Zertifizierung (unabhängig von KNX) sich richtig verhalten ist dies eine Täuschung.

Allerdings muss Ich im hier vorliegenden konkreten Fall gestehen dass mir kein Teil der Spezifikationen bekannt ist der die Zertifizierungsbedingung bezüglich der Adressvergabe untermauert. Und Zertifizierungen die strenger sind als die Spezifikationen sind fehlerhaft.

Erst nach Parametrierung einer möglichen IP-KNX-Zuordnung würde sich evtl. eine Änderung ergeben (hängt ja auch von den, für diesen Test verwendeten IP-Adressen ab - die Tunnel kann man ja vom gleichen Rechner aus öffnen). Diese Parametrierung wird aber eh nicht getestet.

Ob das getestet wird ist unerheblich. Wenn sich ein gerät nach "X" Verhalten muss darf es niemals so konfiguriert werden könne dass es sich gegenüber "X" "unloyal" verhält. (Generell, wie oben geschrieben sehe Ich das im Fall hier nicht als gegeben)

BTW für Anforderungen gilt doch: "should" ist unverbindlich und "shall" verbindlich.

Dabei gibt es einen kleinen aber feinen Unterschied zwischen Zertifizierung und Spezifikation.

Für mich als Nutzer wäre es halt schon interessant, wenn die paar IP-Geräte auch immer die gleiche KNX-Adresse bekämen. In den meisten Fällen ist es aber nur Kosmetik, daher will ich das Thema auch nicht weiter treiben.

Da stimme Ich Dir zu. Auch aus Kosmetischen Gründen aber auch der Sicherheitsaspekt ist nicht zu vernachlässigen. Durch eine feste Zuordnung wäre beim Loggen der KNX Telegramme eine eindeutige Zuordnung von PA zu Client möglich.

Ich denke hier Bedarf die Zertifizierung einer Überarbeitung und dann wäre dieses Feature möglich. In den meisten Fällen würde Ich "befürchten" dass die KNX dann eher die Spezifikationen anpasst und nicht die Zertifizierung, aber im Fall hier macht das IMHO wenig Sinn.

P.S.: Ich will nicht ausschliessen dass Ich etwas in den Spezifikationen übersehen habe, habe sie aber eben nochmal sicherheitshalber durchsucht ohne etwas zu finden was die Zertifikation untermauern würde.

Gruss,
Gaston

Gruss,
Gaston

[saft6luck]

Denkbar wäre natürlich ein kleines Tool mit GUI, das die paar Telnet-Kommandos absendet. Geplant ist von unserer Seite aber erst mal nichts. An der ETS-Applikation wird es sicher auch keine Änderungen mehr geben (Kosten).

Ja, meinte auch eher die Flash-App, aber die geht ja über den Falcon und da gibt es dann Hürden zu überwinden ...

Ich war hier leider nicht deutlich genug. Der KNX-Standard sieht zwingend vor, dass immer der erste freie Tunnel an ein anfragendes Gerät vergeben wird. Das wird in der Zertifizierung so auch getestet. Bei einem zertifizierten Gerät hat man hier also erst mal keinen Freiraum.

Ich meinte das schon so: Das ist nur der Zertifizierungstest, zusätzlich kann man durchaus weitere Funktionen einbauen - machen andere Hersteller ja auch.

Z.B. wenn es darum geht, ob das Gerät den Tunnel wieder ordentlich schließt und zugänglich macht, ist das Ergebnis erst einmal nicht unterschiedlich (frag mich wie so mancher Router den Test bestanden hat, aber der Test wird ja nur einmal durchgeführt ).
Erst nach Parametrierung einer möglichen IP-KNX-Zuordnung würde sich evtl. eine Änderung ergeben (hängt ja auch von den, für diesen Test verwendeten IP-Adressen ab - die Tunnel kann man ja vom gleichen Rechner aus öffnen). Diese Parametrierung wird aber eh nicht getestet.

BTW für Anforderungen gilt doch: "should" ist unverbindlich und "shall" verbindlich.

Für mich als Nutzer wäre es halt schon interessant, wenn die paar IP-Geräte auch immer die gleiche KNX-Adresse bekämen. In den meisten Fällen ist es aber nur Kosmetik, daher will ich das Thema auch nicht weiter treiben.

[salixer]

Sicherlich sinnvoll wäre eine einheitliche Konfigurationsmöglichkeit für alle KNX-Router, trotzdem, was der Enertex-Router hier bietet ist wirklich super und einfach zu bedienen.

Evtl. könnte man diese Möglichkeiten in das Tool zum Gerät einbauen?

Denkbar wäre natürlich ein kleines Tool mit GUI, das die paar Telnet-Kommandos absendet. Geplant ist von unserer Seite aber erst mal nichts. An der ETS-Applikation wird es sicher auch keine Änderungen mehr geben (Kosten).

Man kann auch weitere Funktionen einbauen, z.B.:
- sich die IP-Adressen der anfragenden Geräte merken und immer den entsprechenden Tunnel zuweisen (bzw. die gleiche KNX-Adresse für das IP-Gerät verwenden)
- Konfigurationsmöglichekeiten vorsehen, um die Adressen zuzuordnen
- etc.

Ich war hier leider nicht deutlich genug. Der KNX-Standard sieht zwingend vor, dass immer der erste freie Tunnel an ein anfragendes Gerät vergeben wird. Das wird in der Zertifizierung so auch getestet. Bei einem zertifizierten Gerät hat man hier also erst mal keinen Freiraum.
Zitat aus dem entsprechenden Test:

Description: Two tunnel connections are opened, then the first one is closed, and a third one opened. The returned tunnel addresses are checked.
Expectation: If the device supports multiple tunnel connections, then the third returned address should equal the first one.

[saft6luck]

Laut Standard erfolgt die Einstellung der Tunneladressen eigentlich über KNX-Telegramme. So macht das z.B. auch die ETS. Die Möglichkeit das per Telnet ebenfalls einzustellen ist lediglich ein AddOn.

Sicherlich sinnvoll wäre eine einheitliche Konfigurationsmöglichkeit für alle KNX-Router, trotzdem, was der Enertex-Router hier bietet ist wirklich super und einfach zu bedienen.

Evtl. könnte man diese Möglichkeiten in das Tool zum Gerät einbauen?

Der Standard sieht leider keine Möglichkeit vor, Tunnel an bestimmte Geräte zu vergeben. Einem anfragenden Gerät wird also immer der erste freie Tunnel zugewiesen.

Man kann auch weitere Funktionen einbauen, z.B.:
- sich die IP-Adressen der anfragenden Geräte merken und immer den entsprechenden Tunnel zuweisen (bzw. die gleiche KNX-Adresse für das IP-Gerät verwenden)
- Konfigurationsmöglichekeiten vorsehen, um die Adressen zuzuordnen
- etc.

Schön wäre z.B. eine Art "DHCP-Server", also ein "MAC/IP auf KNX"-Management für die beiden Enertex-Geräte, damit die IP-Geräte immer eine einheitliche KNX-Adresse bzw. den gleichen Tunnel bekommen.

[Gaston]

KNXnet/IP Routing nutzt Multicast, das muss dann natürlich auch im LAN weitergeleitet werden. Bei den managed Switches, die ich bis jetzt benutzt habe, war das auch immer standardmäßig aktiviert. Das kann aber bei anderen Switches natürlich anders aussehen.

Jeder Switch sollte multicast standardmässig durchlassen, dies bezieht sich jedoch nicht unbedingt auf alle multicasts da IGMP snooping benutzt werden kann.

Wenn der KNX/IP Router sich per IGMP in die Gruppe registriert ist der Switch oder dessen Konfiguration klar Schuld, ansonsten der KNX/IP Router da IGMP zwingend ist.

Gruss,
Gaston

[enertegus]

Ok ein Problem habe ich schonmal gelöst indem ich den Router zweimal mit Strom versorgt habe, einmal so wie es in der Anleitung steht und noch einmal an die Busklemme.

Die Busklemme ist keine Stromversorgung. Wenn der Bus nicht angeschlossen wird, so erscheint im Display "KNX Down".
EDIT: Und was hat das mit Parallels zu tun?

[McCorc]

Ok ein Problem habe ich schonmal gelöst indem ich den Router zweimal mit Strom versorgt habe, einmal so wie es in der Anleitung steht und noch einmal an die Busklemme. Das sollte in der Anleitung auf jeden Fall aktualisiert werden, sonst weiß man das nicht.
Jetzt ist er auch über KNXnet/IP ansprechbar..

[McCorc]

Ja mit MAC auf einer VM (wobei Parallels deutlich integrierter ist als nur eine VM) per ETS den IP Router konfigurieren.

Wobei ich auch ohne VM mit direktem Windows 8 einige Probleme habe. Ich habe den Router parametrisiert (alles auf default), eine statische IP und eine physikalische Adresse vergeben. Aber in der Kommunikationsschnittstelle vom ETS wird er nur als KNnetX/IP Routing und über seine Multicast Adresse erkannt. Als KNXnet IP wird er aber -trotz korrekter IP-Adresse- nicht erkannt. Ich habs mit Patchkabel und auch mit Crossover kabel versucht.
Über das KNXnet/IP Routing kann ich zwar auch Geräte parametrisieren aber wenn ich Firmwareupdates einspielen will, erkennt das Fimware-Tool das Gerät nicht.
Und ist es auch normal, dass ich jedesmal wenn ich irgendein Gerät programmieren will, sowohl den Programmierknopf des Geräts und auch des Routers drücken muss? Dann müsste man ja ständig runter in den Keller?

[enertegus]

Hat es eigentlich jemand geschafft den Enertex IP Router per Mac (Parallels) zu programmieren? Bei mir hängt er an "Programmiertaste drücken" fest. Mit "normalem" Windows klappt es.

Wie jetzt: Mit Mac die ETS bedienen auf der VM?

[McCorc]

Hat es eigentlich jemand geschafft den Enertex IP Router per Mac (Parallels) zu programmieren? Bei mir hängt er an "Programmiertaste drücken" fest. Mit "normalem" Windows klappt es.

[salixer]

1. PoE-Switches sind meistens managebar und lassen Standard wohl keine Multicast-Verbindungen zu ... hat mir der Admin dann gemacht, nachdem ich ihn fragte. Da muß man aber erst mal d´rauf kommen. Alternativ muß man eben einen dummen Switch + 24VDC nehmen.

KNXnet/IP Routing nutzt Multicast, das muss dann natürlich auch im LAN weitergeleitet werden. Bei den managed Switches, die ich bis jetzt benutzt habe, war das auch immer standardmäßig aktiviert. Das kann aber bei anderen Switches natürlich anders aussehen.

2. Die Einstellung der 5 Tunnel und physikalischen KNX-Adressen z.B. mit putty_0.63 ist gelinde ausgedrückt eine Reise in die 90er Jahre.

Laut Standard erfolgt die Einstellung der Tunneladressen eigentlich über KNX-Telegramme. So macht das z.B. auch die ETS. Die Möglichkeit das per Telnet ebenfalls einzustellen ist lediglich ein AddOn.

3. Hat man sich in der ETS Dummys z.B. für Panels oder seinen Programmier-PC angelegt und betitelt, damit man diese im Monitor identifizieren kann, verschieben sich die Tunnel, sobald sich einer abmeldet. Das bedeutet in dem Projekt z.B., wenn ein Panel neu gestartet wird, das B&O-Gateway aber noch online bleibt, schiebt dieses sich einen Tunnel vor. Ergo weiß man im EIB nie, von welchem IP-Gerät Telegramme gesendet werden.

Der Standard sieht leider keine Möglichkeit vor, Tunnel an bestimmte Geräte zu vergeben. Einem anfragenden Gerät wird also immer der erste freie Tunnel zugewiesen.

4. Ich hatte anfangs die Hauptlinie als TP belassen und wollte mit 2 IPR200REG die 6 FAP, das B&O-Gateway, meinen Programmier-PC anmelden, doch 2 Router in einer Hauptlinie machten richtig Chaos = geht nicht, steht aber nirgends.

Es dürfen nicht mehrere Router auf einer Linie sein, sonst können Schleifen entstehen:
- Router 1 sendet ein Telegramm vom Bus auf das LAN
- Router 2 empfängt das Telegramm auf dem LAN und sendet es auf den Bus
- Router 1 empfängt das Telegramm wieder auf dem Bus und die Schleife beginnt von vorn

[EIBY]

ENERTEX Router = JUNG IPR200REG

Ja, zweifellos: besser als gar nichts (andere Geräte/Hersteller), ergo der Einäugige unter den Blinden ;-)
Bekäme der Hersteller die feste Vergabe der Tunnel und damit die Identifikation der IP-Geräte, die auf den KNX zugreifen, perspektivisch besser/fix gehandelt?
Kann sein, daß mir i.d.S. Telegramme und Koppler das Basiswissen fehlt, jedoch half mir der Link zur Topologie, den ich mir auch wirklich angesehen habe, nicht weiter. Was macht der IP-Router bei welcher Einstellung mit den Telegrammen und was muß ich einstellen, damit ich mit meinem Programmier-PC am IP-Router EG die Telegramme der Wetterstation der Linie DG bekomme (3 Linien: EG, OG, DG)? Da ich Visualisierungen in jeder Etage habe, müßte ich m.E. quasi alle Telegramme weiterleiten, oder? Wie verhindere ich, daß unbeantwortete Telegramme eines FAP aus dem DG vom IP-Router DG zurück kommen oder gar von den anderen beiden IP-Routern EG und OG nochmals getrippelt werden?

[enertegus]

2. Die Einstellung der 5 Tunnel und physikalischen KNX-Adressen z.B. mit putty_0.63 ist gelinde ausgedrückt eine Reise in die 90er Jahre.

Bei den anderen Geräten wird das eben nur automatisch vergeben und das wars. Hier hast Du eben beim Enertex Router wie auch bei der Schnittstelle die Möglichkeit, das zu ändern.
Zu den KNX Eigenheiten wurde ja schon was gesagt, das ist aber nicht herstellerabhängig sondern einfach so festgelegt.

[SnowMaKeR]

1. PoE-Switches sind meistens managebar und lassen Standard wohl keine Multicast-Verbindungen zu ... hat mir der Admin dann gemacht, nachdem ich ihn fragte. Da muß man aber erst mal d´rauf kommen. Alternativ muß man eben einen dummen Switch + 24VDC nehmen.

zu 1: Hmm, das hat aber nix mit den IP-Routern von Enertex oder Jung oder Gira zu tun.
Das ist im KNX halt so und muss immer berücksichtigt werden.
Das gleiche Problem wird es mit Weinzierl, ABB und allen anderen auch geben.

3. Hat man sich in der ETS Dummys z.B. für Panels oder seinen Programmier-PC angelegt und betitelt, damit man diese im Monitor identifizieren kann, verschieben sich die Tunnel, sobald sich einer abmeldet. Das bedeutet in dem Projekt z.B., wenn ein Panel neu gestartet wird, das B&O-Gateway aber noch online bleibt, schiebt dieses sich einen Tunnel vor. Ergo weiß man im EIB nie, von welchem IP-Gerät Telegramme gesendet werden.

Ja, das ist nicht so schön. Aber für jedes Gerät extra eine eigene Schnittstelle zu kaufen ist auch nicht gerade eine schöne Lösung.
Es wird halt immer der nächste freie genommen. Ist auf der anderen Seite auch schön, dass man isch nicht kümmern muss.

4. Ich hatte anfangs die Hauptlinie als TP belassen und wollte mit 2 IPR200REG die 6 FAP, das B&O-Gateway, meinen Programmier-PC anmelden, doch 2 Router in einer Hauptlinie machten richtig Chaos = geht nicht, steht aber nirgends.
FAZIT: aufgrund meiner >50T Telegramme pro Stunde weiß ich momentan nicht, ob die FAP unaufhörlich die Read-Telegramme senden und/oder von den Routern permanent weitergeleitet werden ... quasi PingPong mit den Read-Telegrammen spielen.

So ist das halt im KNX und der Topologie: Topologie - KNX/EIB - Lexikon - KNX-User-Forum

[EIBY]

ENERTEX Router = JUNG IPR200REG

Ich habe 3 o.g. IP-Router von JUNG im Einsatz und hatte anfangs riesige Probleme, von denen ich nicht weiß, ob sie tatsächlich ausgeräumt sind:
1. PoE-Switches sind meistens managebar und lassen Standard wohl keine Multicast-Verbindungen zu ... hat mir der Admin dann gemacht, nachdem ich ihn fragte. Da muß man aber erst mal d´rauf kommen. Alternativ muß man eben einen dummen Switch + 24VDC nehmen.
2. Die Einstellung der 5 Tunnel und physikalischen KNX-Adressen z.B. mit putty_0.63 ist gelinde ausgedrückt eine Reise in die 90er Jahre.
3. Hat man sich in der ETS Dummys z.B. für Panels oder seinen Programmier-PC angelegt und betitelt, damit man diese im Monitor identifizieren kann, verschieben sich die Tunnel, sobald sich einer abmeldet. Das bedeutet in dem Projekt z.B., wenn ein Panel neu gestartet wird, das B&O-Gateway aber noch online bleibt, schiebt dieses sich einen Tunnel vor. Ergo weiß man im EIB nie, von welchem IP-Gerät Telegramme gesendet werden.
4. Ich hatte anfangs die Hauptlinie als TP belassen und wollte mit 2 IPR200REG die 6 FAP, das B&O-Gateway, meinen Programmier-PC anmelden, doch 2 Router in einer Hauptlinie machten richtig Chaos = geht nicht, steht aber nirgends.
FAZIT: aufgrund meiner >50T Telegramme pro Stunde weiß ich momentan nicht, ob die FAP unaufhörlich die Read-Telegramme senden und/oder von den Routern permanent weitergeleitet werden ... quasi PingPong mit den Read-Telegrammen spielen.