[Erfahrungsbericht] [ETS 5.7.4] [V1.6 IP1] - Kein Zugriff auf den KNX-TP Bus, Schnittstelle belegt.

[haeuslebauer]

Nachdem ich in den im Letzten Jahr an der Migration vom Wiregate zum TW gescheitert war habe ich es jetzt wieder in aAngriff genommen und das hat auch gut funktioniert. Das Wiregate lief parallel und ich habe nach wie vor über das Wiregate von der ETS auf den Bus zugegriffen.

Timberwolf 950Q mit 1.5.3

Kaum waren alle Daten umgezogen, zeigte das System plötzlich ein merkwürdiges Verhalten. Es gingen Dimkreisen selbst an und aus, etc. - Irgendwann bin ich dann darauf gekommen, das das Flash des Wiregate sich gehimmelt hat. Also das Wiregate außer Betrieb genommen.

Seit dem funktioniert hier garnichts mehr:
- Comet Visu hat keine Verbindung zum Bus
- ETS: ein Zugriff ist nicht möglich, da ich keine separate Adresse für einen Tunnel auf den Bus habe und sich das auch nicht einstellen läßt, da ich wiederum keinen Zugriff habe
- Sensordaten kommen nicht mehr durch an den Bus - Schnittstelle ist bereits belegt. Dadurch ist die Heizung außer Betrieb.

Eine Umprogrammierung der PAs geht auch nicht, da kein Zugriff.

Nach dem Artikel von Stephan habe ich dann gedacht mit einer 2. noch unbelegten Schnittstelle könnte ich das Problem lösen und habe den USB TP-UART umgeflashed. - Funktioneriert auch, allerdings nicht parallel, daher ist der Fehler derselbe.

Nächster Schritt: Update auf 1.6 RC1 - hat auch nichts gebracht.
RC 2 ist noch nicht verfügbar wie ich gehofft hatte mit der besseren KNX Verwaltung.

Fazit: ca. 30 Stunden investiert in den Umzug um auf einen Stand zu kommen den das Wiregate schon seit 2013 hatte - funktionieren tut es trotzdem nicht. Cometvisu ist tot, Heizung auch, WAF im Keller.

[gbglace]

Moin. Mal ganz unabhängig vom Umzug, hatte der TWS jemals einen Buszugriff unabhängig vom wiregate. Bevor man einen Umzug macht kann man ja den TWS Mal ganz einfach so einrichten das er mit dem Bus selbständig interagieren kann. Wenn der Zustand erreicht ist, kann man ihm gern auch noch ein Daten und Funktionsgedächtnis vom wiregate implantieren.

Die 950-er TWS haben ja die interne direkte KNX Schnittstelle die benötigen keine weitere externe, das macht man nur für einen reinen zusätzlichen Busmonitor Betrieb im nicht Applikationsmodus also alles nichts was Dir hier jetzt helfen kann.

Also als allererstes mach mal so als ob der TWS frisch aus dem Karton kommt und gehe die Anleitung zur Inbetriebnahme durch, so ganz ohne Migrationsvorhaben. Wenn Du dann Zugriff auf den TWS selbst per Browser hast schaut man weiter in der ETS. Dort sollte der TWS als Schnittstelle gefunden werden und auf allen Ebenen wie Linien usw. sollte das wiregate als Busschnittstelle entfernt werden. Sollte das wiregate kaputt sein da aber noch in der ETS registriert sein dann funzt das natürlich nicht.

Danach hier bitte wieder berichten.

[haeuslebauer]

Hallo Göran,
ja den Zugriff hatte er und ich konnte auch über die Schnittstelle schon programmieren.
Das habe ich alles gemacht, bevor ich den Umzug angefangen habe.

Auch das Senden der Werte auf den Bus von Sensoren etc. hat alles schon funktioniert.

Nachdem das Wiregate gestorben war, habe ich die alte Schnittstelle vom Wiregate aus der ETS gelöscht und sie ist auch im Projekt nicht mehr übrig.

Die Sensoren schreiben auch in die TS Datenbanken, es ist nur das KNX interface dauernd belegt, sodass weder die Daten aus dem TW auf den Bus kommen, noch ich zum Programmieren von der ETS auf den Bus komme.
Wenn ich das irgendwo sinnvoll ablegen kann, setze ich das Ding auch nochmal auf Werkszustand zurück.
Ich will nur nicht den ganzen Sensorumzug nochmal von vorne machen müssen.

Die Fehlermeldung ist in beiden Fällen die Gleiche: Die Schnittstelle ist derzeit belegt.

Viele Grüße

Heiko

[haeuslebauer]

