Bekannte Probleme mit der Buskommunikation

[Tobi]

Hallo zusammen,

ich habe am Wochenende Probleme mit der Buskommunikation mit einem bestimmten NICHT-Selfbus-Gerät feststellen müssen. Ich habe hier im Forum schonmal einen Beitrag gelesen, wo die SELFBUS-Geräte bei Busfehlern anscheinend nicht so tollerant waren, wie originale KNX-HW. Aus diesem Grund möchte ich hier mal zusammentragen, wo ihr eventuell Probleme hattet. Mir geht es nicht darum die SELFBUS-Geräte "schlecht" zu reden, sondern vielmehr darum Probleme in diesem Thread zu sammeln, um dann idealerweise die SELFBUS-HW zu verbessern/anzupassen, insbesondere die "Bus-Ein-/Ausgangsschaltung". Im ersten Schritt würde es (Einsteigern) auch helfen bekannte Probleme bzgl. der Buskommunikation hier zusammenzutragen und ggf. ins WIKI mit aufzunehmen.

Mein konktretes Problem war:
- Schreiben der Adresse über ETS5 auf dem Rauchmeldermodul mit dem RaspberryPi + TUL-Stick (http://www.busware.de/tiki-index.php?page=TUL) als GW bzw. Programmierschnittstelle.

Vermutung:
Der TUL-Stick sendet ein "schlechtes" Signal auf den Bus, die die SELFBUS-HW nicht bzw. nur sehr sporadisch erkennt. Ich habe das Signal noch nicht (per Scope) überprüft, aber ich habe wirklich sehr oft versucht die Adresse zu schreiben. Ich habe außerdem noch einen SELFBUS-Schaltaktor getestet. Hier das gleiche Problem. Nachdem ich dann das SELFBUS-Raspi-Modul (FT12) als Programmierschnittstelle verwendet habe, lief alles ohne Probleme. Alle originalen KNX-Geräte haben kein Problem mit der Kommunikation zum TUL-Stick (läuft ca. 6Monate ohne Probleme).

Ich habe, wie gesagt, noch keine "größeren" Tests gemacht, weil ich bei der Fehlersuche natürlich erstmal gedacht habe, dass ich die Rauchmelder-Platine falsch bestückt oder ich das Projekt irgendwie falsch kompiliert habe. Nachdem aber der SELFBUS-Schaltaktor auch nicht funktionierte, wurde ich skeptisch, weil dieser damals auf meinem Testaufbau (ohne TUL-Stick) einwandfrei funktioniert hat.

Viele Grüße
Tobi

[Doumanix]

Hi Tobi,

danke für diesen Beitrag. Ich finde das super wichtig, dass das offiziell mal zusammengetragen wird. Nur wenn wir uns offen mit solchen Problemen auseinandersetzen, haben wir auch die Chance besser zu werden.

Ich finde es super interessant, dass dieses Problem auftritt, denn wenn ich das richtig sehe, ist ist ja auch auf dem TUL der Siemens TP-UART Chip verbaut. Busware hat ja auch noch einen Raspberry-HAT im Angebot, was fast 1:1 dem TP-UART Modul entspricht, welches Monster50 hier mal rein gebracht hat. Ich habe schon mehrere dieser Bausätze an User verkauft und habe selbst das RPi-TPUART-HAT im Einsatz und es hat praktisch noch nie Probleme mit der Programmierung von Geräten gegeben.
Was ich halt seltsam finde: warum macht die USB-Variante Probleme und die HAT-Variante nicht? Am Ende ist es ja beide Male der Siemens-Chip, der die eigentliche Kommunikation zum Bus macht.
Also wie gesagt: die Rauchmeldermodule lassen sich über das RPi-TPUART Modul einwandfrei programmieren.

Eine Rückfrage, um das von dir beschriebene Problem vielleicht stärker eingrenzen zu können: war das Modul im RM eingesteckt in dem Moment, in dem du die Adresse vergeben wolltest? Oder der RM gar schon auf den Sockel gesteckt?

Grüße
Christian

[Tobi]

Hi Christian,

stimmt, mir ist auch aufgefallen, dass hier anscheinend der Siemens-Chip verbaut wird. Ich habe das SELFBUS-RM-Modul OHNE Rauchmelder programmiert/programmieren wollen.

Ich habe, um weitere Probleme auszuschließen, einen Testaufbau gehabt, wo lediglich KNX-Netzteil+Drossel, RM-Modul und RPi+TUL-Stick angeschlossen waren. Minimaler ging es quasi nicht. Hier bestand aber weiterhin das Problem, weshalb ich den TUL-Stick im Verdacht hatte. Aus diesem Grund habe den Aufbau mit RPi+SELFBUS-FT1.2 getestet und es funktionierte.

Die genauen Unterschiede aber nochmal hier genau aufgelistet:

• Aufbau mit RPi+SELFBUS-FT1.2
  • RPi 2
  • EIBD
  • SELFBUS-FT1.2
  • Aufbau auf Schreibtisch
• Aufbau mit RPi+TUL-Stick
  • RPi 3b
  • KNXD
  • TUL-Stick
  • Aufbau im "Netzwerkschrank"

Ich habe hier extra nochmal den Standort mit aufgelistet, um ein EMV Problem nicht ausschließen zu wollen.

Wie gesagt habe ich bisher noch keine Scope-Messungen durchgeführt.

[Doumanix]

Mein persönlicher Tipp: KNXD.
Bisher läuft bei mir nach wie vor EIBD mit dem TPUART HAT.

Es könnte jetzt natürlich sein, dass am Ende dich das SB Modul das Problem macht und der KNXD sauber funktioniert. Aber mit EIBD und TPUART hatte ich die Probleme eben nie ...

[Tobi]

Danke für den Tipp. Dann teste ich heute Abend erstmal TUL-Stick+EIBD.

[Doumanix]

Noch ein paar Gedanken, damit diese auch in diesen Thread einfließen, auch wenn ich die teilweise schon im WIiki bzw. in anderen Threads dokumentiert hatte:

• nach meiner Erfahrung gab's bisher keinerlei Probleme mit dem RPi TP-UART Modul + EIBD; weder beim Programmieren von Adressen, noch beim Programmieren von BCU1, BCU2 oder BIM112 emulierende Firmwares. Auch LPC922 (BCU1) und ARM hatte ich getestet.
• Was aber Probleme bereitet hatte, ist das Selfbus FT1.2 Modul, insbesondere beim proggen von BIM112 Firmware (z.B. ARM TS). Diese Probleme und der Mangel an aktiven Mitgliedern, die fundiert an der Behebung der SW-Probleme arbeiten könnten, war ja der Auslöser, das TP-UART Modul anzubieten. Das ist zwar viel teurer, was den IC angeht und ist de facto keine echte Eigenentwicklung, aber immerhin ist es sehr leicht zu löten und man schließt eine Fehlerquelle aus.
• Einmal angenommen, es gäbe wirklich grundsätzlich mit dem TUL STick Probleme, dann müssten wir immer noch abwägen, was der sinnvollste Weg ist: eine Empfehlung aussprechen, den TUL Stick nicht zu verwenden (stattdessen vielleicht sich lieber das halb so teure RPi HAT Modul zu bauen) oder alle SB Module zu überprüfen. Wobei letzteres wahrscheinlich darauf rauslaufen würde einen Fehler in der SW als in der HW zu suchen. Die Jungs, die die Module gemacht haben, haben da echt nen guten Job gemacht und ich bezweifle, dass die Signale das Problem sind.
• Interessant wäre in dem Zusammenhang auch, ob es denn nicht ein mehr oder weniger zufälliges Auftreten des Fehlers ist. Soll heißen: hast du, Tobi, vielleicht zufälligerweise Baute erwischt, die ausgerechnet solche TOleranzen haben, dass sie mit dem TUL Stick Probleme bereiten? Ist jetzt vielleicht eine gewagte Theorie eines nicht-Elektronikers, aber am besten wäre es, wenn wir auch diese Variante ausschließen könnten.
  --> Frage in die Runde: hat noch jemand diesen Stick und kann seine Erfahrungen mit SB Geräten teilen?

Grüße
Christian

[hora0816]

Hallo Leute,
hat es hier eine Lösung gegeben? Ich habe seit einiger Zeit ein RASPI-Hat mit TPuart und KNXD am laufen und kann nun meine alten Module (LPC922 Basis, tlw 10 Jahre alt) nicht mehr programmieren. ETS 5.7.2, auch eine alte ETS3prof meckert mit ...device antwortet nicht in time. Ich hatte früher ein Alix Board mit eibd und eine Merten BCU im FT1.2 Mode mit PEI Interface am seriellen Port des Alix Board/ lief ohne Probleme ca 10 Jahre.

Gruß
Horst

[Doumanix]

Hi Harald,

kannst du ausschließen, dass es am KNXD liegt? Ich hatte zwar vor einem halben Jahr das mal wieder aufgegriffen, aber leider noch nicht zu Ende gebracht: ich habe bei mir bisher auch lediglich EIBD am laufen, da es mit KNXD immer wieder Probleme gab. Würde aber nicht ausschließen, dass ich da einen etwas veralteten Stand habe.

Interessant wäre auch die ETS Version als "Fehlerquelle" auszuschließen. Siehe viewtopic.php?p=4659#p4659
Nicht dass sich durch ein Update der ETS die Kompatibilität unserer Geräte verschlechtert hat. Gerade für LPC922er Geräte wäre das bitter, da ich niemanden kenne, der da aktiv noch was tut.

Grüße
Christian

[hora0816]

Hi Christian,
habe das alte Alix Board mit eibd wieder aktiviert und ich habe mit meiner ETS5.7.2 kein Problem, die alte LPCs zu lesen/programmieren. Wenn ich den ETS access wieder auf den RASPI/KNXD stelle (beides im Tunnel Mode) gibt es wieder Probleme. Für mich sieht das nach knxd Probleme aus.

LG
Horst

[Doumanix]

Hi Horst,

cool, danke für das Update an alle. Natürlich wäre es interessant, wo genau hier das Problem entsteht. Es ist schade, dass dadurch der Schritt auf KNXD zu migrieren immer wieder verhagelt wird, weil es zumindest mit Selfbus-Geräten + KNXD immer wieder Probleme gibt.
Aber immerhin heißt das auch: mit EIBD läuft alles weiterhin sauber weiter.

Grüße
Christian