UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Problem] IOBroker KNX-Schnittstelle periodische Unterbrechnung

Alles rund um io:Broker im Allgemeinen und den entsprechenden Docker-Container für den Timberwolf Server im Speziellen.

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#21

Beitrag von 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
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Benutzeravatar

tws88_user
Reactions:
Beiträge: 428
Registriert: So Aug 12, 2018 9:42 am
Wohnort: Raum Magdeburg
Hat sich bedankt: 242 Mal
Danksagung erhalten: 148 Mal

#22

Beitrag von tws88_user »

Tomtheripper hat geschrieben: Mi Nov 06, 2019 3:26 pm
ms20de hat geschrieben: Mo Nov 04, 2019 12:42 pm Hallo Tom,

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

Bild

Viele Grüße,
Matthias

Hallo Matthias,

nur der Vollständigkeit halber:
Ich kann gar kein KNX-Send-Delay einstellen, wird bei mir nicht angezeigt.
Bild
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.
Viele Grüße, Kai
______________________
Timberwolf88 (2500er) - VPN offen. Reboot bitte nach Absprache.
Benutzeravatar

tws88_user
Reactions:
Beiträge: 428
Registriert: So Aug 12, 2018 9:42 am
Wohnort: Raum Magdeburg
Hat sich bedankt: 242 Mal
Danksagung erhalten: 148 Mal

#23

Beitrag von 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?

Tomtheripper hat geschrieben: Mo Okt 21, 2019 2:42 pm
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).
Viele Grüße, Kai
______________________
Timberwolf88 (2500er) - VPN offen. Reboot bitte nach Absprache.

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#24

Beitrag von StefanW »

tws88_user hat geschrieben: Fr Nov 08, 2019 11:50 amAber 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
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Tomtheripper
Reactions:
Beiträge: 135
Registriert: Mo Okt 01, 2018 11:34 am
Hat sich bedankt: 62 Mal
Danksagung erhalten: 37 Mal

#25

Beitrag von Tomtheripper »

tws88_user hat geschrieben: Fr Nov 08, 2019 11:52 am 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?

Tomtheripper hat geschrieben: Mo Okt 21, 2019 2:42 pm
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
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#26

Beitrag von Sun1453 »

StefanW hat geschrieben: Fr Nov 08, 2019 4:28 pm
tws88_user hat geschrieben: Fr Nov 08, 2019 11:50 amAber 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?
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#27

Beitrag von StefanW »

Hallo Michael,
Sun1453 hat geschrieben: Fr Nov 08, 2019 9:51 pmIch 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
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Antworten

Zurück zu „Docker Container: ioBroker“