Hallo Göran,
ich bin einen Schritt weiter. ich komme wieder von der ETS auf den Bus und kann Programmieren. Offensichtlich war eines der Probleme das ich ursprünglich die 245 als PA für den Timberwolf vergeben hatte und danach keine 25 weiteren PAs mehr frei waren auf der Linie.
Dadurch hat es wohl einen Konflikt mit der Schnittstelle gegeben.
Zusätzlich habe ich auch die Windows Firewall für die ETS noch weiter geöffnet. Im Ergebnis kann ich ich wieder auf den Bus zugreifen und habe die PAs für den Timberwolf auf einen sinnvollen zusammenhängenden Nummernkreis programmieren können.
Mal gucken ob es dann geht.

Viele Grüße

Heiko

[gbglace]

Zumindest das mit den PA lohnt sich genauer anzuschauen, der KNX-Stack sollte eigentlich so schlau sein und sich wenn startend von 245 die Plätze voll sind dann vor der 245 freie gezogen werden.

Nen Docker außer CV hast sonst noch am laufen? Da hab ich hier und da gelesen das da einige etwas problematisch sind und gerne Mal die Tunnel sukzessiv blockieren.

Aber zumindest kannst nun via TWS only erstmal den Bus verwalten.

[haeuslebauer]

Grundsätzlich war das ganze erfolgreich und ich kann auch Programmieren etc.
Die letzte Hürde war noch das Programmieren einer weiteren Linie. Im ETS Projekt war noch übergeordet Reste der alten Schnittstelle. Die findet man wenn man im Topologie Fenster auf Topologie Backbone klickt.

Die Visu funktioniert auch wieder, allerdings mit 3sec Latenz. Sprich, man dimmt eine Leuchte von 0 auf 70% an und 3 sec später reagiert dann der Bus und das Licht geht an.
Mal gucken woran das jetzt liegt.

Ich habe noch einen Container für Wiregate Plugins laufen, allerdings ist da noch kein einziges Plugin drin. Das ist das letzte was ich noch migrieren muss. Allerdings kommt nichts großes wichtiges mehr, das kann ich im Zweifel auch weglassen.

[StefanW]

der KNX-Stack sollte eigentlich so schlau sein und sich wenn startend von 245 die Plätze voll sind dann vor der 245 freie gezogen werden.

Der Herr über die PAs ist diejenige Instanz, welche die PA verwaltet und vergibt, das ist i.d.R. die ETS.

Der Stack hat hier nichts selbst zu entscheiden und zu vergeben, sonst gäbe es Chaos am Bus, wenn jeder (gleichberechtigte) Teilnemer sich selbst irgendwelche PAs nimmt.

RC 2 ist noch nicht verfügbar

Bitte: es ist die Insider Preview 2, nicht der Release Candadate 2 (den es noch geben mag.... erst kommen die Previews, dann kommen die Candidates, dann kommt die Hauptversion). Ich habe es geändert.

wie ich gehofft hatte mit der besseren KNX Verwaltung.

Nun, man kann künftig sehen, welche Tunnels überhaupt insgesamt zur Verfügung stehen, weil für diese eine PA programmiert wurde. Allerdaing kann man das jetzt auch schon in der ETS erkennen. Trotzdem wird die Übersicht mit der neuen KNX Verwaltung sehr viel besser werden und es werden genaue Informationen und Handungsanweisungen eingeblendet, um solche Missverständnisse künftig zu vermeiden.

Fazit: ca. 30 Stunden investiert in den Umzug um auf einen Stand zu kommen den das Wiregate schon seit 2013 hatte - funktionieren tut es trotzdem nicht. Cometvisu ist tot, Heizung auch, WAF im Keller.

Das ist wenig passend und unangemessen gegenüber unserer Arbeit.

Der Wiregate Server von 2009 basiert auf dem eibd von 2006 und dieser eibd kann nur etwa 15% dessen was der Standard für einen zertifizierbaren Stack vorschreibt.

Eine praktische Eigenschaft des eibd war, dass er beliebig viele Tunnel auf der gleichen PA (meist 0.0.0) abgebildet hat, damit musste man sich mit dem zuweisen der PA für Tunnel nicht herumschlagen. Das hatte zur Folge, dass es augenscheinlich "immer funktionierte".

Allerdings ist das so nicht zertifizierbar weil jeder Tunnel seine individuelle PA zugewiesen haben MUSS. Da wir den Timberwolf Server mit einem zertifizierten Stack ausgestattet haben, mussten wir uns dem KNX Standards auch beugen, daher besteht nun für die Kunden - wie bei anderen modernen KNXnet/IP Tunneling Schnittstellen auch - die Pflicht die PAs für jeden Tunnel zu vergeben.

Man kann eben nicht beides haben. Einen Stack der gegen wichige Standards verstößt oder einen Stack, der zertifiziert kompatibel ist. Der eibd hat eine ganze Reihe von Fehlern und nicht implementierten Eigenschaften. Wir haben aus gutem Grund gut eine viertel Million Entwicklungskosten aufgewendet um den leistungsfähigsten 32 / 64 Bit KNX Stack zu erschaffen.

