Seltsame Telegramme auf dem Bus mit unbekannten Quell und Zieladressen

[Adressator]

Hallo zusammen,
ich bin zwar schon seit einiger Zeit als "Leser" im Forum unterwegs, verfasse aber heute meinen ersten Beitrag. Deshalb nehmt mir es nicht gleich übel wenn ich mich evtl. falsch verhalte oder vielleicht "dumme "Fragen stelle.
Ich habe wohl meine Lehrgänge bei der KNX Association abgelegt, treffe aber trotzdem noch auf den einen oder anderen Fehler da ich den KNX hauptsächlich nur in unserem Unternehmen einsetze. Daher fehlt mir natürlich viel Erfahrungswissen.
Aus diesem Grund möchte ich nun meine Frage hier an die alten Hasen stellen.
Ich habe in meinem KNX System eine Hauptlinie mit 5 Unterlinien störungsfrei am laufen. In der Hauptlinie befindet sich ein HS. Filtertabellen in allen LK´s sind korrekt geschrieben. HS läuft ebenfalls störungsfrei.
Weiterhin habe ich in der UL 1.4 eine KNX Heizungssteuerung von Siemens eingebunden die ebenfalls störungsfrei läuft. Allerdings habe ich ein seltsames Telegramm umherwandern das ich nicht zuordnen kann.
Es wird von einer nicht existenten Quelle zu einem nicht existenten Ziel versendet. Es interessiert keinen Teilnehmer und richtet keinen Schaden an.
Was mich wundert ist die Tatsache das es sich 24 Stunden lang jede Stunde 2 mal (zur Viertel- und zur dreiviertel Stunde) wiederholt. Immer mit den gleichen Rohdaten die ich leider nicht entschlüsseln kann.
Ich habe den Vorgang einmal mit dem EIB Doktor (Screenshot) aufgezeichnet da ich es im ETS Busmonitor nicht sehen kann.
Hat jemand schon einmal solch eine Erfahrung gemacht und weiß was die Ursache sein könnte?
Ich gehe ja schon von Spannungsspitzen in irgendeiner Unterverteilung aus, bin mir aber nicht sicher. Zudem entspricht meine Installation den VDE und KNX Vorschriften.
Kann mir hier jemand freundlicherweise einen Tipp geben?
Danke 🙂

[Klaus Gütter]

Das sind Extended Frames mit Quelladresse 1.0.200. Der Eibdoktor decodiert die offenbar falsch. In der ETS solltest du das besser sehen können.

[Adressator]

Klaus, Danke für deine Antwort. Aber wie kommst du jetzt auf die 1.0.200 ?
Die Quelle die ich meine ist doch mit 14.07.016 bezeichnet und geht zum Ziel 12.08.000.
In der ETS erscheint dieser Fehler überhaupt nicht. Das macht mich ja so stutzig. Aber anscheinend muss ja irgend etwas auf dem Bus passieren.
Oder wie darf ich das mit den Extendet Frames verstehen? Kenne mich da noch nicht mit aus 🙄

[Klaus Gütter]

Wenn du es ganz genau wissen willst, schau in die KNX Spezifikation, Volume 3/2/2.
Ganz kurz: wenn das oberste Bit des ersten Bytes (Kontrollbyte) auf dem Bus eine 0 ist (wie bei dir die 34h), folgt auf das erste noch ein zweites Kontrollbyte und dann erst die Quelladresse. Die ist also 10C8h, oder übersetzt 1.0.200.
Das ist vollkommen OK und kein Fehler.

[Adressator]

