[Problem] IOBroker KNX-Schnittstelle periodische Unterbrechnung

[StefanW]

Hallo Foristen,

ich hatte heute ein Gespräch mit dem Geschäftsführer von io:Broker, u.a. auch deswegen und ich habe darum gebeten, dass der zuständige Entwickler sich das möglichst bald ansehen möge, weil hier Kunden eben drauf warten. Die Info wurde gerne entgegengenommen und man hat sich für unseren Aufwand bedankt (die genaue Diagnose hat uns 2 Manntage gekostet).



lg

Stefan

[tws88_user]

Hallo Tom,

kannst du uns bitte noch sagen, wasd du hier im IOBroker einstellst, wenn du die Verbindung zum Timberwolf machst?



Viele Grüße,
Matthias

Hallo Matthias,

nur der Vollständigkeit halber:
Ich kann gar kein KNX-Send-Delay einstellen, wird bei mir nicht angezeigt.

Aber ihr habt ja schon rausgefunden, dass das Problem beim knx-Adapter zu suchen ist und dem Entwickler mitgeteilt.
Nochmals Danke!!!

Beste Grüße
Tom

Hallo Jungs,

ich bin mir gerade gar nicht sicher, ob ihr hier denselben iObroker-Adapter, resp. Version nutzt. Es existieren zwei verschiedne, einer wird aber nicht mehr weiterentwickelt. Ich nutze relativ unkompliziert diesen hier:

https://github.com/ioBroker/ioBroker.knx

Ich nutze die Version 1.0.20. es gibt schon 1.0.34, jedoch hatte ich mich der 20er bislang die wenigsten Probleme.

Nicht hundertprozentig das hier skizzierte Problem adressierend, trotzdem ein paar Erfahrungen von mir:

Im iOBroker Log - wahrscheinlich durch den Node Red-Adapter verursacht - habe ich ab und an Kollisionsmeldungen, dass der NRed Port belegt ist - das könnte in Kollisionen des entsprechenden Node Red KNX-Nodes mit den Tunneln der TWS-Schnittstelle begründet sein - so meine Vermutung.

