KNX-Bridge wechselt nach Offline

[murpele]

Hallo Achim,
ich bin gerade dabei mich etwas in die Materie einzuarbeiten.
knxd habe ich mir noch gar nicht angeschaut. Wenn ich es aber richtig im Kopf habe, kann man entweder knxd oder das KNX-Binding von openhab verwenden. Die Vorgehensweise wäre also, dass ich das KNX-Binding deinstallieren und danach knxd installiere. Korrekt?
Was mir dann aber nicht klar ist: Wie muss dann meine knx.things Datei aussehen?
Und: knxd funktionieriert sowohl mit einer IP- als auch einer USB-Schnittstelle. Da ich beide habe: Welche sollte ich idealerweise verwenden?
Ich bräuchte da mal ein Howto, an dem ich mich als Anfänger entlanghangeln kann...
Viele Grüße
Holger

[am1337]

Hallo Holger,
du nutzt das Binding in beiden Fällen. Wenn ich mich recht erinnere gab es bei mir Probleme mit meinem Weinzierl-Interface und dem parallelen Zugriff von OpenHab und ETS, genau weiß ich es aber nicht mehr. Mein Interface kann auch nur im Tunnel-Modus arbeiten und nicht im Router-Modus. Über knxd geht dann beides.
Ich nutze die IP-Schnittstelle. USB hat mein Interface nicht.

Das ist meine Konfiguration:

config.ini (knxd)

Code: Alles auswählen

[main]
addr = 1.1.249
client-addrs = 1.1.252:255
connections = server,ipt

[ipt]
ip-address = IP DES INTERFACES

[server]
server = ets_router
discover = true
; debug = debug-server
router = router
tunnel = tunnel

[debug-server]
name = mcast:knxd

[router]
filters = A.pace

[A.pace]
delay = 50
filter = pace

[tunnel]
; filters = log

knx.things (Auszug)

Code: Alles auswählen