Auch wenn das ein oder andere sich womöglich anfangs etwas mühsamer anfühlen mag, als beim WireGate Server, weil man nun präziser konfigurieren muss, glauben wir, dass sich die Anstrengungen am Ende lohnen und sauberere Technik auch zu besserer und dauerhafter Funktionalität führt.

In der nächsten V. 1.6 IP2 gibt es - was das Tunnel-Handling betrifft - noch eine Verbesserung: Man kann sich nicht mehr den Ast absägen auf dem man sitzt. Das bedeutet, selbst wenn man sich alle Tunnel-PA dekonfiguriert, bleibt immer der Default-Tunnel 15.15.255 übrig, so dass man der ETS immer drauf kann. Mit der Tunnel-Übersicht sieht man auch, wer oder was einen Tunnel belegt.

lg

Stefan

[haeuslebauer]

Hallo Stefan,
ich bin kein Programmierer, aber ich verkaufe selbst Software und Systeme und ich weiß durchaus, dass das nicht einfach ist. Mir gefällt das Konzept der Timberwolf sehr, sonst wäre ich bei all den Wirrungen auch nicht nicht bei der Stange geblieben.
Auf die persönlichen Anwürfe werde ich nicht eingehen, ich möchte einfach das das Teil seine Arbeit tut.

Den Unterschied zwischen Eibd und zertifizierbarem Stack hast du oben gut erklärt und ist so auch verständlich.
Ich habe das so eingerichtet, step by step und es funktioniert jetzt auch mit dem Programmieren und die Tunnel werden passend belegt.

Nachdem das alles erledigt war, reagierte die Visu wieder, allerdings mit 3 Sec Latenz und der Dispatcher (Object-Verwaltung) zeigt jetzt keinen der 170 Einträge mehr.
Dafür schickt der Timberwolf Daten von der Heizungssteuerung as Relais permanent den KNX Bus.
Im KNX Opject Editor stehen alle GAs mit der Markierung "GA fehlt" und dahinter wird die GA angezeigt. Auch landen die Daten auf den richtigen GAs, nur halt viel zu oft.
Auch das hat er bis gestern nicht getan, die Werte kommen eigentlich nur alle 5 min von der Heizungsteuerung.

Nach 2 Stunden auf Grund der Fehlermeldungen habe ich dann wie von Göran vorgeschlagen den Wiregate Plugin Container gelöscht.
Ich konnte mir das als Ursache nicht vorstellen, den es war nichteinmal ein Plugin drin.
Ergebnis:
Objektverwaltung funktioniert,
"GA fehlt" sind alle weg.
Der Bus wird auch nicht mehr mit Daten geflutet.
Die Latenz der Visu hat sich von 3 sec Verzögerung auf 1 sec verbessert.
Ich werde mir also die Installation des Plugin Containers sparen, dann kann ich mit dem Zustand leben, hoffe aber das die Latenz der Visu noch in den Griff zu bekommen ist. Die war früher bisher nicht merkbar und auch schneller als vorher auf dem Wiregate.

VG

Heiko

[gbglace]

Mach mal nen Ausschnitt vom Busmonitor wp zu viele Ga gesendet werden.

Ein KNX-Gerät welches eine GA sendet für die sich kein Empfänger findet muss gemäß Spezifikation Telegrammwiederholungen senden.

Ja auch wenn da kein Plugin so recht installiert ist, kann da natürlich irgendetwas drinnen gewesen sein was da Bustelegramme produziert hat. Wenn Du nicht viele Logiken oder welche mit externem Content dann kannst das sicher auch in der neuen TWS-LE recht leicht abbilden.

Wahrscheinlich hat das Ding massiv was gesendet was so einfach nicht im ETS-Projekt enthalten war, weswegen da auch so viele Fehlermeldung wg unbekannter GA kamen.

Latenzen usw. bei der CV kann ich nichts weiter zu sagen, habe keine Visu bei mir am Laufen.

[haeuslebauer]

Hallo Göran,
danke nochmal, du hast genau das richtige Stichwort gegeben. Da haben sich Werte für die Visu gespiegelt und sind deshalb mehrfach auf dem Bus aufgetaucht. Das sorgt dann für entsprechend lahme Performance. Ich bin erst nicht drauf gekommen, da die nicht als abgebrochene und nochmal gesendete Telegramme im ETS Monitor gelb markiert waren, sondern die haben sich gespiegelt, da sie auf sich selbst geantwortet haben.

Jetzt funktioniert alles und auch die Visu ist gewohnt schnell.

Vielen Dank nochmal und schöne Ostern

Heiko