Allerdings ist das bei mir weniger problematisch, da ich ja 2 Tunnel habe. Ein Neustart von Node Red oder des iOBrokers reicht dann meist aus. Das Problem habe ich nur in Parallelarbeit mit der ETS. Seit ich die Einstellungen für die Tunnel - wie von Göran @gbglace vorgeschlagen - vorgenommen habe (ab PA X.X.201 dann fortlaufend die 26 PA's vergeben).

Weil ich mit ihm schon einmal Kontakt hatte - zur Not könnte ich zusätzlich den Entwickler einmal kontaktieren und auf das Problem hinweisen, ggf. hat er ja ein Interesse daran, dieses Problem zu lösen.

[tws88_user]

Nur noch einmal zur Info für mich, Thomas. Wie genau hast du dieses Problem diagnostiziert?

Wie greifst du auf Alexa zu? Mittels entsprechendem iOBroker-Adapter?

Nun zum Problem:
Wenn in der KNX-Instanz im IOBroker die KNX-Schnittstelle des TWS eingestellt ist, unterbricht die Verbindung laut IOBroker-Log etwa alle 2 Minuten, um dann sofort wieder hergestellt zu werden (Alexa-Befehle genau in dieser kurzen Zeitspanne sind natürlich fehlerhaft).

[StefanW]

Aber ihr habt ja schon rausgefunden, dass das Problem beim knx-Adapter zu suchen ist und dem Entwickler mitgeteilt.Nochmals Danke!!!

Wir sind dran.

Wir haben nochmal den Standard studiert und festgestellt, dass wir in der Sache der NAT-Verbindungen (hinsichtlich der ansonsten zigtausend Prüfungen) relaxter sein dürfen, und werden das auch im Daemon umsetzen um kompatibler zu sein. Womöglich muss der Entwickler des Adapters bei io:Broker dann hier nicht mehr Hand anlegen.

lg

Stefan

[Tomtheripper]

Nur noch einmal zur Info für mich, Thomas. Wie genau hast du dieses Problem diagnostiziert?

Wie greifst du auf Alexa zu? Mittels entsprechendem iOBroker-Adapter?

Nun zum Problem:
Wenn in der KNX-Instanz im IOBroker die KNX-Schnittstelle des TWS eingestellt ist, unterbricht die Verbindung laut IOBroker-Log etwa alle 2 Minuten, um dann sofort wieder hergestellt zu werden (Alexa-Befehle genau in dieser kurzen Zeitspanne sind natürlich fehlerhaft).

Hallo,
ich glaub' das ist jetzt O.T., aber trotzdem:
Im TW-Container läuft iOBroker mit KNX-Adapter-Version 1.0.36 und IoT-Adapter 1.1.8 (Anbindung an Alexa-Cloud) sowie der JavaScript-Engine 4.3.2 (um eigene Befehle/Befehlsketten/Szenen zu erstellen und an Alexa/KNX zu übergeben). Funktioniert übrigens traumhaft gut, und meistens auch recht schnell (Licht an/aus/dimmen, Rolladen in % usw.). Ab und an brauchts zwei oder drei Gedenk-Sekunden, bis die Reaktion im Haus stattfindet. (Die nächste Stufe wäre dann die Offline-Alexa-Anbindung mit NodeRED)
Diagnostiziert hab ich's mit Hilfe des iOBroker-Logs: MDT-KNX-IP: keine Fehler. TW-KNX: viele Fehler, oft keine Reaktion auf Sprachbefehle.

@ElabNet: Nochmals Danke für euren Mega-Einsatz in dieser Sache!!!

BG
Thomas

[Sun1453]

Aber ihr habt ja schon rausgefunden, dass das Problem beim knx-Adapter zu suchen ist und dem Entwickler mitgeteilt.Nochmals Danke!!!

Wir sind dran.

Wir haben nochmal den Standard studiert und festgestellt, dass wir in der Sache der NAT-Verbindungen (hinsichtlich der ansonsten zigtausend Prüfungen) relaxter sein dürfen, und werden das auch im Daemon umsetzen um kompatibler zu sein. Womöglich muss der Entwickler des Adapters bei io:Broker dann hier nicht mehr Hand anlegen.

lg

Stefan

Ich würde erstmal die Antwort des Entwicklers abwarten. Wenn ihr dort jetzt wieder Änderungen macht dann muss doch alles wieder zertifiziert werden oder? Nicht das ihr euch dadurch wieder andere Baustellen aufreißt oder wird die Änderung nach der Final 1.5 erst kommen?

[StefanW]

Hallo Michael,

Ich würde erstmal die Antwort des Entwicklers abwarten. Wenn ihr dort jetzt wieder Änderungen macht dann muss doch alles wieder zertifiziert werden oder?

Wir haben mittlerweile festgestellt, dass eine der Prüfungen bei eingehenden Datenverbindungen bei uns strenger ist, als er sein müsste. Es gibt eine ganze Reihe von Prüfungen, die z.B. verhindern sollen, dass eine aufgebaute Verbindung von einem anderen Host übernommen werden kann. Daher wird ausgewertet, dass die eigentliche Verbindung nur zu dem Host unterhalten wird, der die gleiche IP und den gleichen Port benutzt wie beim Verbindungsaufbau angegeben. Dies wird bei der Zertifizierung auch überprüft.

Es gibt jedoch eine zweite Betriebsart, das ist der NAT Betrieb. Diese wird nach unseren Erkenntnissen vom ioBroker (oder auch der eibd / knxd) so genutzt. Hierbei gibt es drei Versionen im Verbindungsaufbau:

1. Client läßt Port und IP leer ("set to zero")
2. Client setzt IP, aber Port bleibt leer
3. Client setzt Port, aber IP bleibt leer

Unser Stack hat wohl einen der Fälle nicht so relaxed gehandhabt, wie es möglich ist. Das prüfen wir derzeit. Wir wollen ja schließlich nicht päpstlicher seine als der Papst und so kompatibel wie möglich, damit alle Produkte auch funktionieren.

lg

Stefan