Bridge knx:ip:bridge [
  
	ipAddress="DIE IP-ADRESSE VON KNXD", 
	type="TUNNEL"
	
	]
	
	{
		Thing device generic [
		]
		{
			Type switch : 			Day_Night				"Tag Nacht"					[ ga="0/0/1"]
			...

docker-compose.yml (Auszug)

Code: Alles auswählen

  knxd:
    image: michelmu/knxd-docker
    container_name: knxd
    volumes:
      - /var/docker/knxd/config.ini:/etc/knxd.ini

    restart: always
    network_mode: host  

Das ist sicherlich nicht die optimale Konfiguration, läuft bei mir aber schon lange stabil. Der Container läuft sicher auch ohne dem Netzwerkmodus "Host". Da ich aber diesen Modus für meine PBX brauche, nutze ich einfach das Host-Netzwerk für alle Container.

VG Achim

[murpele]

Hallo Achim,
danke für Deine Erläuterung.

Docker verwende ich nicht. Auf meinem Pi4 läuft openhabian und ich versuche den knxd daemon nun auf dem gleichen System zum Laufen zu bekommen. Bisher leider aber erfolglos.

Mein Problem ist: Mir ist die gesamte KNX-Adresslogik leider noch ziemlich unverständlich.
Jedes KNX-Gerät hat eine Adresse (z.B. einer meiner Schaltaktoren hat die 1.1.2
Dann gibt es die Gruppenadressen (GA). Das Licht in der Küche hat z.B. 0/2/22

In der ETS5 habe ich mein IP-Gateway angegeben. Mit seiner IP-Adresse: 192.168.2.x und dort steht auch die 'individual Adresse': 15.15.242
Ich nehme an, dass dies also die KNX-Adresse meines Gateway ist und ich hätte gedacht, dass ich diese Adresse nun in die /etc/knxd.ini eintragen muss. Dein Beispiel lautet ja:

Code: Alles auswählen

[main]
addr = 1.1.249
client-addrs = 1.1.252:255
connections = server,ipt

Wenn ich das auf meine Gateway-Adresse ändere: Was trage ich dann unter 'client-addr' ein?

Was mich stutzig macht: Kontrolliere ich mit

Code: Alles auswählen

sudo systemctl status knxd.service

den KNX Daemon sehe ich, dass der Dienst für ein paar Sekunden läuft:

Code: Alles auswählen

knxd.service - KNX Daemon
     Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2023-01-01 21:55:39 CET; 29s ago
TriggeredBy: ● knxd.socket
   Main PID: 21040 (knxd)
      Tasks: 1 (limit: 4915)
        CPU: 50ms
     CGroup: /system.slice/knxd.service
             └─21040 /usr/bin/knxd /etc/knxd.ini

Nach ein paar Sekunden bricht der Daemon aber ab:

Code: Alles auswählen

knxd.service - KNX Daemon
     Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Sun 2023-01-01 21:56:21 CET; 4s ago
TriggeredBy: ● knxd.socket
    Process: 21040 ExecStart=/usr/bin/knxd $KNXD_OPTS (code=exited, status=1/FAILURE)
   Main PID: 21040 (code=exited, status=1/FAILURE)
        CPU: 70ms

journalctl -u knxd --since "1 min ago" sieht dann z.B. wie folgt aus:

Code: Alles auswählen

Jan 01 22:16:21 openhabian knxd[23175]: F00000105: [12:ipt] Link down, terminating
Jan 01 22:16:21 openhabian systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Jan 01 22:16:21 openhabian systemd[1]: knxd.service: Failed with result 'exit-code'.
Jan 01 22:16:31 openhabian systemd[1]: knxd.service: Scheduled restart job, restart counter is at 56.
Jan 01 22:16:31 openhabian systemd[1]: Stopped KNX Daemon.
Jan 01 22:16:31 openhabian systemd[1]: Starting KNX Daemon...
Jan 01 22:16:31 openhabian systemd[1]: Started KNX Daemon.
Jan 01 22:16:50 openhabian knxd[23210]: F00000105: [12:ipt] Link down, terminating
Jan 01 22:16:50 openhabian systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Jan 01 22:16:50 openhabian systemd[1]: knxd.service: Failed with result 'exit-code'.
Jan 01 22:17:00 openhabian systemd[1]: knxd.service: Scheduled restart job, restart counter is at 57.
Jan 01 22:17:00 openhabian systemd[1]: Stopped KNX Daemon.
Jan 01 22:17:00 openhabian systemd[1]: Starting KNX Daemon...
Jan 01 22:17:00 openhabian systemd[1]: Started KNX Daemon.
Jan 01 22:17:05 openhabian knxd[23247]: F00000105: [12:ipt] Link down, terminating
Jan 01 22:17:05 openhabian systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Jan 01 22:17:05 openhabian systemd[1]: knxd.service: Failed with result 'exit-code'.

Solange der knxd Dienst nicht läuft, brauche ich nicht mit openhab starten...

Was mache ich falsch? Ist es ein Problem, dass ich knxd direkt auf openhabian (also ohne die Verwendung von Docker) laufen lassen möchte? Die Installation von openhabian ist so easy, dass ich ungern auf eine Raspberry Pi OS Installation mit Docker und openhab wechseln möchte. Ich sehe (noch) keinen Vorteil für mich, wenn ich die Dienste, die ich auf openhabian laufen habe, in mehreren Container kapsle.

Gruß
Holger

[udo1toni]

Also zuerst mal: knxd Ist ein Software Stack, um auf den knx Bus zuzugreifen. Der Stack unterstützt verschiedenste Zugriffsverfahren und stellt im Gegenzug selbst den knx Bus über IP Tunnel und/oder Router sowie einem Socket zur Verfügung.
Solange aber nur eine Verbindung über das Tunnel Interface aufgebaut wird, sollte die Kommunikation auch ohne knxd stabil sein. Ich nutze hier ein Weinzierl 730 mit fünf Tunneln und weiß daher aus eigener Erfahrung, dass die Tunnel nicht so stabil sind, wenn mehrere parallel betrieben werden. Andererseits braucht es gewöhnlich auch nur eine Verbindung.

Zu knxd: das lässt sich einfach über openhabian-config nachinstallieren. Was die Konfiguration von knxd betrifft, so ist die leider nicht ganz trivial. Zudem kommt es auf die exakte Version von knxd an, wie es zu konfigurieren ist, und ich habe den Eindruck, dass openhabian-config das nicht zuverlässig korrekt macht.

Du müsstest knxd über die Datei /etc/knxd.ini konfigurieren (siehe letzte Zeile der Ausgabe von systemctl status knxd)

Zur Adresslogik in knx:

Jedes Gerät (genauer jeder Buskoppler) hat eine physikalische Adresse (im englischen individual address... die unterschiedlichen Bezeichnungen machen es auch nicht einfacher...). Im Auslieferungszustand ist jedes Gerät auf die Adresse 15.15.255 eingestellt. Die Adresse ist insgesamt 16 Bit breit, unterteilt in 4.4.8 Bit. Die physikalische Adresse spielt in der gewöhnlichen Kommunikation eine untergeordnete Rolle, allerdings gibt es "besondere" Adressen für besondere Geräte. x.y.0 ist beispielsweise immer ein Linien- oder Bereichskoppler. Innerhalb einer Linie können bis zu 256 Geräte adressiert werden, wobei aber nur bis zu 64 Geräte physisch an einer Linie angeschlossen werden dürfen. Möchte man mehr Geräte an einer Linie anschließen, so benötigt man einen Linienverstärker, letztlich verwendet man in einer Linie bis zu drei Linienverstärker, um bis zu vier mal 63 Geräte anzuschließen (Linienkoppler und Linienverstärker zählen als Gerät am Bus) und bis zu 15 Lnien können zu einem Bereich gekoppelt werden, bis zu 15 Bereiche können an einem Backbone angebunden werden.
Heutzutage werden gewöhnlich immer IP-Router verbaut und direkt auf den Backbone verbunden, weil der Datendurchsatz auf IP-Seite mit 10MBit/s tausendmal höher ist als die 10kBit/s, die auf der TP-Seite (Twisted Pair...) verwendet werden - knx (bzw. EIB, das ist der ursprüngliche Name) wurde bereits in den 80er Jahren entwickelt, da war IP noch unerschwinglich...

Wie gesagt, die physikalische Adresse spielt ansonsten eine untergeordnete bei der normalen Kommunikation, sie ist vor allem beim programmieren der Geräte wichtig, natürlich wird auch im Normalbetrieb immer die physikalische Adresse mit übertragen (kann man in der ETS im Gruppen-/Busmonitor sehen), wichtiger ist jedoch die GruppenAdresse.

Jedes Gerät am knx Bus hat Kommunikationsobjekte, und diese Kommunikationsobjekte werden mit GA verknüpft, dabei kann ein KO mit mehreren GA verknüpft werden. Die Kommunikation des KO wird über Flags gesteuert, welche darüber bestimmen, ob ein KO überhaupt kommuniziert (K), senden darf (Ü), empfangen darf (R), Read Requests beantworten darf (L), Antworten auf Read Requests als Befehl interpretieren soll (A) oder selbst Read Requests senden darf (I).
Sollte das KO Daten senden dürfen, wird es das aber ausschließlich auf der ersten verknüpften GA tun (gleich ob Ü-,L- oder I-Flag).
Die GA sind ebenfalls 16 Bit breit, aber gewöhnlich in 5/3/8 Bit aufgeteilt. GA sind universell, es gibt keinerlei Regeln, welche GA wozu verwendet wird. In aktuellen ETS Versionen kann man die Aufteilung der Bits beliebig setzen, z.B. 4/12 oder auch 16, das spielt aber ebenfalls nur eine untergeordnete Rolle. Die Aufteilung ist rein virtuell, im Gerät geht es nur um 16 Bit, deshalb können die GA einfach ineinander umgerechnet werden, es ist also egal, ob man bei 5/3/8-Aufteilung als GA 0/1/1 sendet oder mit Aufteilung 4/12 als GA 0/257.

So oder so sind GA die zentrale Form der Kommunikation auf dem knx Bus.
Die Kommunikation ist grundsätzlich gerichtet, ein Gerät sollte also auf einer GA entweder senden oder empfangen, aber nur im Ausnahmefall beides (das wäre, wenn z.B. openHAB einen Read Request auf einer GA sendet, was vom Gerät registriert wird und mit dem Status des KO quittiert wird. Deshalb darf auch nur ein KO pro GA auf Read Requests antworten, das ist quasi oberstes Gesetz. Nur Status-GA dürfen lesbar sein (diverse Hersteller halten sich nicht an diese Regel und setzen L-Flags in KO, die nicht exklusiv senden )
Wenn ein Channel in beiden Richtungen funktioniert, werden also immer zwei GA im Spiel sein, wobei openHAB auf der ersten GA sendet und auf allen GA empfängt (identisch zum restlichen knx-System). Es geht hierbei aber um zwei GA innerhalb eines Parameters. Ein Channel kann mehrere Parameter haben, z.B. ein Rollershutter verwendet lang, kurz und position, ein Dimmer switch und position, optional auch increaseDecrease, die doppelte GA ist immer dort einzutragen, wo der vollständige Status zu erwarten ist, im Beispiel also jeweils position, weil hier 0% - 100% übertragen werden.

[murpele]

Danke für die KNX-Nachhilfe...
...ich stelle fest, dass ich mich damit bisher nicht ausreichend auseinandergesetzt habe.

Mein Haus ist ca. 20 Jahre alt und die EIB-Installation hat damals ein kleines Vermögen gekostet. Obwohl ich mich selbst als technikaffin bezeichne, habe ich mich jedoch nie wirklich mit der ETS und meiner KNX-Installation beschäftigt. Ich habe nie die Zeit dazu gefunden und stattdessen lieber mit diversen Rasperry PIs rumgespielt. D.h. bisher waren meine 'zwei Welten' komplett getrennt. Auf der einen Seite habe ich etwas Homematic-Technik im Einsatz (RasperryMatic), die ich zusammen mit ein paar Shellys und Z-Wave Komponenten mit openhabian zusammengeschlossen haben. Auf der anderen Seite gibt es meine KNX-Elektroinstallation.
Ohne eine IP-Schnittstelle konnte diese zwei Welten bisher nicht zusammenschließen und openhabian zur Steuerung meiner KNX-Komponenten verwenden. Diese Lücke möchte ich nun (endlich!) schließen. Da mein ganzen Haus über eine KNX-Installation verfügt (und ich nun etwas mehr Zeit zur Verfügung habe), habe ich mir eine IP-Schnittstelle (MDT SCN-IP000.03 IP) gekauft und versuche gerade die KNX-Aktoren in openhabian einzubinden.

Das hat ja grundsätzlich auch funktioniert - wenn denn nur nicht die regelmäßigen Verbindungsabbrüche wären. Weder benutze ich die ETS noch ist mir sonst irgendwie bekannt, dass es mehrere Tunnel auf der IP-Schnittstelle geben könnte. Ich habe nur das KNX-Binding, mit welchem ich die Schnittstelle ansprechen möchte. An der Existenz von mehreren Tunnel dürfte die Instabilität also nicht liegen.

Achims Rat folgend habe ich gestern über openhabian-config den knxd Daemon installiert und ja, ich editiere die /etc/knxd.ini
Die /etc/knxd.conf besteht nur aus einer Zeile:

Code: Alles auswählen

KNXD_OPTS=/etc/knxd.ini

Leider ist mir nun nicht klar, wie die knxd.ini auszusehen hat. Aktuell sieht sieh wie folgt aus (unter "[main]" spiele ich wegen meiner Unkenntnis ziemlich planlos mit verschiedenen Adressen rum):

Code: Alles auswählen

[main]
;addr = 1.1.249
;client-addrs = 1.1.252:255
addr = 15.15.242
client-addrs = 15.15.252:255
connections = server,ipt

[ipt]
ip-address = 192.168.2.250

[server]
server = ets_router
discover = true
; debug = debug-server
router = router
tunnel = tunnel

[debug-server]
name = mcast:knxd

[router]
filters = A.pace

[A.pace]
delay = 50
filter = pace

[tunnel]
; filters = log

Kann es sein, dass meine IP-Schnittstelle von MDT "einen Schlag" hat? Ohne knxd war die Anbindung an openhabian grundsätzlich ziemlich einfach. Mi t meinen zwei Dateien (knx.things und knx.items) hatte ich schnellen Erfolg. Ich wäre grundsätzlich "happy" - wenn den (wie bereits gesagt), die Verbindung stabil wäre.

Viele Grüße
Holger

[udo1toni]

Dass die Schnittstelle selbst defekt ist, ist natürlich immer möglich, wenn auch nicht sehr wahrscheinlich (aber da neues Gerät: warum nicht?).
Mögliche Fehlerquellen sind erfahrungsgemäß eher bei der Verkabelung zu suchen, also prüfe mal das LAN-Kabel und gerne auch den TP-Anschluss.
Ich hatte bei mir schon mal einen defekten Port am Switch, das war allerdings auch erst nach einigen Jahren Betrieb, so dass ich das leicht erkennen konnte.
Weiterhin nutzt das Gerät default ein kurzes Timeout für UDP, das kann man umkonfigurieren. Der Parameter heißt "Langsame Tunneling Verbindungen unterstützen" und wäre das erste, was ich mal auf Verdacht auf "Ja" umstellen würde.

Die physikalische Adresse muss grundsätzlich zu der Linie passen, in der das Gerät angeschlossen ist. Da die physikalische Adresse für jedes Gerät frei gewählt werden kann, musst Du vorher prüfen, welche Adresse Du verwenden kannst.

Allerdings wirst Du dafür eine ETS brauchen, ohne wird es nicht gehen. Es gibt aber eine kostenlose Version, mit der Du bis zu fünf Geräte konfigurieren kannst, das reicht zum Ermitteln der Busteilnehmer (Du willst ja nicht konfigurieren, nur erfahren, wer da so mitspielt) und Setzen der Parameter des IP-Interface vollkommen aus.

Wenn ich nicht etwas wesentliches übersehen habe, nutzt das Interface die knx Busspannung zur Stromversorgung. Da kommt dann die Frage auf, wo die Schnittstelle eingebunden ist. Auch wenn es keine Rolle spielen sollte, möchte ich eine Montage nahe dem knx Netzteil empfehlen.

Wie viele Busteilnehmer hast Du? Sind im Haus mehrere Linien verbaut? All das spielt hier eine Rolle, sollte aber aus der Dokumentation des knx Systems hervorgehen. Zur Dokumentation einer Elektroinstallation mit knx gehört übrigens das komplette ETS Projekt dazu.

Was knxd betrifft: [ipt] ip-address wäre die IP-Adresse der MDT. In der [main] Sektion wird mit addr angegeben, unter welcher Adresse knxd dem Bus gegenüber auftritt. Die client-addrs sind hingegen die Adressen, welche für Clients von knxd reserviert werden. Angefangen von der ersten Adresse, mit Doppelpunkt getrennt dann die letzte Stelle der letzten Adresse (es dürfen nur Adressen einer Linie verwendet werden). Keine der Adressen darf im knx System belegt sein. Im Beispiel wäre also 15.15.242 die physikalische Adresse von knxd dem Bus gegenüber und knxd Clients bekämen Tunnel mit den physikalischen Adressen 15.15.252 bis 15.15.255 zugewiesen.

openHAB selbst nutzt eine localAddress, das ist NICHT die physikalische Adresse des Interface, sondern eine weitere Adresse, welche ebenfalls an keiner Stelle sonst verwendet werden darf. Standard ist hier 0.0.0 und man sollte die auch nur dann ändern, wenn man verstanden hat, wie dieser Parameter funktioniert (0.0.0 ist eine in ETS ungültige Adresse, man kann sie dort nicht verwenden, um ein Gerät damit zu konfigurieren)

Ach so, wo ich gerade openHAB schreibe... Die Smarthome Lösung heißt openHAB, nicht openhabian oder openHABian.
openHABian ist eine Scriptsammlung, mit der openHAB komfortabel aufgesetzt werden kann, wobei im Hintergrund noch jede Menge zusätzliche Software eingerichtet wird.
Für den Raspberry gibt es ein Image, welches Rasperry Pi OS lite enthält, ergänzt mit den vorinstallierten openHABian Scripten.

Es ist bei openHAB (eigentlich immer, wenn es um Technik geht) sehr wichtig, Dinge exakt zu benennen. Da sollte man nicht gleich zu Beginn schon "schlampen"

[murpele]

Der Unterschied von openHAB und openHABian ist mir bekannt. Ich habe bisher bewusst davon geschrieben, dass ich openhabian auf meinen Pi4 installiert habe (damit transparent ist, wie mein System aussieht).

Ich habe bei mir die ETS5 Professional installiert - aber im Prinzip noch nie wirklich verwendet. So wirklich intuitiv ist die Software nicht - vor allem dann, wenn einem diese ganze Adressierungslogik nicht wirklich klar ist.

Von meinem Elektriker habe ich damals keine echte EIB/KNX-Dokumentation erhalten - dies, obwohl man bei den Kosten eigentlich davon hätte ausgehen dürfen, dass ich eine Dokumentation auf handgebüttetem Papier in einem mit Blattgold verziertem Buch-Cover erhalte - mit handgemalten Zeichnungen/Illustrationen von namhaften Künstlern. Bei den Kosten hätte das m.E. dabei sein müssen...
Worauf ich damals aber bestanden habe: Das er mir die Projektdatei aus der ETS auf einem USB-Stick gibt. Diese habe ich damals mehrfach gesichert und darauf konnte ich nun aufsetzen (das Projekt wurde damals in der ETS3 angelegt und ich musste es in die ETS5 importieren).
Soweit ich das übersehen kann, sind in meinem Haus zwei Linien verbaut - und ja, die IP-Schnittstelle bekommt ihren Strom vom EIB-Netzteil, welches in ca. 30cm daneben verbaut ist. Ein Problem mit der Spannungsversorgung kann ich mir eigentlich nicht vorstellen - ich werde das aber zur Sicherheit kontrollieren.

Die LAN-Verkabelung werde ich dann als nächstes überprüfen. In meiner Unterverteilung habe eine RJ45-Dose die auf eines der Patchpanel im 19" Rack gelegt ist. Ich werde von meinem Switch direkt ein RJ45-Kabel zur IP-Schnittstelle ziehen - um auszuschließen, dass es an einem Problem innerhalb meiner CAT-Verkabelung liegt.

Und dann werde ich mich wohl doch mal mit der ETS5 auseinandersetzen...
Frage: Bietest Du (selbstverständlich gegen eine angemessene Vergütung / einem Stundensatz) Support an? Ich wäre sehr daran interessiert, dass mir jemand mal eine Einweisung in die ETS gibt (ich würde dafür meinen Screen sharen). Sich da aus dem (fast) Nichts in die ETS reinzufuchsen, empfinde ich als ziemlich anstrengend. Ich gehe davon aus, dass Du mir in relativ kurzer Zeit mehr Dinge zeigen/beibringen könntest, als ich mir in Wochen/Monaten alleine beibringen kann (ETS und openHAB).

Viele Grüße
Holger

[udo1toni]

Also, bis auf die Sache mit er Vergütung kann ich Dir gerne eine Einweisung in ETS geben. Ich weiß das Angebot einer Bezahlung zu schätzen, aber für mich ist das ein Hobby, ich habe Wissen angesammelt, welches ich gerne unentgeltlich teile, denn ich habe selbst auch nichts dafür gezahlt (außer vielleicht meine Zeit) Wichtiger ist mir dabei der OpenSource Gedanke, ich habe schon oft Hilfe im Netz erhalten, hier (openHAB, ETS) kenne ich mich aus und kann Anderen helfen.

Dass Du die Projektdatei hast, ist aber schon mal topp, da hat es schon viele Probleme gegeben, obwohl die Rechtslage da eindeutig ist.

[am1337]

...
Solange aber nur eine Verbindung über das Tunnel Interface aufgebaut wird, sollte die Kommunikation auch ohne knxd stabil sein. Ich nutze hier ein Weinzierl 730 mit fünf Tunneln und weiß daher aus eigener Erfahrung, dass die Tunnel nicht so stabil sind, wenn mehrere parallel betrieben werden. Andererseits braucht es gewöhnlich auch nur eine Verbindung.
...

Hallo Udo,

ich gehe auch davon aus, dass ich mit knxd eher einen Fehler im Weinzierl kompensiere als in OpenHab. Ich habe beim Weinzierl-Interface immer das Gefühl gehabt, dass abgebaute Verbindungen das Interface blockieren. Genauer untersucht habe ich aber nie, da es mit der oben beschriebenen Lösung stabil läuft.

Viele Grüße Achim

[udo1toni]

ich gehe auch davon aus, dass ich mit knxd eher einen Fehler im Weinzierl kompensiere als in OpenHab. Ich habe beim Weinzierl-Interface immer das Gefühl gehabt, dass abgebaute Verbindungen das Interface blockieren. Genauer untersucht habe ich aber nie, da es mit der oben beschriebenen Lösung stabil läuft.

Mein Eindruck dazu ist vor allem, dass ein zusätzlicher Tunnel sehr lange braucht, bis er etabliert ist und anschließend läuft dieser Tunnel nur langsam (vor allem im Vergleich zu einem bestehenden Tunnel).
DAs fällt mir aber nur auf, wenn ich eine Testumgebung auf knx aufschalte (also eine zweite openHAB Instanz). Dann denke ich dran, dass das nicht sauber funktioniert und beende beide Instanzen, bevor ich dann wieder nur eine von beiden verbinde.