Zur Zeit bin noch intensiv am suchen, warum meine PMs unzuverlässig sind...
Gerade unter Beobachtung habe ich PM 1.1.25, der folgendes senden sollte:
Hängt dieser PM wo er hängen sollte, kommen die Adressen 1/2/20 und 1/2/21 nie - auch wenn die 6/0/20 schaltet.
Um hier weiter zu kommen, habe ich durchaus auch mal neuprogrammiert. Dabei sind mir im Log (über busmonitor1time mit direktem und exklusiv angeschlossenem TP-UART) einige Einträge mit
(in älteren Logs dagegen gar nicht...)
Das einzige, was ich zwischenzeitlich immer mal wieder geändert habe, ist wie die ETS auf den Bus zugreift (mal per IP-Tunnel des Routers, mal per IP-Routing über den Router oder auch mal per IP-Tunnel des WireGates, das selbst per IP-Routing über den IP-Router am Bus hängt. Der TP-UART hängt direkt am TP-Bus und ist hier als exklusiv zuhörender Teilnehmer mit eigenem eibd konfiguriert)
Da ich so nicht weitergekommen bin, habe ich heute quasi den ganzen Bus abgeklemmt, so dass nur noch der PM, das TP-UART, der IP-Router und die KNX-Spannungversorgung enthalten sind (+ 1-2 Aktoren).
Hier verhält sich der PM im Grunde erst mal so wie ich es erwarten würde.
=> Nächster Schritt wäre raus zu finden, ob es am normalen Bus-Teil irgendwelche Verkabelungsprobleme oder spinnende Bus-Teilnehmer gibt. (Aber wie könnten die "selektiv" einzelne Nachrichten killen?!? NACK und BUSY ist ja im vernachlässigbaren Rahmen, die INVALID CHECKSUM sind auch nur manchmal da)
Gibt es irgendwelche Tips und Tricks wie ich hier einen Fehler finden kann, ohne jetzt einzeln alle Teilnehmer ab- und wieder anzustecken?
Das dürfte gerade bei diesen sporadischen Problemen sehr aufwändig sein...
Als Messequipment habe ich leider auch nur ein (gutes) Multimeter und das TP-UART...
Gerade unter Beobachtung habe ich PM 1.1.25, der folgendes senden sollte:
- Alle 4 Minuten an 4/1/20 die Helligkeit
- Alle 60 Sekunden an die 6/0/20 die Überwachung ob jemand da/nicht da ist
- Licht An/Aus an die 1/2/21 mit Konstantlichtregelung an der 1/2/20, Treppenhausautomat ist auf 7 Minuten
Hängt dieser PM wo er hängen sollte, kommen die Adressen 1/2/20 und 1/2/21 nie - auch wenn die 6/0/20 schaltet.
Um hier weiter zu kommen, habe ich durchaus auch mal neuprogrammiert. Dabei sind mir im Log (über busmonitor1time mit direktem und exklusiv angeschlossenem TP-UART) einige Einträge mit
INVALID CHECKSUM
aufgefallen. In diesem Log sind dann auch noch andere, normale Botschaften mit INVALID CHECKSUM aufgefallen (in älteren Logs dagegen gar nicht...)Das einzige, was ich zwischenzeitlich immer mal wieder geändert habe, ist wie die ETS auf den Bus zugreift (mal per IP-Tunnel des Routers, mal per IP-Routing über den Router oder auch mal per IP-Tunnel des WireGates, das selbst per IP-Routing über den IP-Router am Bus hängt. Der TP-UART hängt direkt am TP-Bus und ist hier als exklusiv zuhörender Teilnehmer mit eigenem eibd konfiguriert)
Da ich so nicht weitergekommen bin, habe ich heute quasi den ganzen Bus abgeklemmt, so dass nur noch der PM, das TP-UART, der IP-Router und die KNX-Spannungversorgung enthalten sind (+ 1-2 Aktoren).
Hier verhält sich der PM im Grunde erst mal so wie ich es erwarten würde.
=> Nächster Schritt wäre raus zu finden, ob es am normalen Bus-Teil irgendwelche Verkabelungsprobleme oder spinnende Bus-Teilnehmer gibt. (Aber wie könnten die "selektiv" einzelne Nachrichten killen?!? NACK und BUSY ist ja im vernachlässigbaren Rahmen, die INVALID CHECKSUM sind auch nur manchmal da)
Gibt es irgendwelche Tips und Tricks wie ich hier einen Fehler finden kann, ohne jetzt einzeln alle Teilnehmer ab- und wieder anzustecken?
Das dürfte gerade bei diesen sporadischen Problemen sehr aufwändig sein...
Als Messequipment habe ich leider auch nur ein (gutes) Multimeter und das TP-UART...
Kommentar