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
Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
peti69 hat geschrieben: ↑So Okt 27, 2019 6:14 pm
Wie oben erwähnt gibt es neben OpenHAB auch meine Eigenentwicklung die einen Tunnel zum TWS direkt aufbaut. Dieses Stück C++ Software
Sofern in OH wirklich soviel Logik erledigt, würde ich als erstes das Stück eigene SW abschalten. Nichts gegen Deine Programmierkenntnisse, aber in Kombination mit den begrenzten KNX-Kenntnissen denke ich das er hier die Ursache implementiert ist, die dir die Schnitsttellenfunktionalität im TWS zerlegt / blockiert.
Das wiregate hatte ja mit seiner nicht zertifizierten eibd Instanz eine unbegrenzte Anzahl Tunnelverbindungen aufgebaut. Nicht auszuschließen, dass das Problem schon immer Bestand nun aber die 4 konfigurierten bzw. 25 Tunnel des TWs dann auch mal einfach voll sind, das wiregate hingegen einfach ständig neue Tunnel generiert hat.
Grüße
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Das Problem ist wieder aufgetreten (mit RC 8). Als erstes habe ich die beiden Container mit OpenHAB und meiner Eigenentwicklung gestoppt. Es gab also keine Tunnel mehr zum TWS. Der TWS hat weiterhin die Write-Telegramme 4-mal im Busmonitor angezeigt und keine 1-Wire Werte auf den KNX-Bus gesendet. Dann habe ich den ETS-Busmonitor gestartet. Dieser hat die Write-Telegramme nur einmal angezeigt. Allerdings war der Tunnel zum TWS nicht stabil. Es wurden immer wieder "Verbindungs-Ereignis" protokolliert:
Dann habe ich den KNX-Daemon des TWS neu gestartet. Daraufhin war der Tunnel der ETS wieder stabil - kein "Verbinungs-Ereignis" mehr. Der TWS hat die Write-Telegrammein in seinem KNX-Busmonitor nur noch einmal angezeigt. Auch die 1-Wire Werte waren wieder im KNX-Busmonitor zu sehen. Wie gesagt, alles ohne OpenHAB und meine Eigenentwicklung.
OpenHAB und/oder meine Eigenentwicklung haben möglicherweise eine fehlerhafte Tunnel-Implementierung. Allerdings sollte sich der TWS dadurch nicht aus dem Tritt bringen lassen und einen manuellen Eingriff benötigen.
Viele Grüße,
Peter
Zuletzt geändert von peti69 am Sa Nov 16, 2019 2:40 pm, insgesamt 2-mal geändert.
Timberwolf Server 2400 (ID:206), PBM und TP-UART Light, VPN offen, Reboot jederzeit
peti69 hat geschrieben: ↑Sa Nov 16, 2019 2:39 pmOpenHAB und/oder meine Eigenentwicklung haben möglicherweise eine fehlerhafte Tunnel-Implementierung. Allerdings sollte sich der TWS dadurch nicht aus dem Tritt bringen lassen und einen manuellen Eingriff benötigen.
Es gibt kaum ein Protokoll oder komplexe Maschine die sich mit geeigneten Maßnahmen nicht aus dem Tritt bringen lässt. Das hat damit zu tun, dass ein jedes technische System für eine gewisse Nutzungsbandbreite designed wurde. Das Getriebe eines PKW wird anders ausgelegt als das eines LKW. Selbst der Rückwärtsgang ist nur für eine Nutzung von 5 Km ausgelegt, nur die höheren Gänge dann für 150.000 km.
Bei Software und Interfaces ist das nicht anders. Es gibt eine gewisse Bandbreite innerhalb der ein Protokoll funktioniert und für die es ausgelegt wurde. Selbstverständlich verfügt unser KNX Stack über die Stabilitäts- und Schutzmechanismen, die im KNX Standard vorgesehen sind und für das es geprüft wurde. Aber nicht für alles erdenkliche darüber hinaus, weil es soll am Ende auch effizient und performant sein und das ist es nicht, wenn es zu 95% nur noch aus Fehlerkontrolle besteht (und wir sind glaube ich schon bei 85% angelangt). Mehr haben wir auch nicht versprochen und bekommen es auch nicht bezahlt.
Wenn Du herausgefunden hast, auf welche reproduzierende Weise die Tunnel verbraucht bzw. das beobachtete Verhalten am Bus ausgelöst wird, werden wir uns das auch gerne ansehen und anhand des Standards bewerten, ob wir eine entsprechende Maßnahme treffen können und dies auch dürfen.
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.
wir haben das Thema Tunnel einem deutlichen Update unterzogen.
==> Bitte Anfang der Woche auf die "V 1.6 RC3" updaten, dann sollte das Problem erledigt sein.
Es ist ein Release Candidate und so nahe an der Hauptversion (womöglich ist es dann schon die nächste Hauptversion) dass diese bedenkenlos installiert werden kann
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.