Hallo Klaus,
ich hab jetzt versucht mir jetzt die Spezifikation einmal anzuschauen. Leider reicht mein Englisch hierfür nicht mehr aus. Da bin ich wohl schon zu alt dafür 😏
Ich hab auch nochmal meine Lehrgangsbücher durchstudiert aber ich komme in keinster Weise mit den Aufschlüsselungen oder Umrechnungen zurecht.
Ich weiß wohl wie das Telegramm zusammengesetzt ist und welche Länge die verschiedenen Informationen haben (steuerfeld z.B. 1 byte) aber wie man die Rohdaten in meinem Sreenshot aufschlüsselt das weiß ich nicht.
Gibts hierzu noch irgendwo detaillierte Informationen oder Beispiele? Das würde mich schon brennend interessieren.
Ich danke dir auf alle Fälle schon einmal für deine Geduld. Leider weiß ich ja nicht wie ich mich hier am besten weiterbilden kann, deshalb habe ich mich ja fürs Forum entschieden. Ich denke bei euch kann man noch am meisten lernen.
Gruß
Norbert

P.S.
wie kommst du zB. auf 34h oder 10C8h ? In Hex geht das doch gar nicht zu rechnen?
Vielleicht bin ich auch zu blöd für die Sache......

[Adressator]

.....nur zur Info: Ich habe im EIB Doktor die Filterfunktion für "unspezifizierte Telegramme oder Fragmente anzeigen" deaktiviert. Dann schauts logischerweise auf dem Bus wieder sauber aus.
Dennoch möchte ich die Vorgehensweise wie du mir Sie erklärt hast verstehen können.
Ich bin für jede lehrreiche Info darüber dankbar.

[Klaus Gütter]

Nimm mal das Telegramm, bei dem der EibDoktor die Rohdaten als "34 e710 c800 00 15 [] 07" anzeigt.

Das erste Byte ist 34 hex = 00110100 binär, nach der Grafik in der KNX-Spec 3/2/2, Seite 27 unten schlüsselt sich das so auf:
TF=0 = L_Data_Extended-Frame
r=1 = not repeated (nicht wiederholt)
p=01 = normale Priorität

Da das ein extended frame ist, geht es weiter in Abschnitt 2.2.5, wo man sieht, dass dann ein Byte CTRLE, 2 Byte Quelladresse, 2 Byte Zieladresse, 1 Byte Länge folgt.

Also CTRLE=e7 hex = 11100111 binär, also gemäß der Grafik auf Seite 30 ein LTE_HEE-Frame (1rrr01xx binär) mit Hop Count 6.
Quelladresse sind dann die nächsten beiden Bytes 10c8 hex. Wegen c8 hex=200 dezimal ist das 1.0.200.
Zieladresse sind dann die nächsten beiden Bytes 0000 hex
Die 07 sind dann wohl die Länge, obwohl ich spätestens ab da der Darstellung im EibDoktor misstraue.

LTE ist übrigens ein hauptsächlich im HKL-Bereich von Siemens (Synco-serie) eingesetzes KNX-Protokoll.

[fbirkholz]

Hallo - heiße zwar nicht Klaus und habe sicher nicht die KNX-Kenntnisse - versuche mich aber dafür mal in Digitaltechnik..

Rohdaten sind zB.:34 e710c8000015[]07
Erstes Kontrollbyte Hex 34 = Bin 0010 0010 - oberstes Bit 0
zweites Kontrollbyte: Hex e7 ( in diesem Fall uninteressant)
weiter die Quelladresse: Hex 10C8 = Bin ₀₀₀₁ ⁰⁰⁰⁰ 1100 1000 übersetzt ₁ ⁰ 200

Ich vermute so hat Klaus das gemeint.

Gruß
Franc

[Adressator]

Hallo zusammen,
jetzt wird mir die Sache klarer und ich kann es nachvollziehen.
Was noch interessant für mich ist das es sich hier um einen LTE Frame handelt. Denn genau diese Siemens Synco Regler habe ich nämlich verbaut.
Da weiß ich jetzt zumindest in welche Richtung ich schauen muss.
Ich bedanke mich bei euch für die Hilfe.
Oder wie Lothar Matthäus sagen würde: Again what learned 🙂