Enertex IP Interface

[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..

[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?

[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

[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.

[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]

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.

[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