MDT Glastaster II lässt sich nicht mehr Programmieren

[blacksavior]

Der Wolf ist super... bin von der Leistung echt begeistert. Alleine schon als reiner Visu Server hat der seine Daseinsberechtigung... und das ist nur ein Bruchteil der Features.

Aber...

Der TWS hat aber nicht zufällig einen seiner Tunnel auf die 1.1.20/21 gelegt?

...Du bist klasse gbglace. Ich Volldepp hab damals wohl die Adressen 1.1.20-29 an die Schnittstellen vergeben.

Naja, wie so oft bei Störungen im KNX-Umfeld... schaue nicht auf den Bus, lass die Geräte links liegen... nimm dir den Kerl vorm Monitor vor.

Danke Euch!

Gruß Oliver

[gbglace]

Mein TWS hat die schöne Seriennummer 225, da hab ich ihm auch gleich dies als PA gegeben und die folgenden 226-250 für die Tunnel, dahinter hab ich dann die USB und sollte Mal noch ein anderes wesentliches Systemgerät rein kommen dann ist da noch was frei bis 255.


PS:
Die PA hat er sich ggf auch allein genommen, wenn gar keine effektiv programmiert sind, dann nimmt er einfach die nächsten die Frei sind. Wenn die Taster zwischendrin Mal offline waren kann das passieren, daher besser die Tunnel effektiv programmieren.

Machen andere Schnittstellen nicht anders, die blocken blocken eben nur 4/5 oder 8 PA

[Gast1961]

damals wohl die Adressen 1.1.20-29 an die Schnittstellen vergeben.

Unter welchen Bedingungen wird sowas eigentlich von der ETS gemeldet/geblockt und wann muß man händisch Dummies anlegen?
Beim L1 ist das irgendwie automatisch gelöst.

zus_PA.png

[gbglace]

Ja die ETS sortiert einfach automatisch die nächsten freien PA an die Tunnel.

Allerdings wäre ich dann auch davon ausgegangen, das man dann auch keine Geräte in der ETS mit diesen PA anlegen kann. Dann hätte die ETS schon meckern müssen beim Editieren der PA im Projekt, definitiv nicht erst beim Versuch zu programmieren.

[blacksavior]

Bei mir ist das etwas anders. Da die ETS APP für den Timberwolf das Gesamtprojekt damals ausgebremst hatte, liegtd er in einem separatem Projektfile. Da die Konnex ja nun die ETS verbessert hat, so dass sie besser mit Objektreichen Geräten zurechtkommt, könnte ich die eigentlich zusammenführen.

Somit konnte die Kollision seitens der ETS nicht erkannt werden. Das Bild des L1 könnte auch vom Timberwolf sein. Nur dass der dort 25 Interfaces hat.

Aber ich errinnere mich daran... die 20-29 kommen definitiv von mir. Das Hauptinterface des Wolfes hat die 1.1.255.

Gruß Oliver

[gbglace]

Ja das erklärt es dann.

[Dragonos2000]

Hast Du OpenHAB laufen? Wenn ja, stoppe OpenHab und versuch' nochmal zu programmieren. Ich habe ähnliche Probleme beim Programmieren, verursacht durch OH, die sich aber nicht bei allen Busteilnehmern bemerkbar machen.

[Gast1961]

Hast Du OpenHAB laufen? Wenn ja, stoppe OpenHab und versuch' nochmal zu programmieren. Ich habe ähnliche Probleme beim Programmieren, verursacht durch OH, die sich aber nicht bei allen Busteilnehmern bemerkbar machen.

Das klingt doch sehr danach, daß es auch wieder mit den Tunneln zusammenhängt ... wenn OpenHAB gerade auf den Tunnel nutzt, wo es die Adresskollision gibt.

[gbglace]

Einmal das, aber auch ohne den direkten Tunnelkollisionen gab es schon einige Berichte von Programmiererrors, gerade auch beim Programmieren im hohem Bustempo. Eine genauere Analyse hat wohl auch ergeben, dass der KNX-Adapter im OH an der Stelle nicht ganz sauber umgesetzt ist. Und wenn man dann Geräte / Systeme (z.B. TWS) hat die etwas strenger am Standard implementiert sind dann kann es sich da verschlucken. Im TWS-Forum sind da schon einige Fälle diskutiert worden. Bei den OH Leuten ist das aber wohl auch schon adressiert.

[Dragonos2000]

Konkret habe ich bei mir nachvollziehen können, dass OH während des Programmierens Disconnetcs auf den Bus schickt. Belegte Tunnel sind da nicht das Problem, das kam alles von unterschiedlichen Adressen.