die vielen optionen erschaagen mich. Suche eine Konfig für OpenHab

[lo4dro]

Ich bin etwas erschlagen von den vielen Möglichkeiten die mir der knxd bietet.

Ich würde gerne den knxd als "Proxy" zwischen meinem KNX-Router und Openhab schalten.
Davon verspreche ich mir eine Reduzierung der Last auf dem KNX BUS bei gleichzeitiger bessere Verfügbarkeit von OpenHab.

Istzustand:
OpenHAB nutzt ein Router Verbindung für die Kommunikation mit dem KNX BUS


Nun suche ich eine passende Parametrierung für knxd

- was ist besser per Tunnel oder per Routing Verbindung zum KNX BUS aufzubauen?
- OpenHab und KNXd sollen die besser per Tunnel oder Routing miteinander kommunizieren?

knxd -e 15.15.151 -E 15.15.152:8 -u /tmp/eib -c -T -S -t1023 -b ipt:10.101.1.96

Die Parameter bedeutetet :
- c Caching aktiviert
-T KNXd stellt eine Tunnelverbindung zu Verfügung (wenn openhab und knxd auf dem selben PC laufen 127.0.0.1)
-S ????
-t <DEBUG>
-b KNXd baut per Tunnel einen Verbindung zum KNX Bus auf

[lo4dro]

Bin mir jetzt nicht sicher, ob diese Optionen Ideal sind.
Ich nutze jetzt.

/usr/bin/knxd -e 15.15.151 -E 15.15.152:8 -u /tmp/eib -c -D -T -R -S -b ipt:10.101.1.96

OpenHab habe ich als TUNNEL konfiguriert.

[vento66]

Nö!

/usr/bin/knxd -e 15.15.151 -E 15.15.152:8 -u /tmp/eib -c -D -T -R -S -b ipt:10.101.1.96

und

Ich würde gerne den knxd als "Proxy" zwischen meinem KNX-Router und Openhab schalten

beisen sich. Wenn Du schon einen Router in deiner Linie hast, dann darf knxd kein Routing machen. Du hast aber Routing eingestellt (-R)

Die Adresse des knxd muss zu deiner Linie passen, wieso bekommt er bei Dir 15.15.151? Du hast doch sicher keine Linie 15 bei Dir. Genau das selbe mit den Adressen die knxd vergibt. Die müssen auch in deine Topologie passen, und die ist normalerweise nicht 15.15.x oder?

[Smurf]

Äh, bitte nicht Probleme herreden wo keine sind.

Normalerweise konfiguriert man einen (Hardware)router so, dass er alle physischen Adressen A.B.XXX auf dem (Hardware)KNX-Bus sucht und alles Andere "draußen". Dieses KNX-Kabel bzw. die physischen Adressen auf ihm kann man, wenn man will, "Linie" nennen.

Der knxd ist nicht Teil dieser "Linie", folglich bekommt er irgendwelche anderen Adressen. Solange sie nicht doppelt vergeben sind und sie niemand wegfiltert (der knxd kann das nicht, folglich tut er es auch nicht) kann man sich beliebige Adressen aus dem Ärmel schütteln.

Mehr noch: wenn man zur Anbindung der Hardware nur den knxd verwendet, kann man den Begriff "Linie" in die Tonne treten. Es interessiert schlicht niemanden. Natürlich ist es trotzdem sinnvoll, die Geräte auf einem Bus alle mit derselben Adressgruppe zu versehen, aber zwingen tut dich (außer ggf. einem entsprechend konfigurierten Hardware-KNX-Router oder -interface) niemand dazu.

zum Thema "Router". Man kann manche Hardware (und den knxd) so einstellen, dass sie Multicast macht. Das ist dann ein Router und beim knxd die Option "-R -S". Man stelle sich das Resultat vor wie einen zusätzlichen KNX-Bus, an dem sämtliche Multicastteilnehmer dranhängen. Multicast funktioniert nicht in allen Netzen; manche Switches oder WLAN-Router sind bekannt dafür, dass sie schlicht vergessen, welche Multicastpakete wo hin sollen.

Man kann manche andere Hardware (und den knxd) so einstellen, dass sie tunnelt. Auf Hardwareseite nennt man das resultierende Gerät meistens "KNX-Interface" und beim knxd ist das die Option "-T -S" (als Server) oder "-b ipt:ZIEL" (als Client). Manche Hardware kann beides.

Man sollte nun keine Geräte mit mehr als einem Bus miteinander verbinden. "-RS -b ipt:ZIEL" mit einem ZIELgerät, das selber sowohl Multicast als auch Tunnel kann, geht somit in die Hose (d.h. ale Pakete kommen doppelt an. Mehr nicht, weil der knxd das merkt, ansonsten wären es sechs). Aber der Standardfall ist, dass die Dinger entweder nicht routen oder die Router-Funktion im Werkszustand aus ist, solange man sie nicht via ETS einschaltet.

Trotzdem solltest du in deinem Fall das -R weglassen, weil du es offensichtlich nicht brauchst.

[lo4dro]

das -R wird benötigt, wenn man zwei (oder mehrer) getrennte KNX-Lines hat, die alle per IP gekoppelt sind.
Und der KNXd selbst kann so ein Router sein? Passende Hardware am KNXd vorausgesetz?

Also
1.0.0 = IP-Router 1
2.0.0 = KNX-RF "Router" Line
5.0.0 = IP-Router 2
9.0.0 = IP-Router 3

Kann man vom Standart abweichend andere Ports Verwenden?
z.B. könnte man den Router-Server auf einen anderen Port stellen als den Router-Client Teil?
Und z.B. OpenHab konnte den als Router konfiguriert werden, aber auf einem anderen Port wie default.

[Smurf]

das -R wird benötigt, wenn man zwei (oder mehrer) getrennte KNX-Lines hat, die alle per IP gekoppelt sind.

Falsch. -R wird benötigt, wenn du einen Multicast-Router betreibst, der sich außerdem als Tunnel oder ETS-Zugang verdingen muss. Ansonsten reicht nämlich "-b ip:".

Wie, "getrennte KNX-Lines"? Wozu braucht man sowas? Der Sinn eines knxd ist doch gerade, verschiedene KNX-Busse zu verbinden.

Und der KNXd selbst kann so ein Router sein? Passende Hardware am KNXd vorausgesetz?

Der knxd *ist* so ein Router. Ob er mit den diversen Linien-oder-ws-auch-immer via am Rechner angestöpselter Hardware oder Multicast oder Tunnel redet, ist nebensächlich. Ob die Geräte, die sich mit ihm über Multicast unterhalten oder via Tunnel verbinden, einzlne Programme wie OpenHAB oder HomeAssistant oder … sind oder Gateways, hinter denen 100 weitere "Linien" hängen (ich hasse den Begriff "Linei", denn es führt zu Bergen von Missverständnissen darüber, wie KNX funktioniert), ist auch nebensächlich.

Kann man vom Standart abweichend andere Ports Verwenden?
z.B. könnte man den Router-Server auf einen anderen Port stellen als den Router-Client Teil?
Und z.B. OpenHab konnte den als Router konfiguriert werden, aber auf einem anderen Port wie default.

Ja, kann man alles, aber wieso solltest du das tun wollen? das ergibt keinerlei Sinn. Zumal es keinen "Client" oder "Server"-Modus gibt, sondern einen "Multicast als Transportmedium"-Modus (-b ip und einen "Multicast mit Gateway-Announcement für ETS, ggf. Support für Tunnelserver, etc.pp."-Modus (-DTRS).

[lo4dro]

Danke für die Fachkundige Erklärung.

Mein Ziel ist folgendes: ein KNX Projekt bestehend aus zwei IP-KNX Verbindungen. (+ KNX-RF)


1) KNX-Bus Haus1
Bus-IP Koppler:838 KNX BAOS Modul

2) KNX-Bus Haus2
Bus-IP Koppler: Enertex KNX-IP-Router

Beide Häuser hängen am gleichen LAN, das auch Multicast fähig ist.

Ziel:

1) beide KNX-BUS Systeme müssen miteinander GAs austauschen können.
2) ein Zentraler OpenHAB

Wen ich das richtig verstanden habe, bekommt der KNXd zwei "-b" Devices zugewiesen.
1) -b ft12cemi:/dev/ttyAMA0
2) -b ip: (oder ipt:<IP-Adresse>)

Wenn ich beim KNXd -b ip: benutze, dann sollten doch das 838 KNX BAOS Modul & der Enertex KNX-IP-Router per Multicast miteinander Kommunizieren.
Der Enertex KNX-IP-Router kann auch TUNNEL Verbindungen.

Openhab würde ich mit dem Tunnel Protokoll am KNXd anbinden, damit ich den GA-Cache nutzen kann.

Die Parametrierung vom KNXd würde so aussehen?

/usr/bin/knxd -e 15.15.151 -E 15.15.152:8 -u /tmp/eib -c -D -T -R -S -b ft12cemi:/dev/ttyAMA0 -b ip:

Für die ETS würde ich als Programmierschnittstelle den KNXd mit dem 838 KNX BAOS Modu benutzen.

[vento66]

Äh, bitte nicht Probleme herreden wo keine sind.

Ich versuchs mal so:
Verbindet sich knxd über tunneling auf den bestehenden Router/ Schnittstelle , bekommt der knxd eine PA aus dem Pool des Routers / Schnittstelle. Damit ist er auf der selben Linie wie der Router. Dann darf knxd selber nicht routing bereitstellen, bzw PA aus einer anderen Linie vergeben. Wird Routing trotzdem aktiviert, kommt es zu den doppelten Telegrammen oder Loops und sonstigen Fehlern, die im Moment mit grossen Aufwand künstlich kaschiert werden.
Wird knxd über routing mit der bestehenden Topologie verbunden, bekommt knxd eine PA aus der übergeordneten Linie. In dem Fall muss der knxd dann auch PA's aus dieser übergeordneten Linie vergeben. Alles andere ist keine saubere Toplogie.

[NilsS]

Zitat von lo4dro Beitrag anzeigen
das -R wird benötigt, wenn man zwei (oder mehrer) getrennte KNX-Lines hat, die alle per IP gekoppelt sind

Moin Matthias,

sag mal hast du das mal getestet? Ich habe ja für mein Multicast vom selben Host (dropped) immer noch keine Lösung gefunden. Technisch macht er doch dann das gleiche wie dort beschrieben, oder?

(recvall == 2 && memcmp (&r, &localaddr, sizeof (r)))

[lo4dro]

nein, noch bin ich nicht so weit.
Als erste erfolgt die Umstellung von Router auf das 38 KNX BAOS Modu.
Danach wird der Router ausgebaut.
Wenn danach alles mit OpenHab stabil läuft, dann kommt die zweite Line an die reihe.